Playbooks

An Opportunity Solution Tree is one of my other starting points because a visual map can make a discussion easier to follow. Some people work comfortably through estimates in a table. Others understand the choices more quickly when they can see how the pieces fit together. Both help build shared understanding.

The tree connects an outcome we want to improve to customer needs, possible solutions, and the assumptions we need to test. It gives the team a way to ask whether an idea addresses a meaningful problem and whether solving that problem would move us toward the outcome.

Start with a clear product outcome linked to the business goal. Use customer research to identify the needs and difficulties that could help explain why that outcome is not happening. Those are the opportunities. Under a selected opportunity, explore different solutions and the assumptions each depends on.

The structure comes from Teresa Torres's Opportunity Solution Trees. Her method keeps customer opportunities distinct from solutions and uses assumption tests to guide what the team learns next.

I find the visual structure useful for seeing where something is still too broad. A large branch may contain several different customer problems. Breaking it down can help us choose a smaller opportunity and identify an experiment that would teach us something useful.

For a simple, hypothetical example, a team might want more new customers to finish a first useful task. If research shows they cannot tell which option fits their situation, several responses are possible: clearer descriptions, a guided first step, or a different starting point. The next question is which assumption we need to test before committing to one.

The diagram should make the team's thinking easier to examine. Keep customer evidence close to the opportunities, distinguish assumptions from findings, and change the map as you learn. A useful tree helps people explain what they are considering, why it matters, and what they still need to understand.

RICE is my default starting point for prioritization. Reach, impact, confidence, and effort give us a straightforward way to discuss an idea and compare it with other work. The useful part is what we learn by working through those estimates together.

A precise score can give people more confidence than the inputs deserve. If we disagree about impact, we need to talk about what would actually change for customers or the business. If confidence is low, we should be able to explain what we do and don't know. The framework gives those conversations a place to start.

Keep the customer problem, supporting evidence, and intended outcome with the work you are considering. Before estimating effort, describe a possible approach at a useful level of detail. The same problem may have several solutions with very different costs.

• Reach: Who would benefit, and how many of them would we expect to reach in the same time period?
• Impact: What meaningful change do we expect for those people, and how does it contribute to the outcome?
• Confidence: What supports the estimates? Where are we relying on an assumption?
• Effort: What would this approach take from the people involved?

RICE score = Reach × Impact × Confidence ÷ Effort

Use comparable units and explain the estimates. A colleague should be able to understand why one option ranks above another and challenge the reasoning. Intercom's original RICE method describes the scoring model.

The ranking is one input to the decision. Dependencies, operational work, risk, and team capacity affect what can happen next. When priorities change, explain what moved and what that means for existing commitments.

That is where trust comes in. People need to know why the plan changed and what they can now expect. New tools can change the effort involved too, including where AI makes a different approach practical. Revisit the estimate when the work changes; keep responsibility for the decision with the team.

I used RICE with cross-functional leaders at Pie as part of our roadmap prioritization. Read the Pie Insurance story →

Some disagreements are hard to resolve by talking. A prototype gives people something to react to, and a test with customers gives the team new information to work with.

A design sprint puts a short, structured process around that learning: understand the challenge, explore approaches, choose one to prototype, and test it. The question you need to answer gives the week its purpose.

There is a consequential uncertainty you can explore through a realistic prototype. The people who need to act on the answer can participate, and you can reach the customers whose response matters.

Agree on the decision this work should help you make. Identify the assumptions behind the idea and what you would need to see to change direction. Plan the customer sessions early enough that testing actually happens.

A workshop and a prototype are useful work, but the learning comes from seeing what people do with the idea. Use that evidence to decide what to change or investigate next. A short test doesn't establish long-term adoption or answer every technical question.

Method: The Sprint authors' guide.