Discovery Is Not a Phase

A nonprofit I worked with had built a tool to help companies measure their impact against the UN Sustainable Development Goals. It was ambitious. It had signups. It also had a problem: most users stalled after creating an account.

The team had done discovery before building. They talked to stakeholders. They mapped the SDGs. They designed a comprehensive assessment framework. Then they built it.

The discovery was real. But it was also finished. The team treated it as a gate they passed through on the way to development. Once the requirements were written and the designs were approved, learning stopped. The product launched. Users signed up. And then users got stuck.

The gap was not in the research. It was in the assumption that research was a phase you completed, not a practice you maintained.

The discovery-as-phase trap

I have seen this pattern at every scale. A 70-squad enterprise healthcare organization where discovery was primarily technical. Teams validated feasibility but skipped desirability and viability. They could build the thing. They rarely asked whether the thing was worth building.

A defense software factory where teams had been cycling for six months with no clear output. Not because the engineers were slow, but because no one had done the upfront work to understand what the users actually needed. The first real discovery sessions, mapping user personas and journey flows for a weather app used during rocket launches, unlocked the path to an MVP in weeks.

A healthtech startup building a menopause education platform where user research with OB-GYNs and patients revealed that the symptom categories the team assumed were intuitive were actually confusing. The quiz that launched with those assumptions had high abandonment. The quiz that launched after continuous testing with real users cut abandonment by 38%.

Same teams. Same talent. Different relationship with learning.

What continuous discovery actually looks like

Continuous discovery is not "do more research." It is a structural commitment to learning throughout the delivery cycle. The teams I have coached that do this well share three habits:

1. They talk to users every week

Not every sprint. Every week. This does not mean formal usability studies with recruiting timelines and consent forms (though those matter too). It means a standing habit of 2-3 short conversations with real users, every single week, by the people building the product.

At the healthtech startup, we built this into the operating rhythm. The PM and designer talked to patients and clinicians weekly. Those conversations shaped the product in real time. When users told us the symptom tracker felt clinical and cold, we adjusted the tone. When clinicians told us the phase detection logic was too confident, we added uncertainty handling. These were not big pivots. They were small corrections that compounded.

2. They separate discovery from delivery but run them in parallel

Discovery and delivery are not sequential. They are concurrent. The team delivers what they have learned while continuing to learn what to deliver next.

The worst version of this is the team that finishes all discovery, hands off a spec, and moves on to "the next project." The best version is the team that always has two tracks running: what we are building right now (delivery) and what we are learning for what comes next (discovery).

At the enterprise healthcare org, I coached teams on this explicitly. We restructured their planning to separate committed delivery work from active discovery bets. Teams could ship with confidence on their current track while running small experiments on the next one. The planning process shifted from "forecast the whole year" to "commit to this quarter, hypothesize about the next one."

3. They use discovery to make decisions, not to make decks

Discovery that ends in a research report no one reads is wasted effort. The point of discovery is to change what you build, when you build it, or whether you build it at all.

The most effective pattern I have seen: discovery outputs flow directly into backlog decisions. A user interview reveals confusion about a concept. That same week, the team writes a story to clarify the UX. A usability test shows that a flow breaks on mobile. The fix enters the current sprint, not a future roadmap.

The defense team I coached moved from six-month cycles to two-week MVP iterations by connecting discovery directly to delivery. Their first formal Discovery & Framing process produced user personas, journey maps, and a prioritized problem list. That output became the inception backlog. No handoff document. No waiting for approval. The learning became the plan.

The organizational problem

The hardest part of continuous discovery is not teaching teams to do it. It is getting organizations to support it.

Discovery requires access to users. Many organizations gate that access behind research teams, legal reviews, or stakeholder approval. By the time a PM gets permission to talk to a customer, the window for learning has closed.

Discovery requires time that is not committed to delivery. Many planning processes allocate 100% of team capacity to feature delivery. There is no room to learn because every hour is spoken for.

Discovery requires tolerance for changing direction. Organizations that measure success by adherence to plan punish the very behavior discovery is designed to enable.

The organizations I have seen do this well protect discovery time the way they protect production uptime. It is not optional. It is not "if we have bandwidth." It is a standing investment in reducing the risk of building the wrong thing.

The cost of not discovering

The cost of skipping discovery is never visible in the current sprint. It shows up six months later when the feature launches and no one uses it. When the onboarding flow has a 60% drop-off rate. When the team realizes they spent a quarter building something that solved a problem users do not actually have.

Discovery is not a phase. It is a discipline. The teams that treat it that way build better products, waste less time, and maintain the conviction that what they are building matters.

The ones that skip it ship faster. They just ship the wrong thing.