The tree's four levels

Overview

Lesson 1 left you with a disorganized notebook and the promise to organize it. This lesson delivers on the first part of that promise: it gives you the opportunity solution tree's exact shape — the four levels, what order they go in, and what kind of thing lives at each one. You're not going to build Mercado's full tree yet —that takes the rest of the module—, but by the end of this lesson you'll be able to look at any phrase ("raise GMV", "I can't find what I'm looking for", "show recommendations", "a fake door at checkout") and know, immediately, which level of the tree it belongs to.

The four levels are these, top to bottom:

outcome
   |
   +-- opportunity
   |      |
   |      +-- solution
   |             |
   |             +-- experiment

Outcome: the business number the team is chasing — it's at the top because it's the starting point, not this lesson's result; you already inherited it from product-thinking-for-engineers. Opportunity: a real user need, pain point, or gap — discovered in interviews (module 2), not invented in a meeting room. Solution: a concrete idea for tackling a specific opportunity — there can be several per opportunity. Experiment: the cheap way to test whether a solution really works, before building it in full — the detail of how to design it is module 4, but the node already exists at this level.

How this connects to the module. This lesson is the full map before getting into the detail: lessons 3 through 6 are going to take, one by one, each of these four levels and dig into what makes it valid (an outcome that's actually an output, an opportunity that's actually a disguised solution, a solution with no real opportunity behind it). Without seeing the full shape first, those lessons would feel like loose pieces; with today's map, each one fits into a specific place.

An everyday analogy: why you're not losing weight

Think of any personal goal: "lose 5 kilos this year". That goal, on its own, doesn't tell you what to do Monday morning — you need to drop a level and ask yourself why you haven't achieved it yet. That's where several real reasons show up, each different: "I eat too much dessert at night", "I don't exercise during the week", "I sleep badly and that makes me hungrier". Each of those reasons —each opportunity, in this module's vocabulary— allows for several different solutions. For "I eat too much dessert at night", you could stop buying it at the store, or replace it with fruit, or simply eat dinner earlier so you're not hungry late. And before overhauling your whole routine around one of those solutions, you'd try it small: a week without buying dessert, and see if anything really changes, before committing for the whole year.

Notice the structure: the goal at the top ("lose 5 kilos") doesn't change depending on which solution you pick — it's still the same number at the end of the year. What changes, level by level, is how concrete the action is: a real reason why you're not losing weight (opportunity), an idea for tackling that specific reason (solution), and a small test before you commit fully (experiment). A product team's opportunity solution tree has exactly this shape — except the goal at the top is a business number, and the reasons below are real user needs, discovered in interviews instead of personal introspection.

Worked example: a single path, start to finish

Before building Mercado's full tree —with several opportunities and several solutions per opportunity, which you're going to build throughout the module—, it's worth seeing a single complete path, from root to leaf, to confirm the four-level shape makes sense. We write a printTree() that simply walks the tree and prints it with indentation — it doesn't validate anything yet (that comes in lesson 5, with validateTree); today the goal is just to see the shape.

// printTree: just prints the tree's 4 levels, without validating anything
// yet (that comes in lesson 5, with validateTree). For now the goal is to
// see the full shape: outcome -> opportunity -> solution -> experiment.
function printTree(tree) {
  console.log('outcome: ' + tree.outcome);
  tree.opportunities.forEach((opp) => {
    console.log('  opportunity: ' + opp.problem);
    opp.solutions.forEach((sol) => {
      console.log('    solution: ' + sol.idea);
      sol.experiments.forEach((exp) => console.log('      experiment: ' + exp));
    });
  });
}

const oneBranch = {
  outcome: '+GMV via checkout conversion',
  opportunities: [
    {
      problem: "I don't discover products I'd like without searching for the exact name",
      solutions: [
        {
          idea: 'personalized recommendations on the home page and checkout',
          experiments: ['fake door in the checkout'],
        },
      ],
    },
  ],
};

console.log('=== One branch of Mercado\'s tree ===\n');
printTree(oneBranch);

What to expect. When you run the file with Node, the output is exactly this:

=== One branch of Mercado's tree ===

outcome: +GMV via checkout conversion
  opportunity: I don't discover products I'd like without searching for the exact name
    solution: personalized recommendations on the home page and checkout
      experiment: fake door in the checkout

Read it top to bottom, like a complete sentence: the outcome is raising GMV through higher checkout conversion; an opportunity that explains it is that buyers don't discover products they'd like without searching for the exact name; a solution for that specific opportunity is showing personalized recommendations on the home page and checkout; and a cheap experiment to test that solution, before building the full engine, is a fake door at checkout. This is, literally, the path underlying the recommendations bet from the previous guides — except now it's written out with its full structure, not as a loose sentence.

Why each level is a different kind of thing

It's worth saying directly, because it's the source of the module's most common mistake (lesson 4 goes into it in depth): these four levels aren't interchangeable. An outcome is a metric — something measurable that can go up or down (+GMV). An opportunity is a user need — something happening to a real person, almost always discovered by listening, not invented in a meeting room. A solution is a product idea — something the team could build. And an experiment is a cheap action — something you can run in days, not months, to get a signal on whether the solution above is worth it. Confusing two levels —treating a solution as if it were an opportunity, or an experiment as if it were an outcome— breaks the tree's entire usefulness, because it's no longer clear what justifies what.

Common mistakes

Starting to fill in the tree from the middle, skipping the outcome. What happens: a team excited about a solution idea (for example, "recommendations") jumps straight there, and only afterward, if at all, asks itself what outcome it's chasing or what opportunity justifies it. Why it happens: solutions are the tree's most concrete, most easily imaginable part — it's much more natural to think about features than about business metrics or user needs. How to spot it: if you ask the team "and what outcome does this move, and for what opportunity?", the answer gets made up on the spot, instead of coming from a tree that's already built. How to fix it: the tree always gets read top to bottom, never bottom to top — first the outcome (you already have it, from the previous guide), then the real opportunities (module 2), and only then the solutions.

Treating the four levels as if they were interchangeable synonyms. What happens: in a meeting, someone calls "opportunity" what's actually a solution ("the opportunity is showing recommendations"), or calls "experiment" what's actually the full solution, unproven ("the experiment is launching the recommendations engine"). Why it happens: the vocabulary is new, and in everyday language "opportunity" and "solution" sometimes get used as vague synonyms for "good thing we could do". How to spot it: ask yourself, about whatever was just said, "is this something that happens to the user, something the team could build, or a cheap way to test it?" — if the answer isn't clear, the level is mislabeled. How to fix it: come back to this lesson's diagram whenever you're unsure — an outcome is a metric, an opportunity is a need, a solution is a product idea, an experiment is a cheap action. All four are different kinds of things, not synonyms.

Believing the tree has a single path, start to finish. What happens: seeing today's worked example —a single outcome → opportunity → solution → experiment—, someone assumes Mercado's full tree looks just as simple: a single straight line. Why it happens: the first example, for teaching clarity, shows a single path — but a real tree is almost never a line; it's, literally, a tree, with several branches at each level. How to spot it: the team's "tree" has a single opportunity, with a single solution, with a single experiment — no alternative considered at any level. How to fix it: lessons 5, 6, and 7 of this module are going to build Mercado's full tree with several opportunities, several solutions per opportunity, and several candidate experiments per solution — an opportunity solution tree's real shape, not the single-path version you saw today just to learn the structure.

Exercises

Exercise 1 — Label each phrase with its level. For each of these phrases about Mercado, say which level of the tree it belongs to (outcome, opportunity, solution, or experiment):

• (a) "+GMV via checkout conversion"
• (b) "I don't trust new sellers without reviews"
• (c) "show a verified-seller badge"
• (d) "clickable prototype of the product page with the badge, shown to 15 buyers"

See solution

• (a) outcome. It's a business metric, the number at the top of the tree.
• (b) opportunity. It describes something happening to a real user — a gap, without yet proposing what to do about it.
• (c) solution. It's a concrete product idea — a specific answer to (b)'s opportunity.
• (d) experiment. It's the cheap way to test whether (c)'s solution works, before building it in full.

Exercise 2 — Find the skipped level. A teammate says: "Let's build recommendations because that raises GMV." Without running anything, identify which level of the tree that sentence skips, and rephrase it filling in the missing level.

See solution

The sentence jumps straight from solution (recommendations) to outcome (GMV), skipping opportunity — it doesn't say why recommendations would raise GMV, that is, what real user need they're tackling. A complete rephrasing: "Buyers don't discover products they'd like without searching for the exact name (opportunity) — we're going to build recommendations (solution) to tackle that opportunity, which should raise GMV via checkout conversion (outcome)". The complete version doesn't just sound more rigorous — it lets you, if the experiment fails, know exactly which opportunity is still unsolved and try a different solution for the same opportunity, instead of abandoning the whole opportunity.

Exercise 3 — Draw your own personal one-level tree. Using this lesson's "losing weight" analogy (or any personal goal of your own), write a complete four-level path — your own outcome, a real opportunity, a solution for tackling it, and a cheap experiment for testing it before committing fully.

See solution

There's no single correct answer —the exercise is personal—, but a reasonable example, following the lesson's analogy: outcome: "sleep at least 7 hours most nights". opportunity: "I check my phone in bed before sleeping and that costs me over an hour". solution: "leave the phone charging in another room overnight". experiment: "try it for 5 nights this week and note what time I fall asleep each night, before buying a separate alarm clock so I don't depend on the phone". The point of the exercise: the same four-level structure you're going to use for Mercado works just as well for any goal with a real reason behind it, a concrete idea, and a cheap way to test it before committing.

Summary and next step

In this lesson you learned the opportunity solution tree's full shape: four levels —outcome, opportunity, solution, experiment—, each a different kind of thing, one hanging off the previous one. You saw printTree() walk a single complete path of Mercado's tree, from "+GMV via checkout conversion" down to "fake door at checkout", passing through the opportunity and solution in between. And you saw, in the common mistakes, why confusing levels —or skipping one— breaks the tree's entire usefulness.

Before moving on you should be able to: name the four levels in order; explain in your own words what different kind of thing lives at each one; and, given any phrase about a product bet, say which level it belongs to.

Lesson 3 stops at the top level —the outcome— because it's easier than it looks to get that wrong: you're going to see, with an executed model, how to tell a real outcome apart from an output disguised as an outcome.

Resources

• Product Talk, "Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes" — producttalk.org/opportunity-solution-trees. The article illustrating the tree's full shape with real diagrams — the same one you saw today, applied to real product cases. In English.
• Product Talk, glossary — "Opportunity Solution Tree" — producttalk.org/glossary-discovery-opportunity-solution-tree. The short, precise definition of each of the four levels, useful as a quick reference while you build your own tree. In English.
• Marty Cagan (SVPG), "Product Discovery" — svpg.com/product-discovery. On why discovery starts with an opportunity assessment, before moving on to the solution — the same level order that structures this module. In English.