What Is Product Discovery? The Stage That Decides If a Project Works

Product discovery is the process of thoroughly understanding what a project actually needs — the real business problem, the technical constraints, the expected scale, and the minimum required to solve it — before writing the first line of code or picking which team will build it. It isn't "gathering requirements" in a kickoff call: it's the work that reduces four concrete risks before committing budget and development time — whether the problem is worth solving, whether anyone will be able to use the solution, whether it's technically feasible with the time and team available, and whether the business can sustain it — before committing those resources to building it.

It exists because what a company asks for at the start is almost never a complete spec: it's a need expressed in everyday language — "we need a system that organizes orders better" — that has to be translated into a concrete, actionable scope before anyone starts coding. Skipping that step doesn't save time — it pushes the cost further down the line, to a point where fixing a scope misunderstanding costs a lot more than resolving it in a conversation would have.

Why does discovery matter before writing code?

Because the cost of a scope mistake grows the later it's caught. Marty Cagan's "four big risks" framework (Silicon Valley Product Group) organizes discovery around exactly that idea: before building, a team has to resolve value risk (does anyone care about this problem?), usability risk (will people be able to use it?), feasibility risk (can it be built with the time and technology available?), and business viability risk (does it work for the business, not just the user?). None of the four gets resolved by looking at code — it gets resolved by talking, researching, and, above all, doing it before the first line gets written.

• Value risk — whether the problem being solved actually matters to the user or the business.
• Usability risk — whether people will understand how to use what gets built.
• Feasibility risk — whether the team can build it with the time, stack, and people available.
• Business viability risk — whether the solution also works for legal, finance, or the go-to-market strategy, not just the user.

When discovery gets skipped or done poorly, those risks don't disappear — they show up later, after development is already done. PMI (Pulse of the Profession, 2014) found that 47% of projects that miss their goals fail because of inaccurate requirements management — the single most cited cause of project failure in that study, ahead of budget or schedule issues.

Is discovery a one-time phase or an ongoing habit?

It depends on the model, and the difference matters. The traditional approach treats discovery as a phase that happens once, up front, before moving into "delivery" and not looking back. Teresa Torres, in Continuous Discovery Habits (2021), argues for a different model: discovery as a weekly team habit, not a one-time project — talking to real users, testing small assumptions, and adjusting course constantly, in parallel with development (what she and Cagan call "dual-track": discovery and delivery running at the same time, not in sequence).

The practical difference is this: in the single-phase model, a change in context — the business shifts priority, a competitor shows up, users react differently than expected — breaks a plan that's already locked in. In the continuous model, that change gets caught in next week's conversation, not six months later, when the product is already built and doesn't fit.

What changes when discovery is built from AI-captured meetings instead of a PM taking notes by hand?

Most discovery information doesn't live in a document — it's scattered across meetings: the one with the product team, the one with support, the one with a client frustrated about a broken feature. A PM taking notes by hand loses nuance between one conversation and the next, and reconstructs the full picture from memory. That's why AI meeting transcription and note-taking stopped being a novelty: according to Fellow.ai's State of AI Meeting Notetakers 2025 survey, 75% of professionals surveyed already use an AI assistant in their work meetings.

But the same survey shows the uncomfortable side of that adoption: 84% of respondents said they change what they say when they notice an AI bot recording, and 47% reported that a notetaker recorded or shared something they didn't intend to have captured. Adopting AI in meetings without being explicit about what gets recorded and why doesn't solve the problem of scattered discovery — it makes it worse, because it also breaks the trust of the conversation that's supposed to get understood in depth.

How does Kaizen do it at Zenit?

Kaizen is Zenit's discovery engine, and it starts there — not with an intake form. It joins the company-side team's meetings as a participant, not a hidden bot, and cross-references what it hears across different conversations to build a single map of the real process: what exists, what's missing, where contradictory versions of the same priority show up. That map becomes a living brief — scope, milestones, team requirements — before any match with a squad even starts.

The difference from traditional discovery isn't just speed: that brief doesn't get lost or rewritten from memory six months later. It's the same memory that later guides matching, milestone-by-milestone execution, and, if needed, handing context off to a replacement squad.

Discovery is also why automatic keyword-based matching falls short: without understanding the project's real context, any match is a bet made on incomplete information.