Which Product Management framework to use when
There are lots of different Product Management tools, techniques and frameworks out there that all seem to do different things. These techniques are relevant for different segments of the product management journey, so it can get quite confusing about what to use when. Here is a mapping of what I think are the best techniques for each stage.
Map out the problem space with Jobs to be Done
This is an excellent framework for understanding and mapping customer needs. Jobs to be Done (JTBD) makes you shift the focus away from your product, and makes you think about what the customer is actually trying to achieve. When interviewing customers or analysing feedback, I find a job map is the best way to store findings.
There are different approaches to JTBD, and some approaches like Tony Ulwick’s Outcome Driven Innovation will take you through to “Problem Selection” as well. However, this approach is very expensive and not viable for most product teams. So I see that the main benefit of this framework is mapping needs in the first place. This is something we need to be doing continuously, and so your job map(s) should be a living document.
For a good summary of the JTBD world, I recommend the Jobs to be Done playbook by Jim Kalbach. It gives a good overview of all approaches.
Create alignment and focus with OKRs
When we start thinking about which problem to focus on, we need to think about what our current company/team strategy is. We need to understand what customer problems we can solve that will drive business value. Therefore, we need an understanding of what business value is important right now.
OKRs are a brilliant way for a company to communicate what outcomes it wants to drive in the current quarter / year. The OKR framework then allows teams to decide which parts of the company strategy they are able to focus on for the coming OKR cycle.
The clarity that this brings helps a team narrow down the list of customer problems that it should focus on solving.
If you don’t know about OKRs, then Measure What Matters is generally the book you need to start with. For a quick overview, I have always liked Dan North’s article.
Pick your problem with Opportunity Trees
This is a brilliant approach to mapping out which opportunities a team should focus on to drive a particular business outcome. I find it is particularly useful with stakeholders (who often think in solutions rather than problems/opportunities/outcomes) to take their ideas, clarify the problem they think they are solving, and then use that to frame solution discovery.
I can’t recommend enough Teresa Torres’ book Continuous Discovery Habits which covers Opportunity Trees and much more of the Product Management process, but she also has some great blog posts on Opportunity Solution Trees too.
Generate solutions with (part of) a Design Sprint
When it comes to generating solutions, I think there is nothing better than the Design Sprint process from Google Ventures. The Design Sprint is a 5 day process where a team focuses on a particular problem and aims to solve it.
Day 1 is all about understanding the problem (which we’ve already done with the previous techniques) and then day 2 and day 3 are all about generating ideas and designing a potential solution (day 4 and 5 are about building and testing a prototype). It’s fun to do a design sprint from end-to-end, but I also find it useful to take a lot of the techniques from days 2 and 3 to help teams generate solutions to a problem they have decided to focus on.
The book is called Sprint, definitely worth a read.
Work out what to test with Assumption Mapping
This is another technique covered by Teresa Torres in Continuous Discovery Habits, but is actually from David Bland’s Testing Business Ideas. Once you have generated several potential solutions, this approach helps you quickly map out all the riskiest assumptions associated with them, and gives a (clichéd 2 x 2 matrix) to map which are the most important to test. This helps demonstrate what you need to do to gain the biggest learning.
If you want to understand the approach quickly, Teresa has another comprehensive blog post about it.
Test with Minimum Viable Products
I think it was a terrible name, but it is the name that Eric Ries used, so that’s what I’ll call it. The name “Minimum Viable Product” is misleading, because you don’t really need to build a product that you sell to customers. His definition is:
“The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”
I prefer to call them risky assumption tests. We do the smallest things we can do to learn the most about the riskiest assumptions that we highlighted in the “assumption mapping” process. This might be a fake door test to understand desirability, a clickable prototype to test usability, or a proof of concept to understand technical feasibility.
Assumption mapping helps us understand what we need to test. The MVP is that test. By the time we have tested several of the riskiest assumptions, we should have a good idea of what is the best solution.
If you haven’t read Lean Startup, then go read it.
Plan what you build with User Story mapping
Once you have a good idea of what is the optimal solution, then we need to start thinking about the best way to deliver that. User Story mapping is a great way to map the final solution out.
We might think we have a good idea of what the final solution should be, but we can never be 100% sure, and we almost definitely don’t know the best way to deliver it technically. So we still need to learn as we go, we still need to iterate our way to the solution.
User story mapping allows us to map out the solution in a way that makes it easy to break it down into iterations that give our development team the ability to deliver valuable software sprint after sprint. This ensures that we create a solution that delivers value to our customers, and the business.
Jeff Patton was the inventor of User story mapping, Here is the book, and here is his webpage on the topic.
Conclusion
A lot needs to happen to ensure you are delivering products that fulfil your team’s mission. It’s a hard task to find feasible technical solutions that meet user needs and drive business value at the same time. There are a lot of different frameworks out there, and hopefully this gives a clear structure of what to use when.
What have I missed? What would you add to the list?
