How do you connect the customer problems you're solving with the features you're shipping?
I originally wrote this in 2017 after working with several companies that were struggling to answer the question "how do we know if that feature succeeded?" I've updated this to include some new links and materials.
A Product Manager’s job is one of the broadest and most chaotic roles in an organization. With competing interests, saying no a lot, the latest fads, along with goals and objectives to hit, it’s easy to forget what actually is the core of the role.
Many years ago I read an article by Adam Nash that really stuck with me. I believe it captures the essence of good product management. Adam suggests that a Product Manager’s job comes down to articulating two simple things: what game are we playing? And how do we keep score?
I love this because it underscores the point that as Product Managers, it’s our job to understand, distil and communicate what we’re trying to accomplish as a business along with how our product supports those business goals.
It’s such a simple, clear and concise summary of the amorphous role of Product Managers. And I think it’s worth consciously embracing this concept and spreading it through your organization.
Too often PMs are shepherding a roadmap/backlog/mixed bag of semi-organized features and themes. People aren’t exactly sure why one thing is prioritized over another. Most of the time the features that get delivered were “low hanging fruit” or “something simple we could knock off”. Other times the loudest voice wins.
And once those “something simple to knock off” features have been pushed to prod, it’s time for a quick, but forced celebration. We don’t always think about the poor customer who is at the receiving end of this potluck of features. Did they enjoying our low hanging fruit or should we have let it rot on the vine? Even more crucial, we forget to ask “how does solving this problem move the needle on our business goals?”
When this happens you’re a Product Manager in a very unhappy state. A PM from my former team aptly described this as “Jira Janitor”. And we’ve all been there. That unhappiness is likely contagious, spreading to the rest of the product, engineering, sales, marketing, customer success and finance teams not to mention, customers. And it’s a leading indicator of a team treading water that, unfortunately, will never make significant headway. But it doesn’t have to be that way.
Instead, Adam’s “what game are we playing and how do we know the score?” mind shift not only establishes context for everyone in the company, it removes the success theater of “yay we shipped 🎉 🎉 🎉” Even better, it gets everyone aligned on what goals and metrics matter. And the only way to make headway on those goals is to ruthlessly scrutinize the proposed problems to solve and feature requests.
Another thing I like about Adam’s concept is that it reinforces that there is no company or product success without success for our customers. Sounds easy and it can be if you remember two simple things: what game are we playing and how do we keep score?
The Game: What Customer Problems are we solving?
Starting with “What game are we playing?”, think about your customers first: What problems are we solving? For whom? Equally important, who aren’t we building this for? Side note: I’m going to assume you’re drawing on a customer development practice to quantitatively answer these questions. If you aren’t stop right now and start there. Seriously.
Once we know what problems and users we’re targeting, it’s time to layer in your Product Vision and Strategy.
Jobs-To-Be-Done is a great framework for demystifying Vision & Strategy. Ask yourself “Why would customers hire our product in particular to solve this problem?”. “How are we solving the problem for them in better or differentiated way?”. Be honest. Brutally honest. Another way to think about this is to imagine you’re writing the press release for this product/feature. What would it say? What would your key customer quote be? What are the resulting features that solve the problem for your Target Audience that fits your Vision and Strategy? All of this upfront work goes a long way to reducing your product risk.
The Score: How do I know what product analytics I should measure?
Now that you know what game you’re playing, how do you know the score? Easiest place to start is by asking what’s the goal of solving this problem with these features? In other words what needle(s) are we moving and how far do we expect them to move?
These should be real metrics. And by real I mean measurable and attributed to the features that you’re releasing. An easy trap to fall into here is to forget about timeframes. While revenue, retention and conversion are both admirable and valuable goals you need to make sure you’re also including some leading indicators that tell you are on the right or wrong track as soon as possible.
There are lots of ways to tackle metrics but they tend to be specific to your product and/or customer segments. Outside of your overall KPIs (e.g. revenue) there are some basic metrics that can get you going. Think about:
-
Who uses the feature and who doesn’t? How long is the feature being used for? By what user segments/personas? Look for trends by user segment/persona here. Is the trend expected or does it challenge your assumptions?
-
Do people complete the task the feature is used for? Do users bail out at a certain point? Does it vary by user type or persona? Symptoms: UX issues, problem-feature mapping, etc… doing this helps isolate if a feature isn’t being used due to how it’s implemented vs the problem it’s solving.
-
Do different user cohorts use the feature differently and at different rates? If there are major discrepancies between cohorts, this can uncover if you’ve successfully introduced the feature to existing users vs. new users.
Amplitude, has released their North Star Framework that helps product managers connect the customer problems that the product team is trying to solve and the revenue that the business aims to generate by doing so. If you're unsure how to begin, this is an easily understood framework to get everyone pointed in the right direction, pun intended.
Adopting this product rigour will put you miles ahead of most product orgs and product managers. Your entire company will be much happier for it and you’ll be happy that everyone can make better decisions based on the product context you’ve clearly established.
