Product Discovery: Continuous Discovery, User Interviews and the Opportunity Solution Tree

Version note: This post is conceptual; the Opportunity Solution Tree and continuous discovery follow Teresa Torres's Product Talk articles (December 2023 update) and her book "Continuous Discovery Habits" (2021).

Guess First

To understand the cart abandonment problem, the Bookstore team decided to interview six customers who abandoned their cart in the last month. A developer on the team prepared the interview questions:

• If there were one-click checkout, would you have completed your purchase?
• Do you like our site, and what would you like us to improve?
• Is the shipping fee important to you?
• When did you last buy a book online, and what did you buy? Could you walk us through that purchase from the start?

Which of these four questions actually produces useful information? Which answers could you have guessed before the interview? And consider this: if "the shipping fee is too high" comes up in four of the six interviews, does that mean we should lower the shipping fee?

Continuous Discovery

Product discovery is the work of deciding what we should build; delivery is the work of building it and getting it to customers. In many teams discovery is an "analysis phase" at the start of a project: a few weeks of research, a document, then months of delivery. In "Continuous Discovery Habits," Teresa Torres proposes a continuous practice instead: the team building the product has touchpoints with its customers at least weekly and runs small research activities in pursuit of a desired outcome.

A weekly touchpoint may sound like a lot, but we're talking about something small: a 30-minute interview, trying a prototype with five customers, a session reading support tickets. What matters is the rhythm: discovery stops being a phase and becomes work that flows every week alongside delivery. Torres also stresses that the product team itself should do the interviews, so findings don't arrive as a report from a research team: the product manager, the designer and at least one engineer.

Good Interview Questions: Ask About the Past, Don't Ask for the Future

Of the four opening questions, only the last one is really useful. The first three share a problem: they ask the customer for a prediction or an opinion. Most people politely answer "yes" to "If there were one-click checkout, would you have completed your purchase?"; but people are bad at predicting their future behavior and tend to want to please the interviewer. The answer to "Is the shipping fee important to you?" is known in advance too: nobody says "no, I never look at the shipping fee."

Rob Fitzpatrick's 2013 book "The Mom Test" describes this trap well: if you ask your mom about your business idea, she won't lie to you, but she'll like your idea so as not to hurt you. The fix is to ask about concrete past behavior instead of ideas or opinions. Torres calls this story-based interviewing: questions that start with "Tell me about the last time..." and invite the customer to walk through a real moment from start to finish.

A better flow for the Bookstore interview goes like this: "Can you tell me about the last time you bought a book online? Who was it for? Where did you search? What happened after you added it to the cart?" Then follow-up questions from inside the customer's story: "What did you think when you saw the shipping fee at that moment? What did you do next?" These questions don't imply a solution, don't put an answer in the customer's mouth, and tell you what really happened.

If you are going to record the interview, ask for permission in advance and say who will keep the recording, and for how long. Don't keep personal data such as the customer's name, e-mail or order number in your interview notes; a summary of the story and a customer code are enough.

The Opportunity Solution Tree

Findings from interviews, support tickets and data have to be gathered in one place so the team can decide which to focus on. Torres's Opportunity Solution Tree (OST) is a visualization for exactly that, with four levels:

The root of the tree is the outcome, and it sets the scope of discovery. Torres makes a distinction here: business outcomes (revenue, churn) measure the health of the business, but the team can't move them directly; product outcomes measure customer behavior inside the product and, as a general rule, suit the root of the tree better. Bookstore's root is a product outcome: cut cart abandonment from 66.7% to 60%.

The second level is opportunities: a customer's unmet need, pain point or desire. An opportunity is not a solution. Torres's simple test is: "Is there more than one way to address this opportunity?" "I give up when I see the shipping fee at the last step" is an opportunity, because you can address it with many different solutions. "Show the shipping fee on the product page" is a solution. Opportunities should come from interviews, not from the team's heads; Torres suggests revisiting the opportunity space every three or four interviews.

The third level is solutions, but only for the chosen target opportunity. The team doesn't generate solutions for every opportunity in the tree; it picks one and considers several alternative solutions for it. Torres recommends comparing at least three solutions; falling in love with a single solution is the most common discovery mistake.

The fourth level is assumption tests. Every solution rests on a set of assumptions, and instead of building the whole solution the team tests the riskiest assumption cheaply. The results guide the next decision: drop the idea, develop one for delivery, or pick a new target opportunity.

Bookstore's Tree

Six interviews, the last three months of support tickets and the funnel split by segment produced three opportunities. The first is the surprise shipping fee: four of the six people interviewed described a moment when they gave up after seeing the shipping fee once the book was in the cart. The second is mandatory sign-up: guests who don't want to create an account for a single book; in the funnel, guest abandonment is 72.1% versus 56.3% for registered customers. The third is typing card details every time; this came only from registered customers, and it is exactly the opportunity the general manager's one-click checkout idea addresses.

The team chose the surprise shipping fee as the target opportunity, because it came up most often in the interviews and affects both guests and registered users. It considered three solutions for this opportunity: showing the shipping fee on the product page, a free shipping threshold meter in the cart saying "add X TL more for free shipping," and a shipping estimate by postcode. Note that "lower the shipping fee" could also be a solution; but that is a viability decision and needs a cost conversation beyond product discovery.

Here is the answer to the opening question too: shipping coming up in four of six interviews doesn't mean we should lower the fee. Paying attention to the customers' stories showed that their issue was less the fee itself than seeing it at the last step. Naming the opportunity correctly changes the solution space completely.

Types of Assumption Tests

Several assumptions sit behind the "shipping fee on the product page" solution: customers want to see the shipping fee early (desirability), we can calculate the fee correctly on the product page (feasibility), and customers who see the fee early won't add less to the cart and lower total orders (viability). There are several cheap ways to test these.

Data analysis is the cheapest: how much abandonment happens in the cart and how much at the payment step is already in the funnel. In a fake door test you put up the door of a feature without building it: you add a "see shipping cost" link to the product page and measure how many people click; whoever clicks is told honestly "this feature is coming soon." In a concierge test a human does the work by hand instead of automating it: for a few weeks the support team tells customers who ask the shipping fee over live chat. In a prototype test you have five customers use a clickable design and watch what they do.

Which one to choose depends on the assumption you're testing. A fake door measures demand but not usability; a prototype test measures usability but not demand. None of them measures the real feature's effect on real traffic; for that you need the experiment in post 08.

Dual-Track and the Developer's Place

The way of working in which discovery and delivery flow in parallel inside the same team is called dual-track; it spread through the writing of Jeff Patton and Marty Cagan. One track learns what to build this week, the other builds what was learned in previous weeks to production quality. The two tracks are not separate teams; the same people do both, at different hours of the week.

The developer's place in discovery shows up in three places. The first is the feasibility spike: spending a day or two poking at the carrier's pricing API (Application Programming Interface) to answer "can we calculate the shipping fee on the product page?", measuring its latency and checking whether it can be cached. The second is the throwaway prototype: quickly setting up the fake door link or the fake data behind a prototype test, and writing it knowingly as "code to be thrown away." The third is joining interviews: a developer who hears the customer's story first-hand remembers it months later when deciding on an edge case.

In Production

A fake door test carries an ethical line. Getting users to click a feature that doesn't exist and sending them to an empty page damages trust; show an honest message to whoever clicks, keep the test short (a week or two) and run it on a small slice of traffic. Don't use fake doors in sensitive flows like payment.

Keep prototypes from leaking into production. Fake door links and prototype endpoints left "as is for now" live for years. Keep code written for discovery in a separate branch or behind a clearly named feature flag, and write the test's end date into the backlog as a removal item.

Record discovery findings, but don't record personal data. Interview summaries, the OST itself and the results of assumption tests are the team's shared memory; three months later, the answer to "why did we decide not to do this?" should be there.

Common Pitfalls

The first pitfall is the leading question. "Does the high shipping fee bother you?" puts the answer in the customer's mouth. Turn the question into a request for a story: "In your last purchase, when did you see the shipping fee, and what did you do at that moment?"

The second is generalizing from a single interview. One story told very vividly can change all of the team's priorities. Add an opportunity to the tree as a strong branch only once you've seen it in several interviews and, if possible, in the data too.

The third is falling in love with a single solution. If the team decided on "shipping fee on the product page" from the start, assumption tests get designed only to confirm that idea. Putting at least three solutions side by side breaks that bias.

The fourth is turning discovery into a phase. "This quarter we do discovery, next quarter delivery" is the exact opposite of continuous discovery. Once the weekly rhythm is lost, from the first week of delivery onward the team starts deciding by guesswork again.

A Small Experiment

★☆☆ Write three questions for your team's next customer interview and label each one "past behavior, future prediction or opinion?" Turn the questions that don't ask about past behavior into the form "can you tell me about the last time...?"

★★☆ Draw a small OST for one of your product's outcomes: the root outcome, at least three opportunities based on evidence you have, pick one as the target and write three solutions for it. Which opportunity has weak evidence, and how would you strengthen it?

★★★ Find the riskiest assumption of the solution you picked and design an assumption test that checks it in under a week: which type of test, how many users, which result would make you drop the idea? As a developer, what is your share of the work in this test?

We picked a target opportunity in the tree, but usually there are several good ideas, several team requests and limited capacity on the table. In the next post we'll discuss prioritization with RICE (Reach, Impact, Confidence, Effort), MoSCoW, Kano and Cost of Delay, and rank the same backlog two different ways in TypeScript.