Matt Kowalski is VP of Product at Uplift Labs, a software company transforming human movement performance with AI-powered insights. He started his career at Intronis, the MSP-dedicated business unit of Barracuda Networks, where he worked his way up to Director of Product Management before joining WHOOP. From there, Matt transitioned to product management at iZotope before moving to leadership at Uplift Labs.
In our conversation, Matt talks about how behind every job to be done is an emotional feeling a user is seeking. He discusses the importance of defining a product’s aha moment, as well as how his team is working to create a consistent user experience across platforms.
Uplift is an AI and computer-vision-driven tech company focused on motion capture and movement analysis. We’re focused on delivering motion capture and movement analysis in a more portable way than ever before. With two iPhones or iPads, users can capture any stationary movement, be it baseball swing, golf swing, jump, squats, etc.
We’re primarily deployed in big organizations, from major league baseball teams and NCAA programs, to help them understand how their athletes are moving to prevent injury, improve performance, aid with scouting, and more. We’re also working on a single-camera product that will be released in the fall. It takes the core technology that Uplift has deployed to these big-name organizations and brings it down into one device, making it much more accessible for the everyday coach, trainer, and athlete to use and benefit from.
Especially in the early stage of a product’s cycle, it’s really important to be very clear about the objectives that you’re driving toward. Priorities should always follow objectives. For most early-stage products — whether just launched, in beta, or only a few months old — the primary aim should be identifying a core group of highly engaged users and driving toward product-market fit for that specific group. The focus should be on solving a very specific problem for them.
In terms of prioritizing features and functionality, the focus should be on delivering the value prop of the product for a specific user group, instead of prioritizing the breadth of functionality of the features. This includes defining your aha moment in the product, prioritizing UX experiences and features so that more users reach that moment, etc. Next, you need to constantly monitor the signals, analytics, and data you’re collecting to see if your priorities are actually moving that needle. From there, you adjust your approach as needed.
From my previous experiences at iZotope, a company that creates music software for producers, engineers, and musicians, we worked on a product that worked as a mobile app with a paired hardware device. The app was designed to help hobbyist musicians create music that sounded as good as what they heard on the radio or Spotify.
For that product, the aha moment was when users shared what they recorded with someone else. This highlighted the core value prop — the music these users created sounded so good that they felt proud to share it. We also looked at other usage activities in the platform, but this sharing feature had a strong correlation with higher engagement and better retention.
Users who reach this aha moment with the product are more likely to continue using the product. So, an aha moment should be something that has a measurable outcome, but it should also be something that’s tied very specifically to the goal and the value prop of the product.
Resources are always a challenge. Usually, early-stage companies can’t just throw marketing dollars at building top of the funnel to acquire more users. They typically start with a lower volume of users. In those cases, there are signals that are often large but might not be meaningful. There could be a few squeaky wheels in the user base. So while it’s always important to listen to what users are saying, it’s critical to remain focused on the product vision at this stage.
The other challenge is that early in a product’s life cycle, almost everything that the product team is doing, prioritizing, and building is an assumption. It’s an informed assumption based on market research, user research, and competitive analysis. But everything is theoretical until they get the product out in the world and can actually measure how users interact with it. This means there’s a lot to learn and analyze in terms of usage and data inputs. So it’s a lot to sort through before deciding, “OK. What do we do next based on what we’re seeing?”
There are a couple of ways. One is that you should maintain the same rigor and focus you give to user research that you do before the product launches throughout the product life cycle. You should make sure that you have a healthy community of both users and non-users to participate in some user research. I’m also a fan of a persistent beta program. You should always have a beta program for your product. It gives you a pool of feedback-friendly users and lets you test and experiment with your product in a more controlled setting.
The other component is making sure you’re intentional about your user segmentation. In a growth phase, there are multiple ways to grow. You can increase your penetration within a specific customer segment or move to adjacent customer segments and grow from there. Knowing the differences in those user segments’ profiles and personas and targeting user research at the customer segment you want to grow into is vital in a growth phase.
Relying on feedback from your current customers may not be enough if you intend to expand into new use cases or target new current segments. So, when expanding your use cases to get new customers, you need to ensure that you are targeting representative people in that new segment.
I’ll start with beta because that’s the world I’m living in right now. In this case, I mean pre-launch. In this phase, you’re looking at qualitative metrics because you’re doing things like face-to-face or over-Zoom usability testing with designs to make sure that people can actually use the software. This is all about concept testing — you’re doing live feedback sessions and trying to better understand the target customer persona or segment you’re going for. There’s a lot of digging into the current pain points and frustrations of your users.
From a quantitative perspective, engagement will naturally be pretty high in beta. It may not necessarily be a realistic signal, but you could look for short-term usage retention or make sure people aren’t dropping off the app soon after joining the beta. If they are, that’s a good indication that you’re not positioning the product effectively or fulfilling the product promise yet. With this, you know you need to work toward a more holistic expression of the product before launching it.
At the launch phase, you’re looking at user acquisition, but that’s usually a little less owned by the product and much more on marketing and product marketing early on. After launch, there are two things.
First, you’re looking for the friction points that need to be fixed quickly to get people to reach the aha moment in the product. If people are dropping off during onboarding or before they perform the first value-deriving action in the app, you need to fix it right away because that means they are hitting a roadblock before they even get to what the app is supposed to help them with.
Second, you will track engagement and retention through cohort analysis of different customer segments. This will help you determine what your beachhead customer segment is. For example, if you’re working on our product, say the engagement and retention in the first three months are high among high-level NCAA strength and conditioning coaches but very low among high school basketball players. This means you need to pay attention to the way you prioritize features going forward based on who you want to acquire or how you position and message the product.
It’s a huge challenge, and it’s similar to the challenges of being in an early-stage company. In a perfect world, we’d have a fully staffed top of the line research lab with no shortage of research subjects. But because we’re an early-stage company, we want to collect that data from app users.
Our current product has seen lots of adoption in baseball, softball, golf, and other sports focusing on rotational movements. This is a very specific set of data and people. However, one of the reasons we are building our single-camera product is that we want to offer a solution that’s more accessible and more broadly applicable to people of all health and athletic objectives. When we launch a product, it’s important to start with a smaller target user group, so we’re focusing more on psychographic niches. We’re looking at very data-driven, disciplined people who already have a good fitness regimen and are already using wearables, tracking their calories, or working with a coach.
We’re building an experience that isn’t for everyone — it’s specifically for the early adopters in the fitness and health space and those very intentional about their approach. Across that, the actual gender, age, ability, sport, training experience, and injury history are very broad. One of the things we want to do with this product is make it applicable across sports because that would give us more room to grow.
Establishing a common design language with consistent icons, language, and colors early on is important. It’s also important to call things by the same name. From a general product management approach, treating the product as a unified platform is important. You don’t want to segment product management decision-making based on platform, such as having separate product managers for iOS, Android, and web, without having some oversight at a platform level to make cohesive decisions.
Consistency is important, but you also need to know when not to try to be consistent. For example, take the concept of using the right tool for the job. Our current product generates a lot of data, like joint angles, jump height, takeoff velocity, and biomechanical and kinematic data. A coach or a sports scientist who wants to pore through the data for trends and correlations for all of their athletes won’t do that in an iOS app — they’ll use a web platform.
Athletes, on the other hand, tend to look to see how they are improving over time on metrics like the jump height or their new PR in something. They generally want to do this on mobile. So, how we present that data is very different for different users and formats. It’s OK that it’s inconsistent because it’s fulfilling specific needs and doing two different things.
I’ll start with a disclaimer — this is a thought philosophy approach that I’ve mostly applied in consumer software. In B2B products, emotional needs are still a consideration, but the decision-making process is different — the users are less emotional, more logical, and more budget and ROI-driven.
But the reason the emotional needs of users are important is that as you define the jobs to be done for specific features or products for your user base, you’re doing a specific job for them, but there’s always an emotional root to why they want that done. We’re all human beings, and with every definition of a job to be done, there’s an actual task, and there’s an emotional feeling that we want to have at the end of it.
When I first speak with a user for user research purposes, I don’t immediately talk about the product, or at least not for the first 30 minutes. I focus on talking about their experience with the job we’re trying to help them with, what their pain points and frustrations are, and what makes them feel capable when they get something right.
Then, I can do a root cause analysis. For example, why does a user want to update their profile picture? It’s not just because they want a different one; they want to present themselves a certain way on a platform. In the health and fitness case, they’re proud of the transformation that they’ve made, and they want to show off. So, leveraging users’ emotional needs is all about understanding them through research and empathy.
A great example from Uplift is how we adjusted our reporting. At first, it was mostly built for sports scientists, data analysts, and biomechanists at major league baseball teams, while now it’s useful for hitting and pitching coaches at all levels. When we interviewed pitching and hitting coaches, they told us that our reporting was not actionable enough. They needed a glossary to understand all the data, and even then didn’t know how to communicate it to the athlete and use it themselves to coach their athletes better.
This all speaks to the deep emotional needs of feeling capable and confident in your abilities or expertise, and of wanting to do a good job and seeing the fruits of your labor — in this case, by seeing the players you’re coaching improve.
So, we spent a lot of time with hitting and pitching coaches across all levels, from the big leagues to college to youth. We asked them what their superpower was in helping players improve, how they communicated lessons to the players, and what language worked the best — making them feel confident and capable.
We also learned what terms they used and what experts they looked up to. We used all that feedback to make multiple updates to our pitching and hitting reports, and with each update, we got better feedback and more excitement from coaches. We were helping them be better at their job and thus feel capable and proud.
It’s also a great example of how each release of a feature is re-testing your assumptions and learning from it. The way you iterate and constantly improve that feature is so important to deliver real value to users.
This is a decision I’ve made at every place I’ve been. One of the deep emotional needs of anyone who’s using a product or service —especially if it’s something that helps them do something they’re passionate about — is that they want to feel capable.
For example, at Whoop, we completely revamped our first-time user experience early on. We developed an onboarding process that explained, “What is sleep? How is it calculated? What is recovery? Why is it important? How do we measure daily strain, and how does it influence the recommendations we give you?”
We could see a huge retention jump in the cohort of people who had gotten that educational first-time experience versus the cohort of people who hadn’t. This improved retention was one of the things that convinced us to move to a subscription model. We knew that the lifetime value of the customer base would support the shift.
At Uplift, there was an inflection point in almost every product where we prioritized a first-time user experience over a new feature functionality — something that helped walk the user through how to use the product. We focused on speaking their language, helping them understand t how to get the most value from it. This approach was critical to solving the problem users had hired our product to address.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
Learn more →
