There is a ton of information about product management on the internet at this point. Very rarely, however, I found this information to be practical — meaning, being able to go and use this new information in practice right after I read some piece.
Here is my take on what the core body of product management should look like at practice.
Deliverables
Your product work has very concrete deliverables. And while user insights, product analytics data or market data are all nice (and necessary) to have, they’re merely stepping stones, not the actual output you are supposed to produce. Your deliverables are product hypotheses — educated guesses on what is needed to be changed in the product to hit our goals.
In that sense, most of the time on the job you need producing and refining such educated guesses. How? By educating yourself, using information both about the (potential) users and product usage. Then you use this data to come up with the guesses on what actual changes needed to be made in the product.
Learn about the user
That’s the insights you’re gathered outside of the product. Collected data is either “qualitative” (lower number of reports, higher details) or “quantitative” (larger number of reports, lower details). Qualitative data helps understand what challenges (potential) users are experiencing and quantitative is the mean to estimate potential reach and impact.
Qualitative data
You’re trying to hit the depth in user understanding here. You do it by rather talking to the users directly in 1–1 manner (UX research) or peeking on publicly available communications (reading forums, watching interviews, reading news from the market you’re trying to serve).
You’re looking for the potential challenges users are facing, for each you try to understand whether the product potentially can solve it. Then you need to estimate the prevalence of the challenge by using a quantitative approach.
Quantitative data
While qualitative data is a nice tool for producing hypotheses on challenges users are facing, it doesn’t help much with estimating how many users are potentially experiencing the same challenge. From this point you’re using quantitative data to do such estimations:
- Users survey. You’re asking users on the scale, whether they’re experiences the same problem
- Market data. While during a user survey you’re asking users about their behaviour (whether they’re experiencing the issue or not) - here you’re collecting raw facts about the users. Then you use these facts to clusterize the market and understand how many potential user will benefit from the product change
During this process we’ve created the set of the initial hypotheses and then filter/prioritise them based on potential reach and impact. Some of them will end up in the product, from this point it’s worth to leverage product data to properly re-iterate the features.
Learn about the product
Collect data about how users interact with the product. This information usually serves as a positive feedback loop of previous product hypotheses, which is supposed to increase chances of success of future educated guesses.
Most basic quantitative data of the product is usage statistics:
- How frequently is the feature used?
- What is retention?
- Does the feature affect core business metrics? (sales, conversion)
- What does a feature funnel look like?
For the features that have lower metrics then expected you’ll try to find the cause. However collected data by itself doesn’t tell much — whether the feature used frequently or not is just the start, the next logical step is to ask ourselves “Why is it happening and how can we change it?”. From this point we might leverage qualitative insights.
For the features that have lower metrics then expected you’ll try to find the cause. However collected data by itself doesn’t tell much — whether the feature used frequently or not is just the start, the next logical step is to ask ourselves “Why is it happening and how can we change it?”. From this point we might leverage qualitative insights.
Here you aim to get a strong understanding on how very concrete user sessions in the product looks like. Those sessions are not necessarily typical on a scale, however it better serves the purpose of generating concrete hypotheses and understanding full user flow. Usual means:
- Studying actual user sessions and usage funnel. Those can be actual video recording or user sessions in your analytics toolkit
- Using the product by yourself. It’s important to try to be in the “user shoes” and take a detached look at the product while using it.
- Live user research where you’re asking users to try the feature and doing the observations.
Here you are supposed to generate ideas on potential root causes of why the feature doesn’t hit expected metrics. You close the loop by estimating the impact of the root causes by doing quantitative research and then try most prominent hypotheses. After that you’re repeating the whole process.
Conclusion
Described workflow is the backbone of your product work and the actual product hypothesis are the most basic deliverables of your work. Of course, you’ve also working on more high-level deliverables, such as product vision, strategy and roadmap. However, it’s important to remember that all of these things really should be tied up to the very concrete question you’re supposed to answer all the time over and over — “what do we need to change in the product to hit our goals?”
