Continuous Discovery

Discovery isn't a phase. It's a heartbeat.

Discovery is the work of figuring out what's worth building. Delivery is the work of building it. This page is about the first one, and about the mistake of treating it like something you finish.

Most teams treat it like a phase. There's a research period at the front of a project, a stack of interviews, a deck of slides summarizing what they found, a decision. Then research is over and the building begins. The team goes heads-down for a year and ships what the research told them to ship.

"We already did our research"

You'll hear this one a lot. A new question comes up, somebody suggests talking to a few customers, and the answer comes back fast: we already did our research. We made our decisions. We're building.

Here's the trouble with that. Research has a shelf life.

The world your customer lives in keeps moving while you build. Their tools change. A competitor ships something. Their budget gets cut, or their boss leaves, or the workaround they complained about six months ago became a thing they don't even think about anymore. The pain you validated was real. It was also a snapshot, and the snapshot is aging the entire time you're heads-down.

So the deck isn't wrong, exactly. It's just describing a customer who's already moved on.

That's the whole case for continuous discovery in one line. A customer is a moving target, and a one-time study aims at where they used to be.

The fix is small and constant, not big and occasional

The instinct, when you realize your research went stale, is to schedule another big study. Another round of interviews, another synthesis, another deck. Six months of confidence, then back to stale.

Don't do the big occasional study. Do the small constant one.

A standing weekly touchpoint with a real customer beats a giant quarterly research project, and it isn't close. Once a week, the people building the product talk to one of the people using it. It doesn't have to be long. It doesn't have to be formal. It has to be regular.

Now your understanding of the customer is never more than a week old. It never gets the chance to go stale, because you were just talking to them on Tuesday.

A small conversation you actually have every week beats a big study you run twice a year. Not because it's more rigorous. Because it's current, and current beats thorough when the target is moving.

Teresa Torres, who wrote the book on this, defines continuous discovery as weekly touchpoints with customers, run by the team building the product, where they do small research activities in pursuit of a specific outcome. Credit to her for the cadence, the name, and the discipline around it. I'll point you at her book at the end. Small, regular, never stopping.

The team does it, not a research department

Notice who's in that weekly conversation. The people building the product. Not a research team that hands a finished deck to the builders.

This is the second half of continuous discovery, and it matters as much as the cadence. Product, design, and engineering do discovery together. Torres calls that group the product trio, a product manager, a designer, and an engineer. Those three because they cover the three questions every build has to answer at once: is it worth doing, can a person use it, can we actually make it. They decide what to learn and what to build as one unit. The reason isn't politeness about including everyone. It's that insight doesn't survive the handoff.

When a researcher interviews a customer and writes it up, the builders get the conclusion. They don't get the hesitation in the customer's voice, the thing the customer almost said and didn't, the moment where you could see the workaround they were embarrassed about. That texture is where the real product decisions live, and it evaporates somewhere between the interview and the deck.

So you put the builders in the room. The engineer who hears a customer describe the workaround builds a different thing than the engineer who reads "users want efficiency" in a slide. The designer who watches someone get stuck designs for that exact moment, not for a persona. Discovery done by the team is discovery that actually changes what gets built. Discovery done by a department becomes a document nobody opens.

Two tracks, running at once

If discovery never stops, and the team is the one doing it, then discovery is happening at the same time as the building. Two tracks, side by side, every week. This is what people mean by dual-track.

One track is delivery. The team is building and shipping the work that's already been validated, meaning you've confirmed with real customers it's worth building. Delivery is its own deep topic. Here, stay on the discovery track.

The other track is discovery. The same team, the same week, is also out talking to customers, testing assumptions, and figuring out what to build next. They run in parallel. You are always shipping something you've already learned is worth building, and you are always learning what to build after it.

Two lanes the team runs in at once, not two phases it moves between. The delivery lane keeps validated work flowing to customers. The discovery lane keeps a steady supply of validated work coming, so the delivery lane never has to guess.

Here's why that beats the phase model. In the phase model, discovery and delivery take turns. You research, then you build, then you research again. While you're building, you're learning nothing. While you're researching, you're shipping nothing. Every handoff between the two is a place where momentum dies and context gets dropped.

Run them together and you don't pay that tax. The team is learning while it builds and building while it learns. The customer stays current because someone talked to one this week. And the next thing in the backlog, the list of work waiting to be built, is already half-understood by the time it's the next thing, because discovery has been chewing on it the whole time delivery was busy.

Where this points: the Opportunity Solution Tree

One pointer before we move on, because people ask how you keep a continuous discovery effort from turning into a pile of disconnected interviews.

Teresa Torres has a tool for exactly this, the Opportunity Solution Tree. The shape is simple. The outcome you're chasing sits at the top. Below it hang the opportunities, the customer needs and pain points you keep hearing. Below those branch the solutions and the tests that tell you whether a solution actually works. Picture an org chart, but for a problem instead of a company. It's a way to keep all that continuous research tied to the outcome you're chasing, so the conversations add up instead of scattering. That's a credited Torres reference, not mine, and the real how-to lives in her book, Continuous Discovery Habits. Read it if you want the full method. I'm naming it here so you know the map exists.

Two pointers before we close, on where this goes from here. When you need the actual tools for running these weekly conversations and experiments, they live in the Toolbox, Part 06. And the delivery track, how validated work actually ships, gets built out later in the playbook, in Part 08.

The heartbeat

So drop the phase. Discovery isn't a thing you finish and file. It's a habit you never stop, because the moment you stop, your understanding of the customer starts aging and you don't feel it happen.

Small touchpoints, every week. The team doing it, not a department. Discovery and delivery running side by side, so you're always building something validated and always validating something to build next.

A phase ends. A heartbeat doesn't. Keep it going.