Is Product Discovery a Phase or a Weekly Habit?

Product discovery is weekly customer touchpoints by the team building the product, doing small research toward a desired outcome. Teresa Torres set that floor in Continuous Discovery Habits. Marty Cagan started using the word around 2005 (and committed in 2007) so teams would gather evidence before asking engineers for production-quality software.

The work runs next to delivery: a product trio that shares the customer, and a week you can run with no research team. It is not a pre-build kickoff, a Jira ideas tutorial, or storefront merchandising.

Key Takeaways

• Continuous discovery means the building team talks to customers every week, in bite-sized research, toward an outcome. A workshop that dumps a backlog on engineering is a different object.
• Discovery and delivery are two kinds of work on one team. Jeff Patton treats a high kill-rate as the test that discovery is real.
• Recruiting is the bottleneck. Wake up Monday with a conversation already on the calendar, even if that conversation is a CS ride-along.
• If nothing you researched has ever been stopped, you are specifying. Kill criteria and named overrides beat more interviews.
• Jobs to be done, design thinking, interviews, and assumption tests are techniques inside this loop. They are not competing religions.

What Is Product Discovery?

Atlassian-style pages describe this work as understanding needs and validating ideas before you build. That sentence is true and incomplete. It reads as a gate you pass, then leave.

Torres's load-bearing definition, as she restates it, is a practice, not a phase:

At a minimum, weekly touchpoints with customers by the team that's building the product, where they conduct small research activities in pursuit of a desired product outcome.

Three conditions sit inside that sentence. The people writing the code and the interface talk to customers, not via a persona deck.

The research is small enough to sit next to a sprint. The work pursues an outcome, not generic insight.

Cagan's origin story is a vocabulary swap. Teams used to "gather and define requirements." He borrowed "discovery" from pharma: you enter knowing most candidates fail.

MVP, design thinking, customer development, and jobs to be done are techniques you can use inside that search. None of them is the search.

If you typed this query looking for Atlassian's ideas-and-roadmap product, that tool is Jira Product Discovery. Storefront search and merchandising live in a different industry.

Why Weekly Beats a Kickoff

NN/g surveyed 436 UX practitioners in October 2019 (published May 2020). 75% of organizations said they run discoveries. People who ran one on their last project self-reported success 83% of the time, versus 52% without.

That is self-report, not a causal trial. It still shows how strongly practitioners associate an upfront study with a project that "worked."

Designers showed up on 74% of last discoveries, researchers on 60%, PMs on 52%, product owners on 36%, developers on 27%.

A product trio that interviews together is not the NN/g default. The default is a design-and-research phase that engineering joins late, if at all.

A two-week Discover+Define kickoff can still frame a project. It will not stop the curse of knowledge from running the next stretch of product decisions.

Building also got cheaper. Cagan wrote in April 2026 that 10-20 prototypes a week is now easy. Delivery speed without judgment is how you ship a polished wrong thing.

Steven Cohn on LinkedIn (August 2026): building gets cheaper every month, which puts the weight on deciding what deserves to get built at all.

Four Risks You Are Testing

Cagan's four risks are the questions discovery exists to answer. Keep them separate. Do not collapse viability into "strategic fit" and stop testing the others.

Most product efforts fail on the solution, not on a fake market. You confirmed demand for "something in this space," then shipped a product nobody would switch to. Discovery that never touches a solution is how that happens.

Customer Discovery Is a Different Job

Customer discovery in the Lean Startup sense is founder interviews to test whether a company should exist. Same two words as this query, different job.

Product-team discovery assumes the company exists. You already have users, a codebase, and a delivery calendar.

The question is which customer behavior to change next, and which solution is worth production. Point interviews at qualitative research craft (stories, not "would you use this?"), then come back to this loop.

Discovery vs Delivery: One Team, Two Kinds of Work

Cagan's 2015 split is two goals that feel at odds: learn the customer solution fast, and release a robust implementation with confidence. Discovery's purpose is evidence before you ask engineers for production-quality software, so live customers are not unwitting test subjects.

Patton draws the same line as two kinds of thinking. Discovery optimizes for fast learning. Delivery optimizes for predictability and quality.

If discovery is working, you substantially change and kill lots of ideas. Every test ends one of three ways: build it, kill it, or keep learning. The most expensive test is production-quality software.

Head-term pages stop at "before you build." That sequencing is what teams hear as a handoff.

Cagan's later language is blunter: do not treat them as phases. In practice both are continuous. Both build, for different reasons.

Teresa Torres said the same thing on Lenny's Podcast (2022, 0:50):

They think about it as phases: first I discover and then I deliver. No. You're always delivering and you're always discovering, and the more you build this discovery habit the better those bets are going to get with time.

On r/UXDesign, "continuous discovery" sometimes means launch-and-learn: ship, then watch behavior. That is back-loaded delivery instrumentation. Useful.

It is not Torres's weekly touchpoint by the building team. Keep the names apart or you will skip the interview and call the dashboard "discovery."

Dual-Track Is Not Two Teams

The phrase people fight over came from Desirée Sy's 2007 paper in the Journal of Usability Studies (Alias / Autodesk). Designers still talked to developers every day. Patton taught the model with Cagan, pulled the wording from Sy, and then spent years telling rooms it is Dual Track, not Duel Track.

Two teams is the failure mode. Research produces specs. Engineering waits, then complains the specs were wrong.

Patton's version is one team, two kinds of work, overlapping on the same people.

Cagan used Dual-Track Agile as a label, then moved the public language to continuous delivery paired with continuous discovery, because teams fixated on the process name. Use the work words. Retire the brand if it makes your org draw a swimlane.

A UX Discovery Phase Is a Different Object

Maria Rosala at NN/g defines discovery as a preliminary phase in the UX-design process: problem space, frame the problem, enough evidence and initial direction. It maps to the UK Design Council double diamond's Discover and Define. It typically does not test a hypothesis or evaluate a solution.

UX Crush readers arrive with that definition. Keep it for project framing. Weekly touchpoints are the operating loop.

NN/g's own agile advice is SCALE: share progress, constrain spikes to one or two questions, align on the problem, limit methods to missing information, evaluate together. They also warn you not to set discovery duration equal to sprint length.

In the 2019 survey, 58% of last discoveries lasted two weeks or less. NN/g's read: unless users are easy to reach and the space is small, two weeks is too short.

An NN/g video argues that upfront and continuous both help teams solve real problems. You can run a framing study and still put a customer on the calendar every week. A kickoff cannot substitute for the week.

Continuous Discovery as a Weekly Practice

Torres's system is an opportunity-solution tree fed by two small weekly activities. Interviewing is generative: it surfaces opportunities. Assumption testing is evaluative: it pressures solutions.

The book breaks the system into 11 habits. Start with one.

Best teams, in Cagan's number as cited by Torres in 2022, complete 12-15 discovery iterations every week. An iteration is anything that further understands what to build.

That is not 15 production experiments. Pair it with Cagan's 2026 prototype cadence: cheap cycles, logged decisions, almost none of them shipped.

Product Talk Academy reports more than 18,000 product people enrolled in its courses. Fluency in the vocabulary is not the practice. On r/ProductManagement, u/Superbureau (Jun 2026) named the cargo cult:

The product thinking movement didn't just professionalise PMs. It created a shared vocabulary that organisations could adopt as proof of capability without actually developing it. Discovery. Outcome ownership. Continuous experimentation. These became things teams say they do, not things they actually do.

Weekly Touchpoints Are Not Always a 60-Minute Interview

Weekly is the floor because a month of decisions without a check leaves the curse of knowledge unexamined. Frequency above weekly depends on the audience.

Consumer products make recruiting easy. Some B2B audiences may never hit weekly and still need a consistent cadence.

A touchpoint can be a 25-minute story interview, a CS ride-along, a five-minute intercept, or a one-question prototype test. A CAB used as a focus group, or a stakeholder opinion session logged as "research," is not one.

Recruiting is the bottleneck, not interviewing skill. Torres's line: if you have to hustle to find a customer every week, you will not do it. The goal is a conversation already on the calendar when Monday starts.

Tactics that survive a delivery week: an in-product intercept, a scheduling link, the last five minutes of a CS or sales call, a bench of past interviewees who opted in.

Torres again, on Lenny's Podcast (2022, 24:46):

What I think is really nice about continuous discovery: you can do it in as little as an interview a week. When somebody says I don't have time for discovery I think what they're really saying is I don't have time for project-based research, and I agree with that.

On r/ProductManagement, u/iB3ar (Aug 2026) described applying that floor without a study protocol:

From her book: I try to talk to at least one of my users per week. It doesn’t need to be a formal study. I can ping someone in CS and ask to listen in.

That is a valid degraded touchpoint. It is not a substitute for story-based interviews forever. It is how the habit survives a feature factory.

The Product Trio Owns One Outcome

A product trio is a PM, a designer, and an engineer jointly responsible for a shared outcome. They interview and run assumption tests together.

Historically the work was a handoff: requirements, then mockups, then code. The messy middle is an org that says "you're a trio" while only the PM talks to customers.

Interview together so disagreements are about shared evidence, not opinion rank. Torres on X (April 2023): product managers don't own the problem, and designers and engineers don't own the solution.

Show your work. Interview snapshots beat slide-deck conclusions. A trio that only presents themes will lose to the most senior opinion in the room.

Outcome, Then Opportunities, Then Solutions

Start with an outcome. A business outcome is the health of the business. A product outcome is a customer behavior that is a leading indicator of that health.

"Ship the redesign" is not an outcome.

Opportunities are needs, pain points, and desires. There are infinitely many. Solutions are also infinite.

Compare solutions with rapid assumption tests, not with a high-fidelity prototype as the first move.

The opportunity-solution tree is how Torres maps that structure. Teach the tree on its own page.

Prerequisites before you draw the first tree: a theory of the target customer and value proposition, a clearly defined outcome, and three or four story-based interviews. Do not invent opportunities from what you already "know."

Interviews for product teams exist to discover opportunities. People are polite. They will endorse a feature and then never switch.

Ask "tell me about the last time…", not "would you use this?"

Assumption tests simulate an experience and observe behavior. Concept testing is one evaluative method; teach it on its own page when it ships.

A Week You Can Actually Run

"Weekly touchpoints" is copy-pasted everywhere. Almost no ranking page shows who books the time, what the touchpoint produces, and how it feeds this week's delivery.

Andrea López at Get Product People (24 Oct 2025) published a Monday-Friday week-in-the-life. Treat it as an example, not Torres canon. Protect "two interviews and one small test per week" in the working agreement so a slipped release does not eat the habit.

Pitfall they name: interview theater. Long sessions, no decisions.

Shipping value every week is a benchmark, not a law. Torres's ideal is weekly value. Nobody lives there.

Get closer by slicing the opportunity smaller and story-mapping the simplest solution (Patton's move).

One Worked Touchpoint

Say the trio owns "cut time-to-first-value for a new workspace." Monday already has an interview because an in-product intercept booked it last week.

Tuesday, the three of you sit on the call. Prompt: "Tell me about the last time you tried to invite a teammate." The story that repeats: people cannot tell who already has access, so they ping in Slack instead of inviting.

Wednesday you map assumptions on a thin invite-screen change. Riskiest assumption: users will notice an access list if you put it on that screen.

Thursday you prototype the list on the invite screen and run five unmoderated tasks, or a one-question intercept. Friday you log one of Patton's three endings: build a production slice, kill the idea, or keep learning.

That is one cycle. The opportunity tree records it.

Delivery may still ship something else this sprint. Discovery did not wait for a new quarter.

Degraded Start When You Are the Only PM

On r/ProductManagement, the overwhelm thread is the one that ranks: no designer partner, engineering in a death march, "book six users" a fantasy.

Torres's feature-factory start needs no permission and no customer access: 20-30 minutes of assumption mapping on an idea you already have. Write the assumptions. Star the one that would kill the idea if false.

That is the first test.

Then pick the easiest customer conversation you can actually get: sit with CS, ping a past interviewee, or join a super-user office hour.

Some teams put a user conversation into definition of ready, so a story cannot enter the sprint without it.

Do not wait for a research ops program to bless you. When you do have researchers, do not Columbus their work. Torres, on Dovetail (2024, 8:27):

I don't think that continuous discovery or teams doing their own discovery replaces good research done by skilled researchers. Product teams talking to customers does not replace skilled researchers doing good research.

If your org dissolved UXR and renamed the gap "democratized discovery," that is theater with a nicer vocabulary. ResearchOps is how you keep panels, consent, and repositories while product teams still talk to customers every week.

Discovery Theater and Kill-Rate

The diagnostic, repeated independently in 2025-26: has discovery ever killed a feature? Not delayed, not reshaped. Stopped.

Ant Murphy on LinkedIn (April 2026):

If you're not stopping things as a result of discovery, you're not discovering.

The output is a decision: build small, run the next experiment, pivot, or bin. Detailed design dressed up as discovery is specification.

Chantal Botana (Sep 2025) called the checkbox version: teams check boxes, they do not challenge assumptions. Done-done is when the work moves the metric, not when it ships.

thehardparts.dev (FM-25) describes activities that produce artifacts and do not change decisions, often presented as mature product practice. First move: pick one current decision research could reverse. If there isn't one, do not run the research.

Martin Labuschin (May 2026) refuses the usual fix ("do more research"). The failure is powerless discovery.

Outputs have no formal authority. Seniority overrides without naming the override. Cost of ignoring evidence is zero.

His decision protocol is three fields, filled before and after the work:

• Kill criteria, written before discovery starts.
• Evidence considered (or "none available," visible).
• Override noted, with a name and a reason, recorded. Review override outcomes quarterly.

Theater patterns to watch for:

• Confirmation interviews, where contradictions become "edge cases."
• A ship date locked before discovery completes. Theater by design.
• Synthesis as themes that never sit at the prioritization table.
• A "discovery sprint" that ends with a prototype. "Should we build this?" never makes the agenda.
• Research scheduled after the roadmap is committed.
• The same insights, successive cycles, no change.
• MVPs that never get thrown away.

Cagan's 2020 distinction still applies: learning is the means, not the point. Insights are the learnings you can act on. Interview volume without a decision is still theater.

On r/ProductManagement, AI-speed delivery is squeezing this work even as it should create more space. u/utzutzutzpro (Apr 2026):

You can't be accountable for outcomes when you do not have the authority to decide the path. AI is increasing build speed, which should actually give an organisation for space to explore and discover, not less.

Cheaper delivery raises the cost of pointing the team at the wrong thing. It does not retire the week.

Methods That Feed the Loop

Each method below is an exit, not a chapter.

Jobs to be done is a way to talk about the progress a customer is trying to make. Use it when stakeholders argue features. It will not replace weekly contact.

The design thinking process is a problem-framing kit (empathize, define, ideate, prototype, test). Cagan treats it as a discovery technique.

A five-day design sprint is still a project. Put a customer on next week's calendar when the sprint ends.

UX research methods is the catalog: when interviews beat surveys, when usability testing is the right evaluative move, when diary studies earn the cost.

Continuous discovery uses a thin slice of that catalog every week. It does not replace a skilled study when sampling, outliers, or a high-stakes launch need one.

Opportunity-solution trees, user interviews, and concept testing are spokes in this cluster. They are not live on UX Crush yet, so they are named here rather than linked.

Interviews stay generative. Evaluation goes to assumption tests and, when you need a structured concept check, to concept testing.

Recruiting infrastructure (a panel, an intercept, a scheduling link) matters because Monday needs a name on the calendar. The tool is not the practice.

Common Discovery Mistakes to Avoid

Logging Demos and Stakeholder Meetings as Interviews

A roadmap review is not a customer touchpoint. Neither is a sales demo where the prospect performs enthusiasm.

Torres's quality-of-evidence point on LinkedIn (July 2026): low-value signals feel like they tell you what to build. They rarely carry enough strength. Petra Wille added the AI-era sting: it is easier than ever to release mediocre software, so people need to get better at interviewing.

A Discovery Sprint That Cannot Kill the Idea

If the week is scheduled to end with a prototype, "should we build this?" is not on the agenda. Labuschin's three fields (kill criteria, evidence, named override) belong in the working agreement before anyone books the room.

Dual-Track as Two Teams

A research track that throws specs over the wall is duel track. If developers only see discovery as a Friday slide, you do not have a trio.

Waiting for Project-Based Research

On r/ProductManagement, "I don't have time" usually means no time for a protocol, a sample, and a report. Agree with that.

Book one conversation. Assumption-map for 20 minutes.

u/brauxpas (Aug 2026) on r/ProductManagement: the superpower is fitting the fundamentals into the org you are in, not performing the literal book process.

Measuring Interview Count Instead of Kill-Rate

Twelve interviews and zero reversed decisions is theater with a higher bill. Count decisions: built small, next experiment, pivot, bin.

Review overrides quarterly. Interview volume without authority is powerless discovery.