Product discovery
Bandos's branching map is an Opportunity Solution Tree, run live with a team, with AI-generated options at each node and anonymous voting to decide which branch to go down.
The framework, where it came from, and the problem it was designed to solve.
Teresa Torres developed the Opportunity Solution Tree as a core tool in her continuous product discovery practice, formalized in Continuous Discovery Habits (2021). The OST is a visual framework that structures product decisions across four layers, read from top to bottom: a single Outcome (the business result the team is trying to move), Opportunities (customer needs, pain points, and desires that would move that outcome), Solutions (product ideas that address each opportunity), and Experiments (tests that validate the assumptions behind each solution before committing to build it).
The tree's structural contribution is sequencing: it forces teams to prioritize opportunities before they think about solutions. This sounds obvious until you watch a product team in practice. Most sessions begin with someone saying “we should build X” and the rest of the session spent reverse-engineering a problem to justify it. The OST makes that shortcut structurally difficult — you have to place an opportunity in the tree before a solution can branch from it.
Outcome
The business result you're trying to move
Opportunities
Customer needs, pain points, desires
Solutions
Product ideas that address the opportunity
Experiments
Tests that validate solution assumptions
For a full treatment of the framework and how to embed it in ongoing discovery work, Torres's writing at producttalk.org is the authoritative source.
Miro and FigJam can render the tree shape. They can't run the session.
Miro and FigJam can render an OST visually. What they can't do is generate the options at each node, keep the team from jumping layers, or manage convergence when the conversation stalls. Someone still has to drive the session, and without a trained facilitator, most OST attempts collapse into a brainstorm with sticky notes arranged in a vaguely hierarchical shape.
Prioritizing opportunities is where OST adds the most value — and where it's most vulnerable to social bias. When a group converges on which opportunity to pursue through open discussion, the most senior person's preference anchors the result before anyone has formally committed. The tree ends up reflecting one person's conviction, not the group's actual assessment.
A box labeled "Opportunities" gives you nothing to react to. Teams who haven't run exhaustive customer interviews arrive at the session with no raw material and stare at an empty node. Bandos generates 4–6 persona options and job-to-be-done candidates from your company context, so the team is reacting and voting rather than generating from scratch.
The four layers of Torres's framework and how Bandos implements each one in a live session.
The business result you're trying to move
Company goals and constraints
You describe your business model, unique capabilities, and hard constraints. This grounds every subsequent branch in what you can actually build and what success means for your company.
Customer needs, pain points, and desires
Persona + Jobs-to-be-done
Bandos generates 4–6 persona options from your company description. Your team votes anonymously — the winning persona becomes the lens for every subsequent branch. Then it surfaces 4–6 jobs-to-be-done for that persona, and the team votes again to pick the highest-value opportunity.
Product ideas that address the opportunity
Idea branches — Explore → Shape → Define → Experience
Solutions are generated progressively across four levels of detail, from broad directions down to specific execution. At each level, the team votes to pick which branch to deepen. The result is a single winning solution path, not a flat list of ideas.
Tests to validate solution assumptions
Stakeholder pressure-test (adjacent, not equivalent)
Before the session ends, AI reviewers simulate stakeholder perspectives — marketing, engineering, product, UX — and raise the objections your team hasn't considered. This is assumption stress-testing, not real-world user testing. See the divergence section below.
The alignment is real. So are the differences. Here's what Bandos does not do.
Honest differences
Bandos runs a session, not a continuous practice. Torres's OST is designed to be a living document — updated weekly as you run customer interviews, pruned as assumptions get invalidated, and expanded as new opportunities emerge from research. Bandos is a structured 60–90 minute workshop. It produces an OST snapshot, not an evolving discovery system. If your team runs weekly customer interviews and needs to continuously update an opportunity map, Bandos is not the right tool for that workflow.
The Experiments layer is adjacent, not equivalent. In Torres's framework, experiments are real-world tests — assumption mapping, fake door tests, prototype walkthroughs with actual users. Bandos's pressure-test is AI stakeholder simulation: reviewers that role-play as skeptical engineers or budget-conscious PMs and surface objections. That's a useful pre-validation step, but it is not the same as running a test with real customers. It catches obvious blind spots; it doesn't replace discovery interviews.
Bandos generates options — it doesn't synthesize existing research. Torres's OST is typically populated from customer interview data. Bandos generates persona and opportunity options from your company context using AI. If your team has already conducted customer research and needs to synthesize findings into an opportunity map, Bandos will work best as a starting point to react to, not as a replacement for your research synthesis.
A good fit
Not a fit
Related: How Bandos works · Product ideation tool · Anonymous voting tool
Free, no facilitation experience needed. Your team votes on the opportunity — you walk out with a direction.
Start free session