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 because 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 project 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.
The business result you're trying to move
Venture goals and constraints
You describe your vision, available strengths, and project boundaries. This grounds every subsequent branch in what you can actually build and what success means for your project.
Customer needs, pain points, and desires
Persona + Jobs-to-be-done
Bandos generates 4–6 persona options from your project description. Your team votes anonymously, and 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 → Surface → Structure → Polish
Solutions are generated progressively across six phases of detail, from strategic directions down to UX-level execution. At each phase, 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
Customer validation surveys (adjacent, not equivalent)
From any node on the map, you can generate a structured survey built from your specific assumptions and share the link with real potential customers. Responses flow back and, if they invalidate your direction, Bandos generates a corrected path. This is lightweight survey-based validation, not the full experiment design of continuous discovery. 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 offers customer validation surveys generated from any node on your map and shared with real potential customers. That is lightweight survey-based validation, useful for catching invalidated assumptions before you build, but it does not replace the depth of discovery interviews or prototype walkthroughs.
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 project 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
Free, no facilitation experience needed. Your team votes on the opportunity, and you walk out with a direction.
Start free session