# Using feedback to build an opportunity solution tree > An opportunity solution tree is a one-page map with a measurable outcome at the top, customer opportunities below it, and candidate solutions and small tests under each opportunity. Feed it with grouped feedback, and keep it to one outcome, three or four opportunities and two solutions each. Source: https://escutaproduto.com/resources/opportunity-solution-tree-feedback Last updated: 2026-10-11 ## What is an opportunity solution tree? An opportunity solution tree is a simple map that connects a product outcome to the customer needs that could move it, and then to the solutions and tests that address each need. It was popularized by Teresa Torres in her work on continuous discovery. The structure is the useful part: one outcome at the top, opportunities in the middle, solutions and experiments at the bottom. Feedback fits naturally into the middle layer. Customers tell you what gets in their way, which is what an opportunity is. The tree keeps you from jumping from a single request straight to a feature, and it shows whether your work still moves the outcome you care about. ## How do you set the outcome first? Start with one outcome you can measure, and that a team can influence in a few weeks. A good outcome names a behavior and a direction, such as "more new teams finish setup in their first week" or "fewer checkout sessions end on an error page." A bad outcome is a feature ("launch the dashboard") or a vague wish ("make customers happier"). Write the outcome in one sentence at the top of a page. Everything below it must plausibly move that number. If a branch does not, it does not belong in this tree, however loud the request. ## How do feedback items become opportunities? Take the grouped feedback from the period and rewrite each cluster as an opportunity: a customer need, described from the customer's side, that stands between them and the outcome. Opportunities are not solutions. "Teams cannot tell which setup step is stuck" is an opportunity. "Add a progress bar" is a solution. Good sources for opportunities are the job statements you have written, bugs that block the outcome, and requests that appear across several distinct customers. Keep the number of opportunities small. Three to five at a time is enough to focus a team. Each opportunity should carry evidence: how many distinct customers raised it, and what the usage data shows. The [jobs to be done guide](/resources/jobs-to-be-done-from-feedback) explains how to phrase the need so it reads as a customer problem. ## How do you branch into solutions and tests? For each opportunity, list two or three possible solutions. Different solutions for the same need are the point of the branch. If you can only think of one, you have not explored the need yet. Then attach the smallest test that could show whether a solution works. A test might be a prototype shown to five customers, a manual process run for a week, or a change behind a flag for a few accounts. Write the success signal before you run the test, so the result is judged against something agreed in advance. Keep the tests cheap. A tree full of multi-month builds is hard to update and tempting to defend. Small tests produce faster evidence and let you drop a branch without drama. ## A worked example from twelve feedback items For example, suppose the outcome is "more new teams finish setup in their first week," and a month of feedback contains twelve items about onboarding. The team groups them into three opportunities. - Opportunity A: new users cannot tell which setup step is still missing. Seven items, from five distinct customers. - Opportunity B: the install instructions do not match their framework. Three items, from three customers. - Opportunity C: the invite email arrives late. Two items, from two customers. Under opportunity A, the team lists two solutions: a checklist on the first screen, and a short banner after each step. The test for the checklist is a clickable prototype shown to four new users, with a note of where each one hesitates. Under opportunity B, the solution is a framework-specific install page, tested by having one developer install it on their own project. Opportunity C has one solution and a test of the email log, which costs little and answers the question. The tree is now small enough to read in a minute, and each branch has a next step with a clear signal to look for. ## How do you keep the tree small? A tree grows quickly if you let it. Use four rules to keep it useful: 1. One outcome per tree. If you have two outcomes, you have two trees. 2. Three to five opportunities at a time. Park the rest in a list. 3. Two solutions per opportunity, unless the first test answers the question. 4. Prune every two weeks. Remove branches whose tests have run, and record what you learned. Pruning is where feedback earns its keep. Each closed branch should leave a note: what the test showed, and whether the opportunity still matters. The [weekly feedback review template](/resources/weekly-feedback-review-template) has a slot for these notes. ## Linking tree nodes to feedback in Escuta Produto Escuta Produto does not draw trees, so keep the tree in your usual planning tool and link it back to the inbox with notes. For each opportunity, search the inbox for the customer's words, list the matching items, and write the count of distinct customers in an internal note on the most representative item. Set the status to planned when a solution is committed, in progress while the test runs, and done once the outcome has been checked. The [RICE prioritization guide](/resources/rice-prioritization-feedback) helps you choose between two opportunities that both look worth testing, and the [widget docs](/docs/widget) explain how new feedback arrives with the page the customer was on, so you can check whether an opportunity is still active after a change. ## Frequently asked questions ### What is an opportunity solution tree? It is a one-page map with a measurable outcome at the top, customer opportunities beneath it, and candidate solutions and small tests under each opportunity. It keeps the team focused on the outcome rather than on individual feature requests. ### How is an opportunity different from a solution? An opportunity is a customer need or problem, described from the customer's side. A solution is one way to address it. Feedback usually arrives as solutions, so rewriting each request as an opportunity is the step that opens up better options. ### How big should an opportunity solution tree be? Keep it small: one outcome, three to five opportunities, and two solutions for each. A small tree is easy to review every two weeks and easy to prune when a test shows a branch is not worth pursuing. ### Can feedback alone build an opportunity solution tree? Feedback is a strong source of opportunities, but combine it with usage data and direct conversations. Feedback shows what customers complain about, while usage shows how often a need occurs across the base.