A note for new subscribers: This post is part of a bi-weekly Sunday series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
Over the past 6 weeks, I’ve made (and expanded upon) 3 points in this series on IC/individual contributor product management
1. A product manager brings together a group of cross functional stakeholders to build a product that is valuable, usable, and feasible.
2. Of these 3 outcomes, building for value is the most important as there is no substitute for it. The fabled “product sense” skill is the ability to consistently identify and build for value – I term it “problem finding.”
3. Thus, the four core skills of a product manager are – problem finding, problem solving (solving for usability and feasibility), building effective teams, and selling (internally and externally).
As I spent my last note explaining why product sense is simply the ability to build for value, today’s post will be focused on lessons learnt on how to build for value. And, the three tools we’ll discuss as part of our problem finding toolkit are problem statements, hypotheses, and riskiest assumption tests. These are the first 3 and arguably most important steps of the product process.
Problem Statements: Good problem statements articulate 3 elements – i) audience – who are you building for?, ii) need/problem – what is the specific need/problem?, and iii) value – what is the value of solving the problem?
The worst case scenario for products is those that get built without a clear articulation of the problem. This typically happens when problem statements are written for the executive team or as a homage to the HiPPO / highest paid person’s opinion. And, the bad scenario is when product teams are unclear about who they are building it for. It is okay to be wrong about the target audience – that happens from time to time. But, it is poor form to start without a point of view.
Here’s an example problem statement from Amazon in 2004. I wasn’t part of the Amazon team in 2004. But, given how beautifully they’ve nailed the online shopping customer experience, I’d assume they started with a problem statement in a 6 page memo that looked something like this.
We want our loyal customers (monthly actives) to have a delightful shopping experience on Amazon.com. However, our checkout experience data and user research confirms that this is not the case. Customers hate paying shipping costs and this either prevents them from completing their shopping experience or forces them to redo their shopping to minimize shipping costs – thus creating a stressful and unsatisfactory experience. Solving this problem for customers would be worth $xxxM in the first year alone.
Hypothesis: A hypothesis is a proposal to the meet the needs of the audience articulated in the problem statement. A hypothesis can be expressed as a collection of assumptions that can be validated using experiments or data and can be thought of as an answer to the question – “What do we need to believe for this problem to be solved?”
Here is an articulation of the hypothesis of the Amazon free shipping problem statement above.
Our hypothesis is that offering free shipping to our loyal customers would result in a significant improvement in their shopping experience on Amazon.com while also greatly improving our ability to monetize customer engagement. This hypothesis is based on the following assumptions –
1. Free shipping will reduce the stress and anxiety that comes with shopping online and will translate to a faster, more efficient, check out experience.
2. Customers who are offered free shipping will have higher lifetime value – making it well worth the investment cost.
3. Our customers will be open to paying for a monthly/yearly subscription that offers unlimited “free shipping” for a reasonable price point
The Riskiest Assumption Test or RAT: The natural next step is to figure out how to test this hypothesis – ergo a “riskiest assumption test.”
The riskiest assumption in the 3 assumptions laid out above is (1) as it makes the case that free shipping has high customer value (2 and 3 are focused on value capture). And, we can now imagine tests to validate this. We could design an A/B test with “free shipping” in the treatment group or analyze existing data to plot the correlation between check out time and shipping costs.
As you can see from the flow from problem statements -> hypothesis -> RAT, a problem well stated is indeed a problem half solved.
How is an RAT different from a MVP? The main problem with the “MVP” term is that it is ambiguous and that has led to to memes like the one below (and articles like this).
(Image credit: Applico)
FWIW, I think the principle behind the “Riskiest Assumption test” is the same as the principle behind the “Minimum Viable Product.” These memes just underscore the importance of thinking about the customer user/problem (i.e. transportation) before thinking about the product/solution.
But, given my stated purpose in the series is to simplify how we think about product management, it means discarding more ambiguous terms like “product sense” and “minimum viable products” and replacing them with “problem finding” and “riskiest assumption tests.”
The case for problem management instead of product management. A consistent theme that has hopefully become evident through this series is the importance of focusing on problems instead of products. To that end, I recently came across a tweet by Isaac Hepworth, a PM at Google, that I thought was on point.
Companies that get disrupted are those that focus on owning product solutions instead of owning customer problems. I thought it was fitting that we used an Amazon example as we worked through the problem finding process. They are the textbook example of a company that has done a phenomenal job focusing on customer problems that are, in Jeff Bezos words, “things that do not change.”
A career and life sidebar. There’s a lot of conflicting advice on perseverance out there. We are led to believe that entrepreneurs who succeed never quit. But, we then hear stories of those who knew exactly when to quit and “pivot.” When do we persevere? And, when not?
Applying what we’ve learnt today, the wrong kind of perseverance focuses on the solution while the right kind focuses on the problem. Problem finding, thus, isn’t just a valuable product management skill – it is an incredibly valuable career and life skill.
