Outcome Hypothesis Tree
We tend to call professions that focus on solution building — engineers. Software engineer, mechanical engineer, hardware engineer you name it. When we look into titles in a typical cross functional product team, we see that not every title contains an engineer in it. You have your typical Software Engineer, Quality Engineer, but when we reach to people whose job is to define the product itself and suddenly their titles are Product Manager, Product Designer etc. I think this doesn’t reflect the true nature of these people’s work which is — Product Manager being the Market Problem to Solution Engineer and Designer being the Solution Design Engineer.
Thats right Product Manager is primarily a Market Problem to Solution Engineer not just Solution engineer. Our job starts from discovering market problems that are large and important enough to have people pay for it. This means we should spend most of our brain power on getting deep understanding of customer pain.
Bernie Roth — Professor of Engineering at Stanford once famously did an experiment with the audience. He did a short interview with one of the audience members — lets call her Lily.
“What do you want to have in life?”, he asked.
“I want to have a house”, Lily replied.
“What would be better of, if you had a house”, Bernie followed up.
“I would feel more grounded in my community”, Lily replied.
“How else could you feel more grounded in a community”, Bernie asked.
Lily thought for a little bit and answered, “Well maybe I could join a local social club, or do volunteering, I could even join the local Baseball fan club”.
The lesson learned from this small dialog is that the importance of finding a solution is not as critical as having deep understanding of the the ideal outcome after the problem is solved. This way you broaden your horizon to finding alternative solutions. Focusing on solution thinking creates tunnel vision that obstructs us from seeing all opportunities.
This philosophy applied on product development world is usually called “Opportunity Solution Tree”. At the top we have the opportunity and below it different solutions to it.
I don’t really like the naming of Opportunity Solution Tree as it still fails to formulate product creation as an experimental multi-phase discovery process that it should be. As Rafayel Mkrtchyan’s describes in Discovery Sprint discovery process similar to delivery process shouldn’t rely on long, costly cycles rather should be short, experimental and resource lean.
Trying to mind map the concepts of Discovery Sprint with the Opportunity Solution Tree we created a new framework called Outcome Hypothesis Tree (OHT)
Outcome Hypothesis Tree
We can view the OHT as a 4 level tree that helps us to understand, where to put the precious engineering resources on. The lower the branch, the more resources are needed.
Level 1: Defining the Outcome
Everything starts from defining the desired outcome that we seek. The outcome should be a sentence formulated from customer perspective.
“Outcome is a measurable change in customer behavior that leads to business success”
If we dissect this definition the 3 critical properties of a result to be qualified as an outcome are
- It should be a customer behavior change, not a change for business only
- It should create positive impact on the business
- It should be measurable
Lack of any of these 3 properties will make the outcome meaningless as it would either have no impact on the customers or the business, or be unmeasurable therefore not reachable.
We could define the outcome in form of objective and key results, where the objective will define the customer behavior change and the key results the metrics, goals and deadlines for the outcome to be measurable.
Level 2: Building Hypotheses
Now that we understand the outcome we can start thinking about different ways to reach that outcome. I intentionally don’t call this step a solution because at this stage you cannot come up with the solution rather with a hypothesis the approval of which will qualify its core assumption as a solution. Hypothesis describes a potential solution that should be validated with set of experiments to be worth investing in.
Level 3: Building Experiments
For the hypothesis to be validated we need to define a set of experiments that will either approve or reject the hypothesis. Each experiment should be formed as a gateway. Early experiments must be cheap to implement — ideally without engineering involvement. For example fake door testing could help understand the demand. Early experiments should have destructive form, so that if rejected the hypothesis can be rejected and skipped. If early experiments give positive result you can invest in more experiments to validate the hypothesis. The rule of thumb for the number of experiments needed is to map that to the complexity of the solution. Experiments are cheap ways to mitigate risk that could arise when you invest in the wrong direction.
Level 4: Solution
Once you have enough experiments proving the hypothesis you can formulate the solution based on the hypothesis. As you do more and more hypothesis experimentation you will learn multiple solution can work. Here you can apply any prioritization framework you like that would take the effort, viability, feasibility, reach, etc. into consideration and take the best ROI solution to invest in.
This shows that in lean product discovery and development cycles you don’t spend most of your time building tens of solutions, rather filter down to few validated solutions to increase the chance of reaching the outcome.
When it comes to roadmapping you should consider that shipping the solution is not the end. Once you have the market adoption you should ask yourself the tough question, “How much impact did this have to the outcome defined?” If the impact is low or none you should pivot to the next hypothesis and stop doing what you were already doing or otherwise accept that what you have shipped was a half-backed “MVP” that didn’t bring the customer value you aimed for.
Conclusion
Understanding the core problem you solve and the desired outcome you seek will make it much easier to find the solution. Approaching solution engineering scientifically by proving or rejecting experiments will set you on a leaner way and save precious time and resource on errors. Outcome Hypothesis Tree can help you visualize and track those efforts and keep yourself accountable to not jump into solutions.
About the Author
Narek Hayrapetyan is a managing partner at theConsultancy. He advises companies how to map business goals to product strategies to customer outcomes and align organizations vertically and horizontally. He helps companies to use their data to turn it into insights and apply experimental and scientific methods on validation of solutions, strategies and ideas.
About theConsultancy Partners
theConsultancy Partners is a consulting firm that helps businesses to build the path towards digitalization and prepare the organization to support the new economy of Experience-Led Growth.
To help our clients unlock their full potential towards digitalization and Experience-Led Growth we offer a 4-phase program, where we complete:
Analysis:
Perform analysis to find problems and opportunities in products, processes and org structure.
Level up:
Run masterclasses to level up teams to solve those problems and realize opportunities.
Implementation:
Work with teams day to day to implement solutions with our proprietary frameworks and methodologies.
Handover:
Handover all the knowledge and guidelines needed for sustainable growth.
