Generating Multiple Solutions for Each Opportunity: Essential Product Manager Skills

This skill teaches you how to apply divergent thinking techniques to brainstorm at least three distinct solution ideas per customer opportunity, preventing premature commitment to a single approach in your Opportunity Solution Tree.

For each customer opportunity on your Opportunity Solution Tree, use divergent thinking techniques — such as brainwriting, reverse brainstorming, and analogy mapping — to generate at least three distinct solution ideas before evaluating any. This prevents premature commitment to a single approach, expands your solution space, and increases the likelihood of discovering a high-impact, feasible solution worth testing.

Outcome: You consistently generate a diverse set of solution ideas for every opportunity, giving your team more options to test and dramatically improving your odds of finding solutions customers actually want.

Synthesized from public framework references and reviewed for accuracy.

ProductIntermediate45-90 minutes per opportunity

Prerequisites

  • Understanding of the Opportunity Solution Tree framework
  • A clearly defined and prioritized customer opportunity
  • Familiarity with basic brainstorming facilitation
  • Access to continuous discovery research or customer insights

Overview

One of the most common failure modes in product discovery is falling in love with the first solution that comes to mind. When a team identifies a compelling customer opportunity, the instinct is to immediately start building the most obvious fix. But the first idea is rarely the best idea. Generating multiple solutions for each opportunity is a core product manager skill that directly combats this tendency by forcing divergent thinking before convergent evaluation.

Within the Opportunity Solution Tree framework, each customer opportunity should branch into at least three distinct solution ideas. This isn't about generating volume for its own sake — it's about expanding the solution space so you can compare genuinely different approaches before committing resources to assumption testing. A team that evaluates three meaningfully different solutions will consistently outperform one that tests variations of a single idea.

This skill draws on structured creativity techniques adapted for product work. You'll learn how to facilitate divergent thinking sessions, how to push past obvious solutions to find novel approaches, and how to ensure your solution set is truly diverse rather than three flavors of the same concept. Mastering this transforms your discovery practice from reactive problem-solving into systematic opportunity exploration.

How It Works

The core principle behind generating multiple solutions is the separation of divergent thinking (generating ideas) from convergent thinking (evaluating ideas). Cognitive science research consistently shows that mixing these two modes — judging ideas while generating them — dramatically reduces both the quantity and quality of output. When someone says "that won't work" during brainstorming, the entire group narrows its thinking.

In the context of the Opportunity Solution Tree, each opportunity node represents a validated customer need, pain point, or desire discovered through continuous research. Solutions are the specific product changes, features, or interventions your team hypothesizes could address that opportunity. The key insight is that a single opportunity can be addressed through fundamentally different mechanisms — a workflow change, an automation, a notification, a UI redesign, a partnership, or even removing a feature.

The "at least three" rule is a forcing function. Three is the minimum because with only two options, teams tend to frame decisions as binary either/or choices. Three or more options create a genuine comparison space where each idea's unique strengths become visible. Research by Paul Nutt on organizational decision-making found that teams considering multiple alternatives made substantially better decisions than those evaluating a single option against a go/no-go threshold.

Divergent thinking techniques work by deliberately disrupting your default patterns. Brainwriting removes social dynamics. Reverse brainstorming reframes the problem. Analogy mapping imports solutions from unrelated domains. Constraint removal asks "what if we had no technical limitations?" Each technique accesses a different part of your team's collective intelligence and produces solutions you wouldn't reach through conventional discussion.

Step-by-Step

  1. Step 1: Frame the Opportunity as a Clear Problem Statement

    Before generating solutions, make sure the entire team shares a precise understanding of the opportunity you're addressing. Pull this directly from your Opportunity Solution Tree, where you've already structured and prioritized your opportunities. Write the opportunity as a customer-centric statement: "Customers struggle to [specific action] because [root cause], which leads to [consequence]."

    Post this statement visibly — on a whiteboard, in your Miro board, or at the top of your collaborative document. Every solution generated must plausibly address this specific opportunity. This prevents scope creep during brainstorming and ensures your divergent thinking stays productively anchored.

    Tip: If your team can't agree on the opportunity statement, that's a signal you need to go back to your research. Generating solutions for a vaguely defined opportunity produces vaguely useful ideas.

  2. Step 2: Set Divergent Thinking Ground Rules

    Explicitly establish the rules of divergent thinking before you begin. These aren't optional nice-to-haves — they're the structural conditions that make the technique work:

    • Defer judgment entirely. No evaluating feasibility, effort, or likelihood of success during generation. Write down "We are NOT evaluating yet" where everyone can see it.
    • Quantity over quality. The goal is volume. Bad ideas often contain seeds of great ones.
    • Build on others' ideas. "Yes, and..." thinking is encouraged. Combining or riffing on someone else's idea counts as a new solution.
    • Seek wild ideas. The most impractical-sounding idea might reveal an approach nobody considered.

    Make these explicit every time. Even experienced teams slip into evaluation mode if you don't actively protect the divergent space.

    Tip: Assign a dedicated 'divergence guardian' — someone whose job is to call out any premature evaluation. Rotate this role across sessions.

  3. Step 3: Use Brainwriting to Generate an Initial Set

    Start with brainwriting (also called 6-3-5 or silent brainstorming) rather than verbal brainstorming. Each team member independently writes down three solution ideas in five minutes. This neutralizes anchoring bias — the tendency for the first idea spoken aloud to dominate all subsequent thinking.

    Use sticky notes, index cards, or a collaborative tool where everyone writes simultaneously without seeing others' contributions. After the silent round, have each person share their ideas one at a time, briefly describing each without defending or explaining at length. Collect all ideas visibly.

    For a team of four, this initial round alone should produce 10-12 ideas (accounting for some overlap). Don't worry about duplicates yet — similar ideas from different people often have subtle but important differences worth preserving.

    Tip: If working remotely, use a tool like FigJam or Miro with a timer. Have everyone keep their cursors in separate areas until the reveal.

  4. Step 4: Apply Structured Creativity Techniques to Push Beyond the Obvious

    The initial brainwriting round captures the ideas your team already had in their heads. Now push further with structured techniques that access less obvious thinking:

    Reverse Brainstorming: Ask "How could we make this problem WORSE?" Generate ideas for amplifying the customer's pain, then flip each one into a potential solution. If "adding more steps to the workflow" worsens the problem, the inverse — eliminating steps entirely — becomes a solution candidate.

    Analogy Mapping: Ask "What other domain has solved a similar problem?" If customers struggle to find relevant content, look at how Spotify recommends music, how librarians curate reading lists, or how sommeliers suggest wine pairings. Import the mechanism, not the specific implementation.

    Constraint Removal: Ask "What would we build if we had unlimited engineering resources? No legal constraints? No legacy system?" Then ask which elements of that unconstrained solution could be approximated within real constraints.

    Spend 10-15 minutes on each technique. The goal is to generate solutions that are structurally different from your initial set — different mechanisms, different touchpoints, different mental models.

    Tip: Analogy mapping is the most powerful technique for producing genuinely novel solutions. Keep a running list of industries and domains your team can reference as analogy sources.

  5. Step 5: Cluster and Deduplicate into Distinct Solution Concepts

    With 15-25+ raw ideas on the board, it's time to organize without yet evaluating. Group ideas that share the same underlying mechanism or approach. For example, three ideas that all involve sending notifications are really one solution concept with three variations.

    Label each cluster with a descriptive name that captures the core mechanism: "Proactive notification system," "Self-service configuration tool," "Peer-to-peer recommendation engine." These clusters are your distinct solution concepts.

    Check: are your clusters genuinely different from each other? The test is whether they could coexist — if two "different" solutions are mutually exclusive variations of the same approach, they're one concept with options, not two distinct solutions. You want at least three clusters that represent fundamentally different ways to address the opportunity.

    Tip: If all your clusters feel similar, go back to Step 4 and try a different creativity technique. Same-shaped solutions usually mean you haven't broken free of your team's default mental model.

  6. Step 6: Enrich Each Solution Concept with a One-Pager

    For each of your top three to five solution concepts, write a brief one-pager (or one sticky note, or one card in your tool) that captures:

    • What it is: A one-sentence description of the solution mechanism
    • How it addresses the opportunity: The causal logic connecting this solution to the customer need
    • Key assumptions: What must be true for this solution to work? (These feed directly into your assumption testing process)
    • What makes it different: Why this approach is distinct from the other solution concepts

    This isn't detailed specification — it's just enough articulation that someone who wasn't in the brainstorming session could understand each concept and see how they differ. This documentation also ensures the ideas survive beyond the brainstorming session.

    Tip: The 'key assumptions' field is the most important. It creates a direct bridge to the next step in the Opportunity Solution Tree: designing experiments to test whether each solution could actually work.

  7. Step 7: Add Solution Branches to Your Opportunity Solution Tree

    Map each distinct solution concept as a branch under its parent opportunity in your Opportunity Solution Tree. This visual representation accomplishes several things: it shows stakeholders that you're exploring multiple paths, it maintains traceability from outcome to opportunity to solution, and it sets up the comparison framework for your upcoming assumption tests.

    Each solution branch should be labeled clearly and linked to its one-pager. If you're maintaining a living OST, add these branches in your regular cadence rather than waiting for a big reveal.

    At this point — and only at this point — you can begin convergent thinking. Discuss which solutions seem most promising to test first, but frame this as prioritizing experiments, not picking winners. The solutions you don't test first aren't killed — they remain on the tree as alternatives if your first experiments don't validate.

    Tip: Never delete solution branches from your OST just because they weren't tested first. Teams frequently circle back to 'backup' solutions when initial assumptions are invalidated.

Examples

Example: E-Commerce Team Addressing Cart Abandonment

A product team at an e-commerce company has identified the opportunity: 'Customers abandon their cart when they encounter unexpected shipping costs at checkout, leading to lost conversions.' This opportunity was surfaced through continuous discovery interviews and validated with quantitative data. The team needs to generate multiple solutions before committing to assumption tests.

The team runs a 60-minute solution generation session. During brainwriting, they capture 14 initial ideas. After clustering, they identify five distinct solution concepts:

  1. Shipping cost estimator on product pages — Show estimated shipping cost before the customer reaches checkout, eliminating the surprise entirely.
  2. Free shipping threshold nudge — Display a progress bar showing how close the customer is to qualifying for free shipping, reframing the cost as an avoidable fee.
  3. Subscription-based free shipping — Offer an annual membership (like Amazon Prime) that eliminates shipping costs for members.
  4. Local pickup network — Partner with physical retail locations for free in-store pickup, removing shipping cost entirely for customers near a partner store.
  5. Transparent total price display — Redesign product cards to always show the total price including shipping, so there's never a 'surprise' — the product price absorbs the shipping cost perceptually.

Each concept addresses the same opportunity through a fundamentally different mechanism: pre-informing, incentivizing a higher cart value, subscription bundling, logistics redesign, and price presentation. The team documents key assumptions for each (e.g., 'Customers will increase their cart size to hit a free shipping threshold' for concept #2) and adds all five as solution branches to their OST. They then prioritize which assumptions to test first.

Example: SaaS Onboarding Drop-Off

A B2B SaaS product team has identified the opportunity: 'New users fail to complete setup because they don't understand which integrations are relevant to their workflow, causing them to abandon onboarding.' The team is tempted to just build a better setup wizard, but commits to generating multiple solutions first.

Using reverse brainstorming, the team first asks: 'How could we make integration selection even MORE confusing?' Ideas include 'show all 200 integrations at once,' 'use only technical jargon,' and 'require users to configure settings they don't understand.' Flipping these produces solution candidates.

They then use analogy mapping, looking at how Netflix recommends shows (collaborative filtering), how a doctor triages symptoms (guided diagnostic), and how IKEA uses room displays (contextual showcasing). This yields three distinct solution concepts:

  1. Guided diagnostic flow — Ask 3-4 questions about the user's role and workflow, then auto-recommend a specific integration bundle. The user just confirms.
  2. Peer-based recommendation engine — Show 'Teams like yours typically use these integrations' based on company size, industry, and role data collected at signup.
  3. Integration-free quick start — Let users skip integrations entirely and start with manual data entry or CSV upload. Introduce integrations later when the user has enough context to understand their value.

Solution 3 was the unexpected breakthrough — the team had assumed integrations were essential for onboarding, but the reverse brainstorm revealed that forcing integration choice upfront might itself be the problem. They add all three solutions to the OST and design experiments for each.

Best Practices

  • Always generate solutions in a time-boxed session with clear divergent-then-convergent phases — never combine ideation and evaluation in the same conversation.

  • Include at least one person from a different discipline (engineering, design, support, sales) in every solution generation session to prevent product manager tunnel vision.

  • Aim for at least three solutions that differ in mechanism, not just magnitude. 'Send one email' vs. 'send three emails' is not two distinct solutions — it's one solution with a parameter to test.

  • Reference actual customer quotes and research artifacts during brainstorming to keep solutions grounded in real needs rather than team assumptions.

  • Keep a 'solution library' of past ideas that weren't tested — these are valuable starting points for future opportunities and prevent re-inventing discarded concepts.

  • After generating solutions, explicitly ask 'What approach would a competitor or a startup with no legacy constraints take?' to stress-test whether you've explored the full solution space.

Common Mistakes

Generating three variations of the same approach and calling them 'multiple solutions'

Correction

Test distinctness by asking: 'Do these solutions use fundamentally different mechanisms?' Three UI layout options for the same feature are one solution with design variations, not three solutions. Push for solutions that differ in how they address the opportunity, not just what they look like.

Allowing the most senior person or the loudest voice to anchor the entire brainstorming session

Correction

Always start with silent individual ideation (brainwriting) before any verbal sharing. Have the most senior person share last. This structurally prevents anchoring bias and ensures diverse input.

Evaluating feasibility during the divergent phase and killing ideas before they're fully formed

Correction

Strictly separate generation from evaluation. If someone says 'That's too expensive' or 'Engineering will never go for that,' redirect them: 'We'll evaluate feasibility later — right now we're just capturing possibilities.' An 'infeasible' idea often contains a kernel that inspires a feasible breakthrough.

Skipping solution generation because the team already 'knows' the right answer

Correction

This is the single biggest trap. The 'obvious' solution often reflects the team's existing mental model, not the best approach. Mandate the process even when (especially when) everyone thinks the answer is clear. Teresa Torres calls this 'compare and contrast' — you can't know you have the best idea if you haven't generated alternatives.

Generating solutions without a clearly framed opportunity, leading to scattered ideas that don't connect to customer needs

Correction

Always start with a specific, well-articulated opportunity statement derived from customer research. If the opportunity is vague, invest time in sharpening it first. Solutions without a clear problem anchor are features in search of a purpose.

Frequently Asked Questions

How many solutions should I generate per opportunity in my Opportunity Solution Tree?

Aim for a minimum of three genuinely distinct solutions per opportunity. Three is the floor because it prevents binary either/or thinking and creates a real comparison space. Five to seven is ideal for important opportunities. Beyond that, you're likely generating variations rather than distinct concepts.

What's the best brainstorming technique for product managers generating solutions?

Brainwriting (silent individual ideation followed by group sharing) is the most reliable starting technique because it prevents anchoring bias. Follow it with reverse brainstorming or analogy mapping to push beyond obvious ideas. The combination of two techniques consistently produces more diverse solutions than any single approach.

How do I know if my solutions are different enough from each other?

Apply the mechanism test: do your solutions address the opportunity through fundamentally different approaches? If you could combine two solutions without conflict, they're likely distinct. If they're mutually exclusive variations of the same approach (e.g., two different notification designs), they're one solution with design options to test.

Can I generate solutions alone or do I need a team?

You can generate solutions individually, but cross-functional teams consistently produce more diverse and higher-quality solution sets. At minimum, include one person from a different discipline — an engineer, designer, or customer-facing team member — to break out of your own mental model.

How long should a solution generation session take?

A focused session typically takes 45-90 minutes per opportunity. Budget 5 minutes for framing, 10-15 minutes for brainwriting, 20-30 minutes for structured creativity techniques, 10-15 minutes for clustering, and 10-15 minutes for documenting solution concepts. Shorter sessions tend to produce only surface-level ideas.

What do I do with solutions that don't get tested first?

Keep them on your Opportunity Solution Tree as alternative branches. Never discard untested solutions. If your first-choice solution fails assumption testing, these alternatives become your next experiments. Teams frequently find that their second or third solution concept outperforms the one they initially favored.