The Discovery Sandwich: Data-Driven Product Discovery Research

The Discovery Sandwich is a three-layer product discovery framework: broad qualitative interviews to find the full set of problems your customers face, then quantitative research to measure which of those problems matters most, then focused qualitative interviews on the one problem the data picked out. It was developed at OpinionX and named for its structure, qualitative on the outside and quantitative in the middle. The order is what makes it work. Measure first and you’re only ranking a list you wrote yourself, and interviews on their own leave you no way to choose between the problems you heard. The middle layer is usually Customer Problem Stack Ranking, a method coined by Shreyas Doshi while he was a product leader at Stripe.
 

What is the Discovery Sandwich?

The Discovery Sandwich is a mixed-methods product discovery framework with three layers: qualitative breadth interviews, then quantitative prioritisation research, then qualitative depth interviews on the single highest-priority problem.

It exists because of a tension between two things product teams believe. The best products get built by teams who really understand the people they're selling to, and the best teams use data to make informed decisions. Most people agree with both, and then find themselves choosing between what a customer said in an interview and what the numbers say. There's no objective truth telling you which side to trust. You put your chips on red or black and hope.

The Discovery Sandwich is a way of not having to choose. 🥪

The Discovery Sandwich -- Customer and Product Discovery Research Framework

How I f*cked up my customer discovery the first time around

In late 2020 we launched our first product, a new kind of online research tool. It was clever: a normal survey that could adapt and change as more participants joined, like a live conversation.

I spent a year raising investment, building a team and launching a prototype. What we had was a solution in search of a problem. In the first six months we got one paying customer, and they churned within a few weeks.

Rather than give up, we found more than 100 people to interview to work out why nobody cared. We built a very broad understanding of what research means to every type of team, from government policy units and research agencies to HR functions and product teams at companies of every size.

No amount of tweaking helped. We were so deep in insights that we no longer knew what we were building.

As a last-ditch effort in March 2021, we ran one final experiment.

We wrote out the 45 most common problems we'd heard across all those interviews. Then one night we messaged hundreds of UX researchers online and asked them to rank the whole list for us. Within two hours we understood why nobody cared: the problems we'd assumed were most important to our target customers were sitting at the very bottom of the ranking.

We repeated it the next day with product managers and got the same result.

I'd expected that to be the moment it broke us, and it turned out to be the missing ingredient. Ranking those statements showed us we were chasing the wrong problem, and in the same two hours it showed us which problems our target customers cared most about solving, with hard data behind it.

So instead of interviewing a broad mix of people about all their problems, we could focus on product managers and learn everything about the problems they actually had. That's when it started working.

People began paying attention. Some of them started paying us. Over the following twelve months we rebuilt the product from the ground up, and OpinionX now runs on thousands of workspaces.

That experience changed how I think about building products. I no longer believe user interviews and qualitative research alone can get most startups to success, and I don't believe quantitative data and product analytics alone can show a team what to prioritise either. You need both, in a particular order.


What are the three layers of the Discovery Sandwich?

Learn as much as possible about your customers' problems. Use data to work out which of those problems matters most. Then go deep on the context surrounding that one problem.

Here's how I run each layer.

Layer 1: Qualitative, the bottom slice of bread

When we were interviewing 100-plus people in late 2020, we thought that was the whole of customer discovery. That you found people's unmet needs by sitting them down and asking questions, the way The Mom Test describes.

The Mom Test for Customer Discovery Research.png

What we missed is that this is only the first step: breadth interviews.

The job here is to understand your target customers and the range of problems they deal with.

What are they trying to accomplish? What does the process look like? Who else is involved? What are they using now? What frustrates them most often, and what costs them most when it goes wrong?

Like a good slice of bread, you're there to soak all of it up.

This is why The Mom Test principles matter so much at this stage. You aren't validating anything here, just finding out what your interviewee's working life actually looks like, with an open mind.

This is exactly where we went wrong. We treated interviews like an exam to pass or fail. If someone didn't use the right keywords or didn't complain about one of our shortlisted problems, we counted it as failed validation, so we'd steer the conversation toward our own topics until they said something close enough. That's how we ended up chasing our customers' 45th most painful problem.

Nielsen Norman Group's guidance on open-ended questions is the shortest useful primer on not leading the witness. Our own guide to customer discovery covers how to run this layer, problem brainstorming covers turning what you hear into a workable list, and thematic analysis covers finding the patterns across a stack of transcripts.

Layer 2: Quantitative, the filling

Once you understand the range of problems your customers face, you need data to work out which of them they find most impactful.

Impactful can mean frequent, a problem that hits five times a day. It can also mean frustrating enough to create three hours of extra work a week, or costly enough to take 10% off the value of every deal. Usually it's some combination. If you solve a problem customers feel strongly, those customers are probably already looking for a solution, and that's the best position you can build from.

This would be easy if every problem arrived with a cost or a frequency attached. It almost never does, so you need a method that turns qualitative insight into quantitative data.

The one I use is Customer Problem Stack Ranking, coined by Shreyas Doshi while he was a product leader at Stripe. CPSR asks your customers to compare and rank a set of problems so you can measure which ones hurt most. Doshi still writes about product decision-making on his newsletter. There's a full write-up in our beginner's guide to stack ranking research, a breakdown of Doshi's original method, and answers to the questions people ask most about stack ranking.

Stack ranking survey example

The reason ranking works better than a rating scale is that it forces a choice. Ask people to score twenty problems out of ten and most land between six and eight, which is central tendency bias, and you finish with a list nobody can act on. Pairwise comparison makes them separate.

One thing to hold onto here: every product should solve an impactful problem for a specific segment of customers. WeatherBill's $930M pivot is the clearest example of why choosing one target segment is the first ingredient of a scalable company.

If you've already run breadth interviews across several customer segments, you don't need to run separate studies. Use needs-based segmentation to run one stack ranking experiment and split the results by segment, so you can see which problems each subgroup cares about most.

OpinionX is built for exactly this, with segmentation included, and you can take a list of problem statements and have a stack ranking survey live in about five minutes. Use whatever tool you like, though. What matters is that by the end of this layer you have real quantitative data showing the highest-impact problem for a specific customer segment.

If recruiting is the blocker rather than the method, we've written up where to find free survey participants.

Layer 3: Back to qualitative, the top slice of bread

The quantitative layer gives you the permission you need to prioritise one problem. Not validation in the usual startup sense of proving an idea has legs, but permission to ask customers about that problem directly without worrying that you're biasing the conversation.

Here you bring back The Mom Test principles again: don't pitch, discard compliments, dig for specifics. The difference is that this time you don't have to dance around the topic. You go straight at it. These are depth interviews, not breadth interviews.

If your stack ranking tool keeps participant-level data, you can spotlight the people who personally ranked your key problem in their top three and invite exactly those people to a follow-up call. That removes an enormous amount of guesswork. You have the data proving the problem matters to your target customer, and a handful of named people who are personally struggling with it.

The same participant data drives crosstab analysis if you want to cut the result by more than one descriptor before you pick up the phone.

Individual results for a stack ranking survey research

What does each layer actually produce?

Layer Method Question it answers What you end up with
1. Qualitative breadth Open interviews, Mom Test principles What problems do these people have? A long, unranked list of real problems in customers' own words
2. Quantitative Customer Problem Stack Ranking, segmented Which of them matters most, and to whom? A ranked list per segment, plus the people who ranked each problem highest
3. Qualitative depth Focused interviews with self-identified sufferers Why does this problem happen, and what would fix it? The context you need to design a solution worth building

How is the Discovery Sandwich different from Opportunity Solution Trees?

They get confused, and they shouldn't, because they answer different questions and work well together.

An Opportunity Solution Tree, developed by Teresa Torres, is a map. It hangs a desired outcome at the top and branches down through the opportunities that could move that outcome, the candidate solutions under each one, and the experiments that would test them. Its job is to make the opportunity space visible so a team can navigate it deliberately rather than jumping at the first idea.

The Discovery Sandwich is a sequence. It doesn't draw anything. It says which type of research to run, in which order, and it inserts a measurement step between the two qualitative ones.

The practical difference sits at the moment of choosing. An Opportunity Solution Tree shows you the branches and leaves the choice of which to pursue to team judgment, compare-and-contrast reasoning, and whatever evidence is to hand. The Discovery Sandwich says that choice should be made with quantitative data from customers, at scale, before you commit.

So they stack. Run the Sandwich to populate and rank the opportunity branches of your tree with real numbers, then use the tree to work down from the chosen opportunity into solutions and experiments. If you're running Continuous Discovery Habits, the Sandwich is what keeps the opportunity layer honest between cycles.

Discovery Sandwich Opportunity Solution Tree
What it is A research sequence A visual map of the opportunity space
Answers Which research do I run, in what order? How do these opportunities and solutions relate to my outcome?
How you choose Quantitative ranking by customers, segmented Team judgment, compare and contrast across branches
Output One prioritised problem and the people who feel it A structured tree of opportunities, solutions and tests
Used together Ranks the branches Structures what sits under them

The Discovery Sandwich isn't mixed methods research generally, either. Mixed methods is the broad practice of combining qualitative and quantitative work in one study, and we've argued before that it's the most important research skillset of this decade. The Discovery Sandwich is one specific arrangement of it, with a stated order and a stated job for each layer, aimed at the single decision of what to build next. If the general practice is what you're after, start with how to run mixed methods research without being a quant expert.

Why does the order of the layers matter?

The Worst Sandwich Ever Made

^ shitty sandwich

Make a sandwich with two slices of ham on the outside and a layer of bread in the middle and you've made a bad sandwich.

Try to validate the problem your product solves before you know anything about your customers' lives and the problems they deal with, and you'll probably build a bad product. You'll be ranking a list you invented, and a ranked list of your own assumptions still tells you nothing about your customers.

Run only the interviews and you get the opposite failure, which is the one we hit: enough insight to fill a wall, and no way to tell which of it to act on.

The Discovery Sandwich is light on purpose. It identifies the set of possible options, prioritises which to focus on, and gathers the context to make the right decision. It works with whatever method you pick for the middle layer, not just Customer Problem Stack Ranking, and it works outside product discovery too: customer-led roadmap prioritisation, idea validation, assumption testing and product-market fit research. It also slots into frameworks you may already run, including Opportunity Solution Trees.

It produces something a roadmap can be built on, too. If you want the argument for that, we've made the case that startups should have a problem-focused roadmap rather than a feature-focused one.


Frequently asked questions

What is the Discovery Sandwich? The Discovery Sandwich is a three-layer product discovery framework: qualitative breadth interviews to find the problems your customers face, quantitative research to measure which problem matters most, then qualitative depth interviews focused on that one problem. It was developed at OpinionX.

Why is it called a sandwich? Because the qualitative layers sit on the outside like slices of bread, with the quantitative layer as the filling in between. The name is a reminder that the order of the layers is what makes it work.

How is the Discovery Sandwich different from an Opportunity Solution Tree? An Opportunity Solution Tree, developed by Teresa Torres, is a map of how opportunities and solutions connect to a desired outcome. The Discovery Sandwich is a research sequence that decides which opportunity to pursue, using quantitative data from customers. They're complementary: the Sandwich ranks the branches, the tree structures what sits under them.

What method do you use for the quantitative layer? Usually Customer Problem Stack Ranking, coined by Shreyas Doshi while he was a product leader at Stripe. It asks customers to compare and rank a set of problems so you can measure which are most impactful. Any method that produces a ranked, segmentable result works.

How many interviews do you need for the first layer? Enough to stop hearing new problems. In practice that's usually somewhere between fifteen and thirty per segment, and the signal you're looking for is repetition rather than a target number.


We spent a year building for our customers' 45th most painful problem. Two hours of ranking told us which one actually mattered.

Want more like this? Over 42,000 researchers and product people get The Full-Stack Researcherin their inbox. Subscribe for the next one.

If you've already finished the breadth interviews and you're sitting on a pile of insights, jump straight into the quantitative layer. OpinionX is free to start: $0, unlimited surveys, unlimited researcher seats, capped at 25 participants per survey, then $900 a year to lift the cap (full pricing). You can have your first Customer Problem Stack Ranking survey live in minutes, with no credit card, at app.opinionx.co, or book a demo first.

Previous
Previous

The Lean Startup is a terrible book for startup founders

Next
Next

Forced Choice Questions: Use Cases, Survey Examples, Ranking