Back to articles
03.15 — A practical product discovery framework
·12 min read

A practical product discovery framework

JB · jarodbarrera.comDRAWING NO. DF-04 · FIG 3PICK THE RIGHT METHODEach method answers a specific question. Use the wrong one and the data is decorative.INTERVIEWSUSE WHEN →exploring a new problem space. you need depth, context, and the workarounds users invented.NOT FOR → feature preference votingUSABILITY TESTUSE WHEN →you have a design or prototype and you need to know whether users can complete the task at all.NOT FOR → whether the task itself mattersA / B TESTUSE WHEN →two reasonable solutions exist. you need a quantitative answer about which one moves the metric.NOT FOR → exploring an unknown spaceANALYTICS DIVEUSE WHEN →you already have the events instrumented. you’re looking for behavior patterns at scale.NOT FOR → understanding the WHY behind a patternDIARY STUDYUSE WHEN →the behavior unfolds over time. you need to see context and friction across an actual work week.NOT FOR → quick single-task answersCONCEPT TESTUSE WHEN →the idea is early. you want to test desirability before investing in design or build.NOT FOR → validating usability of a real flowThe method follows the question. The question follows the hypothesis. Never the other way around.

Most product teams I've worked with have a discovery problem they can't quite name. They're doing the motions — customer interviews, user research tickets, stakeholder workshops — but the output doesn't feel like it's actually informing what they build. The roadmap updates anyway. The features ship. And six months later, they're doing post-mortems on why usage is flat.

The issue usually isn't effort. It's structure. Discovery is treated as a phase — something you do before you build — rather than a discipline that runs continuously alongside delivery. When discovery is a phase, it always loses to deadline pressure. When it's a discipline, it becomes the thing that makes the delivery more certain.

I've spent a lot of time working out what a practical discovery framework actually looks like, one that holds up under real sprint pressure and doesn't require a dedicated research team to execute. Here's what I've landed on.

The discovery-delivery divide

The framing I keep coming back to is this: delivery is about reducing execution risk. Discovery is about reducing problem risk. Both matter, but they answer different questions. Delivery asks "can we build this?" Discovery asks "should we build this at all?"

Marty Cagan has written about this divide extensively, and his observation that most teams spend 80% of their time on delivery and 20% on discovery has matched my experience — except I'd say the 20% is optimistic. At most companies, discovery gets whatever time is left over after sprint ceremonies, stakeholder updates, and fire-fighting. Which is to say, almost none.

The consequence is predictable. Teams build things they can build rather than things that will change user behavior. They optimize for output — features shipped, velocity maintained — rather than outcomes. And then they wonder why their engagement metrics are drifting.

What I've found actually works is treating discovery as a parallel track, not a preceding phase. While one feature is in development, the discovery work for the next two cycles is running concurrently. That sounds obvious when you say it out loud, but the organizational discipline required to maintain it is real. You have to protect the time, and you have to resist the pull of "just help with the current sprint."

JB · jarodbarrera.comDRAWING NO. DF-02 · FIG 1TWO LOOPS, ONE TEAMDiscovery and delivery run in parallel, on different cadences. When you collapse them into one loop, one of them silently dies.DISCOVERY LOOP · continuousDISCOVERYwhat should we build?talk to usersform hypothesistest the assumptionsynthesizeDELIVERY LOOP · per cycleDELIVERYhow do we build it?scopebuildship + measureestimateevidence flows right →← questions flow leftMost teams have a delivery loop and call it discovery. The discovery loop only exists if it has its own meetings, its own artifacts, its own rhythm.When the loops fuse, it’s always the discovery loop that dies.

Defining the problem space

Before you can generate good hypotheses, you need to be precise about the problem you're investigating. I've watched teams spend weeks running research on problems they never clearly defined. The research comes back messy, the synthesis is hard, and everyone has a different interpretation of what was learned.

The definition work happens along three axes.

Who. Not "our users" or "enterprise customers" — a specific segment with shared context and shared constraints. The more precisely you can name the person whose experience you're trying to change, the better your research questions will be. I often ask teams to name three actual customers who represent the segment. If they can't, the segment isn't defined yet.

What job they're trying to do. This is Clayton Christensen's jobs-to-be-done framing, and it's still the most useful lens I've found for defining the problem space. What outcome is the user actually trying to achieve? Not in the product, but in their work or life. The job is usually simpler and more durable than the feature request sitting in your backlog.

What's blocking them. This is the specific friction between the user and the job. It might be missing information, a clunky workflow, unclear feedback from the system, an assumption they're carrying about what's possible. Getting specific here is hard. Users often can't articulate the blocker directly. But the precision matters — a vague problem generates vague hypotheses and ultimately vague solutions.

One thing I've added to this process that's been useful: writing the problem statement down and showing it to three people who know the space — a customer, an engineer, a salesperson. If they all read it and say "yes, that's the problem," you've probably got it right. If any of them look confused or suggest a reframe, the definition needs more work.

Generating and prioritizing hypotheses

Once the problem is defined, the natural instinct is to jump to solutions. Resist it. What you want to generate first are hypotheses about why the problem exists. Solutions can wait.

A hypothesis takes the form: "We believe [specific thing is true about users/behavior/context] because [evidence or reasoning]. If this is true, it would imply [solution direction]." The format disciplines the thinking. It forces you to separate what you know from what you believe, and to be explicit about what you'd build if the hypothesis holds.

I usually generate ten to fifteen hypotheses in a working session with the team. Some will be obvious, some will be contrarian, some will turn out to be the same hypothesis restated. That's fine. The goal is to surface the full range of explanations before you narrow down.

Prioritization happens on two dimensions: how much impact it would have if the hypothesis is true, and how confident you currently are that it is. The hypotheses worth investigating first are the ones that are high-impact and low-confidence. If you're already highly confident, you should probably just act on it. If the impact is low, it probably doesn't matter whether it's true or not.

JB · jarodbarrera.comDRAWING NO. DF-03 · FIG 2RISK × IMPACTNot every hypothesis deserves a research budget. Sort by what you’d lose if you were wrong.IMPACT IF TRUEHIGHLOWRISK IF WRONGLOWHIGHJUST SHIP ITHigh impact, low risk. Don’t waste a research cycle — the cost of trying is less than the cost of testing.RESEARCH HARDHigh impact, high risk. This is where discovery earns its keep. Spend the research budget here.PARK ITLow impact, low risk. Worth knowing — later. Park in the backlog. Don’t spend a hypothesis slot.SKIPLow impact, high risk. The worst quadrant. You could be wrong about something that won’t move the needle. Move on.Test where being wrong costs the most. Ship where being wrong costs the least.

One pattern I've noticed is that teams tend to generate hypotheses that conveniently support solutions they already want to build. This is selection bias, and it's insidious because the hypotheses feel legitimate — they're framed as research questions, not as rationalizations. The check I've found useful is to ask: "If this hypothesis turned out to be false, would we build something meaningfully different?" If the answer is no, you're not actually testing the hypothesis. You're confirming it.

Designing and executing research

With prioritized hypotheses in hand, you can design the research. The type of hypothesis determines the type of research, and getting this mapping right saves a lot of time.

Exploratory research is for hypotheses where you don't yet have enough signal to know if you're even asking the right question. This is observational, open-ended, qualitative. Interview sessions, contextual inquiry, diary studies. The goal is to generate signal, not to validate a specific claim. Teresa Torres' continuous interview cadence — one user conversation per week, every week — is the closest thing to a universal best practice I've encountered. The regularity matters as much as the technique.

Evaluative research is for hypotheses where you have a proposed direction and want to know if it addresses the problem. Usability testing, concept testing, A/B experiments. You're asking "does this work?" rather than "what's going on?" The design artifact being tested can be a prototype, a mockup, a live experiment — the fidelity should match your confidence level. If you're still early, test concepts. If you're close to shipping, test the real thing.

Analytical research is for hypotheses that can be answered with existing data. Usage patterns, funnel analysis, cohort behavior, support ticket themes. I've seen teams chronically under-invest here because it feels less like "real research." But behavioral data often surfaces the most honest signal about user needs, because behavior is harder to game than a survey response.

JB · jarodbarrera.comDRAWING NO. DF-01 · 01 OF 01THE DISCOVERY PIPELINEFour stations. Each one produces an artifact for the next. You can’t skip a station and still claim discovery.01DEFINE PROBLEM SPACEFrame the actual question. Bound the problem. List the assumptions you’re entering with.OUTPUT → problem statement02GENERATE HYPOTHESESBrainstorm broad. Score by risk and impact. Pick the few worth testing this cycle.OUTPUT → ranked hypothesis list03RESEARCH + TESTMatch each hypothesis to a research method. Run. Collect what users DO, not just say.OUTPUT → evidence per hypothesis04SYNTHESIZE + DECIDEConnect findings. Update what you believe. Make the bet or kill it.OUTPUT → decision + storyEvery decision feeds the next cycle’s problem space so discovery is continuous, not a phaseSkip a station and you ship ASSUMPTIONS. Run all four and you ship EVIDENCE.

Execution is where most discovery frameworks fall apart. The research plan looks great in a slide. The actual sessions are harder to schedule, the recruiting takes longer than expected, and by the time you're three weeks in, the sprint cycle has moved on.

The things that help: pre-negotiate access to customers before you need it (your CS team should have standing relationships you can use), keep interview protocols short (45 minutes maximum, 30 is better), and never do research alone. Two people in a session — one facilitating, one taking notes — produces dramatically better synthesis later.

Synthesizing and sharing findings

This is the part most frameworks gloss over, and it's where discovery output either becomes actionable or dies in a Notion doc.

Synthesis is not summarization. Summarization is listing what you heard. Synthesis is making an argument about what it means. The output I've found most useful takes three forms.

Opportunity statements. Framed as "Users who [context] struggle to [job] because [specific friction], which means [implication for the product]." The format forces you to connect the observed behavior to a product decision. If you can't complete the sentence, you haven't synthesized yet.

Assumption maps. Before deciding what to build, get explicit about the assumptions baked into your intended direction. Which assumptions are load-bearing? Which have been validated by your research? Which are still open questions? Sharing an assumption map with stakeholders before a build decision creates much better conversations than sharing a solution.

Decision logs. Write down what you learned, what you decided as a result, and what you're still uncertain about. This seems obvious but rarely happens in practice. The value compounds: six months later, when someone asks why a feature was designed a certain way, you have an answer. And that answer can inform whether to change it.

Sharing matters as much as synthesizing. I've seen genuinely good discovery work die because it was shared in a format that didn't land with stakeholders. A dense research readout is not the same as a compelling narrative about what you found and what it implies. The best research shares I've seen start with the single most important thing learned, connect it explicitly to a pending decision, and then offer supporting evidence for those who want to go deeper.

Stakeholder alignment as discovery

Here's something that took me a while to fully internalize: stakeholder conversations are discovery work, not a tax on it. The assumptions your VP of Sales carries about the customer are data. The mental model your Head of Engineering has about the technical constraints is data. The thing your CEO keeps bringing up in all-hands is data.

I started treating stakeholder alignment sessions the way I'd treat a customer interview — with a protocol, with explicit questions I wanted to answer, and with note-taking. Not because I was researching the stakeholders, but because stakeholders are often carrying signal about the problem space that isn't captured anywhere else. They talk to customers. They hear things in sales calls. They have intuitions shaped by years of context that you don't have.

The other thing stakeholder conversations do is surface the organizational assumptions that constrain the solution space. If your CTO believes a certain approach is technically infeasible, that constraint is as real as any user need — even if it's wrong. You can't solve around a constraint you don't know exists.

Teresa Torres' framing of a "tri-force" — product, engineering, design — as the core discovery team is the right starting point. But in practice I've found that including at least one external voice per discovery cycle (a salesperson, a customer success manager, a subject matter expert) dramatically improves the quality of hypotheses generated. They bring perspectives that the core team's proximity to the product systematically filters out.

Putting it together

The framework is simple to describe and genuinely hard to sustain. Define the problem precisely, generate and prioritize hypotheses about why it exists, choose research methods that match the hypothesis type, synthesize findings into decision-relevant artifacts, and share them in formats that move stakeholders to action. Repeat continuously, not in phases.

The part that doesn't show up in any framework but matters most: you have to protect it. Discovery will always be crowded out by delivery pressure unless someone actively defends the time. On every team I've led or advised, the thing that made discovery work wasn't the process. It was someone in a senior enough role saying "this is what we do, we don't skip it, and here's why."

The payoff, when it works, is confidence. Not the kind of confidence that comes from having a long backlog, but the kind that comes from knowing why you're building what you're building and being able to explain it clearly to anyone who asks.

This article is part of a series on product management in an AI-transformed landscape.