By Teresa Torres · producttalk.org · @ttorres on X · LinkedIn
This Product in Practice piece profiles Chris Hockley, a lean agile coach at SuperAwesome, who introduced the opportunity solution tree to several product teams through a staggered rollout. He found that teams grasped the tool best when shown it with their own real product outcomes, and that it kept discovery grounded in opportunities before solutions. When one team ran only expensive, full-solution A/B tests, Chris pushed them to break solutions into testable assumptions across value, usability, feasibility and business risk. Adding an assumptions layer and a results section, with color-coded validation, tripled the experiments run per sprint. The story matters because it shows the tree as an adaptable team tool rather than a fixed template.
01Key takeaways
- Roll out the opportunity solution tree to one receptive team at a time rather than all teams at once.
- Demonstrate the tree using a real product KPI so teams see its value concretely.
- Capture off-track ideas on the board in their proper section, then gently refocus on opportunities.
- Break each solution into underlying assumptions to test before building the full feature.
- Assess assumptions across value, usability, feasibility and business risk to choose the right test.
- Record experiment results and color-code validated nodes so decisions stay traceable.
02Key sections
- Staggered rollout
- Chris introduced the tree to one team at a time, starting with a team already seeking structure for discovery. Hands-on sessions anchored to a real KPI helped teams see its value.
- Keeping opportunities and solutions distinct
- Teams often drifted from opportunities into solutions. Chris parked those ideas on the board in the right place and steered the conversation back.
- Experiments that were too big
- One team wanted to test whole solutions via production A/B tests, which were slow and taught little about why something worked. Chris saw the need for smaller, cheaper experiments.
- Four risk areas for assumptions
- Chris framed solutions as assumptions about value, usability, feasibility and business risk, each testable with lightweight methods. Teams added an assumptions layer to the tree.
- Results and current practice
- A results section and color-coded nodes made decision history visible. Fake-door tests and other low-build experiments tripled experiment volume per sprint.
03From the post
“Hi there, Product Talk readers! It’s me, Melissa. I’m Teresa’s blog editor. I mostly work behind the scenes here, polishing and proofreading posts prior to publication. But every once in a while, I’ll contribute a post like this one. Here at Product Talk, we’re excited”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.