Generating Multiple Solutions per Opportunity

Generate multiple solutions for one target opportunity through individual ideation, then narrow to three for a compare-and-contrast decision.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Generating multiple solutions is the step in an Opportunity Solution Tree where the team moves from a customer need to ideas for meeting it. The rule that defines the skill is to generate several ideas for the same target opportunity and compare them, instead of evaluating one favorite idea on its own. Teresa Torres frames the difference as two kinds of decisions. A "whether or not" decision asks whether an idea is good, which is hard to answer because good is relative. A compare-and-contrast decision asks, "Which of these ideas looks best?" (Torres, How Compare and Contrast Decisions Lead to Better Product Outcomes).

Ideation is scoped to one opportunity. Torres advises teams not to brainstorm solutions across the entire tree, and to choose three solutions for the target opportunity to explore further (Torres, Opportunity Solution Trees). Keeping every idea tied to the same opportunity means the three finalists answer the same question, so the comparison is fair. Her original post on the tree warned against comparing solutions that address different opportunities, since the argument is then really about which problem matters.

The method borrows from research on brainstorming. Group brainstorming, popularized by Alex Osborn in his 1953 book Applied Imagination (Torres, Stop Brainstorming and Generate Better Ideas), feels productive, but Torres cites studies showing that the same number of people working individually generate more, and more diverse, ideas than they do brainstorming as a group. Torres's approach is to have people generate ideas on their own, then share and build on each other's ideas.

This skill produces solution nodes on the tree. Breaking those solutions into testable assumptions is covered in Designing Assumption Tests for OST Solutions.

How It Works

Quantity comes first. In her talk on compare-and-contrast decisions, Torres states that "when we generate more ideas, we generate better ideas," citing research on brainstorming. Her book club guide to Chapter 8 of Continuous Discovery Habits describes the chapter's aim as generating 15-20 ideas for a single opportunity (Torres, CDH Book Club: Supercharged Ideation). First ideas tend to be obvious, and the more unusual ideas often come after the obvious ones are exhausted.

Individuals ideate before the group meets. Torres lists four reasons group brainstorming underperforms: social loafing, conformity, production blocking, and downward norm setting, where the group drifts toward the level of its weakest performer (Torres, Stop Brainstorming and Generate Better Ideas). In a review of 22 studies summarized on Wikipedia, Michael Diehl and Wolfgang Stroebe found that, overwhelmingly, groups brainstorming together came up with fewer ideas than the same people working alone. The same guide to Chapter 8 recommends an individual-then-share approach.

When people get stuck, prompts help. The Chapter 8 guide suggests looking at analogous products, considering extreme users, and thinking about wild ideas. Torres's original OST post adds that solutions "can and should come from everywhere (as long as they are bounded by an opportunity)," so stakeholders, engineers, and customers can all contribute ideas, as long as each idea addresses the target (Torres, 2016 OST post).

Convergence is a separate step. Once the ideas are visible, the team clusters duplicates, and the guide to Chapter 8 describes using dot-voting to whittle the list down to three for a compare-and-contrast decision. Torres acknowledges that teams will not always have time to compare, and says it matters most when the solution carries risk, when the opportunity is a differentiator, or when the team needs an innovative solution (Torres, Opportunity Solution Trees).

The three finalists should be genuinely different. Three variations of one idea share the same assumptions, so testing them teaches little. Distinct approaches, such as a self-serve tool, a service, and a content fix, rest on different assumptions and give the tests something to discriminate between.

Step-by-Step Guide

Step 1: Restate the target opportunity

Write the target opportunity in the customer's voice at the top of the board, with a few lines of context from the interview stories behind it. Remind everyone of the outcome it sits under. Everyone should understand the need before anyone proposes a way to meet it. If people disagree about what the opportunity means, resolve that first.

Step 2: Ideate individually

Give each person quiet time to write ideas on their own, one per note, without discussion. Encourage quantity and unusual ideas, and ask people to hold judgment. Include the trio and anyone else who knows the customer or the technology. Individual ideation avoids the production blocking and conformity that slow group brainstorming.

Step 3: Share and build

Post all ideas on the shared board and let each person read the others. Give a second round of individual ideation, now sparked by what others wrote. Combine and extend ideas freely. Keep going until the group has a long list for this one opportunity.

Step 4: Push past the obvious

If the list is short or similar, use prompts. How does an analogous product in another industry handle this need? What would work for your most extreme user? What would you do with no constraints at all? Add the new ideas to the board.

Step 5: Cluster and remove duplicates

Group ideas that are the same idea written differently, and name each cluster by the approach it represents. Set aside ideas that do not address the target opportunity, and record them in case they fit another opportunity later. You should now see a handful of distinct approaches.

Step 6: Narrow to three distinct solutions

Have each person dot-vote for the ideas they think best address the opportunity, then discuss the top candidates. Choose three that take genuinely different approaches, even if that means passing over a highly voted variation of an idea already chosen. Write each as a short description of what the customer would experience.

Step 7: Add the solutions to the tree

Place the three solutions as children of the target opportunity. Note any obvious risks for each so the next step, assumption testing, has a starting point. Keep the full idea list with the tree, since a failed test may send you back to it.

Best Practices

• Scope ideation to one opportunity. Ideas for different opportunities cannot be compared fairly, which is why Torres advises against brainstorming across the whole tree.
• Separate generating from judging. Evaluating ideas as they appear shuts down the unusual ones before they can spark better ones.
• Invite people outside the trio. Engineers, support staff, and stakeholders see the problem from different angles, and more diverse perspectives produce more diverse ideas.
• Look for different kinds of solutions. Product features, services, content, and process changes can all address the same need.
• Keep stakeholder ideas in the set when they add diversity. Torres notes that "Solution ideas are cheap. The opportunity is what matters" (Torres, Stakeholder Management).
• Save the long list. Ideas that lose now may be the right answer after an assumption test fails.

Common Mistakes

• Starting with one favorite idea: When the team walks in with a solution, ideation becomes a justification exercise. State the opportunity first and require several ideas before discussing any of them.
• Open group brainstorming: Shouting ideas out loud lets a few voices dominate and blocks others from thinking. Start with silent individual ideation.
• Ideating across the tree: Generating ideas for many opportunities at once produces a pile that cannot be compared. Pick the target opportunity first.
• Choosing three versions of the same idea: Near-identical finalists share assumptions, so tests cannot tell them apart. Pick three different approaches.
• Stopping at the first few ideas: The first ideas are usually the obvious ones. Keep going, and use prompts when the group stalls.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Opportunity Solution Tree

Related Skills

• Prioritizing Opportunities Using Customer Evidence
• Designing Assumption Tests for OST Solutions
• Structuring Opportunity Spaces Hierarchically
• Identifying Customer Opportunities from Research
• Defining Measurable Outcomes for Product Discovery
• Maintaining a Living Opportunity Solution Tree
• OST Workshop Facilitation

Sources

• Teresa Torres: How Compare and Contrast Decisions Lead to Better Product Outcomes
• Teresa Torres: Opportunity Solution Trees
• Teresa Torres: CDH Book Club, Supercharged Ideation
• Teresa Torres: Stop Brainstorming and Generate Better Ideas
• Teresa Torres: Why This Opportunity Solution Tree is Changing the Way Product Teams Work
• Teresa Torres: Stakeholder Management for Product Teams
• Wikipedia: Brainstorming

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.