Solution

Origin & evolution

The idea that you should diverge before you converge predates product management; it is the spine of design thinking. In the ideation stage, teams are coached to generate as many candidate approaches as possible in a judgment-free space, then narrow with convergent thinking to the strongest few. IDEO built its practice around iterative prototyping and rapid generation of alternatives, and the broader design-thinking literature frames divergence as a deliberate guard against premature commitment.

Product discovery absorbed this and gave it structure. In Teresa Torres's Opportunity Solution Tree, solutions are the third layer: each opportunity branches into multiple candidate solutions, and each solution branches into the assumptions🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference → that must hold for it to work. The tree makes the plurality rule visible. An opportunity with a single solution hanging off it signals that the team stopped exploring too early, or that the "opportunity" was a solution all along. Solutions stay provisional until assumption tests survive contact with users, at which point one graduates into something the team actually builds.

The field's settled view is that the cost of a wrong solution is paid in build time, so the cheapest place to be wrong is on paper, among several options, before a line of code. Generating alternatives is insurance against the sunk-cost gravity of the first plausible idea.

How it works in practice

Take the activation opportunity "I want to see the product working with my own data without waiting on my IT team." Instead of jumping to a build, the team puts three solutions on the tree. A delegated-invite flow that lets a trial user request a one-click connection from their admin. A read-only demo workspace pre-loaded with a realistic dataset. A guided CSV import for users who can export their own data. Each carries a riskiest assumption: that admins respond in time, that demo data feels real enough to convince, that users can find an export button. The team runs cheap tests on all three over a fortnight. The demo workspace lifts perceived value but not real conversion; the delegated invite stalls on slow admins; the CSV import quietly converts. Two solutions die honestly, one survives the evidence, and only that one becomes a feature⭐FeatureProduct SpecificationA product capability or featureView reference →.

Solution vs. its neighbours

• Feature is a solution that has been committed to and built; a solution is the candidate stage before that commitment. The graph encodes the graduation directly as solution_becomes_featureSolutionbecomesFeaturecausal, marking the moment a bet stops being provisional.
• Hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → is the testable claim a solution rests on ("if admins get a one-click request, 60% respond within a day"). The solution is the approach; the hypothesis is the assumption that decides whether it lives. The graph wires this as solution_proposes_hypothesisSolutionproposesHypothesiscausal.
• Opportunity is the gap the solution addresses, and one opportunity should carry several solutions. Reversing the dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference →, building first and finding the opportunity later, is how teams ship features nobody needed.
• Prototype📱PrototypeExperience DesignAn interactive mockup for testingView reference → is a low-cost embodiment of a solution made to test it, not the solution itself. The graph keeps them distinct through solution_materialises_as_prototypeSolutionmaterialises asPrototypehierarchy, so the throwaway artefact never gets mistaken for the committed approach.

In the graph

The solution lives in the Discovery, Research & Validation region as a container, fed by its opportunity through opportunity_drives_solutionOpportunitydrivesSolutioncausal. Its outbound edges trace the full path from idea to validated bet: solution_proposes_hypothesisSolutionproposesHypothesiscausal exposes the assumption, solution_materialises_as_prototypeSolutionmaterialises asPrototypehierarchy makes it testable, solution_addresses_needSolutionaddressesNeedcausal ties it to the user, and solution_becomes_featureSolutionbecomesFeaturecausal carries the survivor across the border into the Product & Delivery region. Modelling solutions as their own entities, plural beneath each opportunity, is what lets the graph show at a glance whether a team explored the option space or committed to the first idea it had.