skip to content

Search

Continuous Discovery: Designing for Real Users at Every Stage

Less than one minute read Updated:

Embedding user research throughout the product lifecycle to ensure continuous alignment with real-world needs.

# product-management
# strategy
# leadership
# lean
# continuous-discovery
Not in series

If your last user interview happened before the kickoff meeting, the research is already stale by the time you ship.

Every team calls its process rigorous. A discovery sprint before the roadmap locks. An intake survey. A round of interviews that gets summarized into a deck, presented once, then filed away while the build runs for the next two quarters. The listening stops exactly when the guessing starts.

At Pixis, that gap almost sank a product. Prism, the AI co-pilot layered on top of the AdRoom creative platform, shipped on schedule and adoption still stalled. The fix was not a redesign meeting. It was fifteen-plus voice-of-customer interviews per launch, every launch, the same habit the home page on this site still points to. That cadence is what continuous discovery means in practice, and it is the argument for the rest of this post.

So that’s today’s post.

Today’s Post

Why research on a timer is not discovery, in five sections.

  • Why one research phase can never keep up with real users
  • The interview cadence that actually catches drift
  • Why engineers and designers belong in the room, not the recap
  • Pairing the story with the number before calling a feature done
  • The three habits that quietly kill discovery, and how to avoid them

1. One research phase is not discovery

A single upfront research phase answers one question well: what did users want on the day you asked them.

It cannot answer what they want six months later, after a competitor shipped something new, after a pricing change, after the feature you built taught them to expect more. User needs move. A phase is frozen the moment it ends.

Continuous discovery is the alternative: research that runs on the same clock as the build, not ahead of it. You define what you are testing before the sprint, you talk to users during it, and you go back afterward to see if the thing you shipped matches what you heard. It is a loop, not a milestone.

One phase versus a loop that runs the whole timeline Both start at kickoff. Only one is still listening when the build hits month three. Grey monospace text names what each block actually does. PHASE Research phase runs once, before build frozen the day it ends build runs on, unwatched LOOP Interview before the sprint 15+ per launch Build same sprint window Prism, AdRoom co-pilot Ship on schedule launch day Re-interview next launch, same cadence users changed since then too back to the next launch, not the same deck a one-time phase, same length as the build but not watching it a loop step, run on the build's own clock
A phase is frozen the moment it ends. A loop runs on the build's own clock, all the way through. PNG ↓

At Pixis, the Prism team had already run its upfront research before I joined the launch. The interviews said people wanted an AI co-pilot. They were right about that and wrong about almost everything else: what people actually did with a co-pilot once it existed looked nothing like the mockups from three months earlier.

2. The interview cadence that actually catches drift

Fifteen-plus interviews sounds like a lot until you notice the second half of that sentence: per launch, every launch.

That is not a research team’s private ritual. It is a standing commitment that shows up on the home page of this site as a stated habit, not a one-off brag: customer in the room, every launch. The point of running it every time, instead of once at the start of a project, is that the fifteenth launch tells you something the first launch could not have, because the users have changed since then too.

Step 1 - Talk to more people than you think you need

Fifteen-plus interviews is deliberately more than the minimum research methodology calls for. The extra volume is what lets you say no to most of it.

Step 2 - Filter hard before it reaches the roadmap

The fifteen-plus interviews on Prism turned into exactly five roadmap features, not fifty. Every idea that did not survive the filter was still useful. It just was not a feature.

Step 3 - Re-run the same cadence on the next launch

The interviews for launch two are not a repeat of launch one. Between them, the product changed and so did what people asked for. Treating cadence as a one-time checkbox is how a team ends up running discovery once and calling it continuous forever after.

3. Why engineers and designers belong in the room

A research summary is a translation, and translations lose things.

When only the researcher or the PM sits in on interviews, everyone else on the team gets a filtered version: the three quotes that made the slide, not the twelve minutes of hesitation before the user answered the question. That hesitation is often the actual finding.

Cross-functional presence fixes this by putting engineers, designers, and whoever else will build the thing, in the room while the user is talking. Nobody has to be convinced by a slide of something they watched happen themselves.

Two rows, one interview each, two different outputs Same user, same questions. The difference is who is watching it happen. Grey monospace text names who is in the room. RESEARCH ONLY User interview researcher or PM only one note-taker Summary deck three quotes survive presented once, filed away CROSS-FUNCTIONAL User interview engineer + designer watch it live the twelve minutes of hesitation Shared decision builder watched the same hesitation the PM saw Prism: five features kept, not fifty translated once, loses the hesitation watched firsthand, needs no convincing
Same interview, two outputs. Watching the hesitation firsthand needs no convincing afterward. PNG ↓

On the Prism launch, that habit is also what kept the roadmap at five features instead of fifty. When the person who has to build a feature hears the same hesitation the PM heard, the argument for cutting it is no longer the PM’s opinion against theirs. It is something they both watched.

4. Pair the story with the number

An interview tells you why something is happening. A dashboard tells you what happened. Neither one is enough alone.

Prism’s interviews explained the adoption problem: people were not learning a new interface to answer a question they could already half-answer somewhere else. The fix, collapsing the query, the creative, and the action into one conversational surface, moved a number: plus 25 percent trial-to-paid and 40 percent less onboarding time.

The story explains it, the number confirms it moved Neither column alone tells you whether the fix worked. Grey monospace text is the interview quote and the metric it predicted. THE STORY THE NUMBER Interview quote "I didn't learn a new tool to answer what I half-know" adoption problem, not a bug predicted One conversational surface query, creative, action collapsed into one the fix the interview pointed at moved +25% trial to paid -40% onboarding time what the interview said and why what the dashboard confirmed after ship
The interview explained the adoption problem. The dashboard confirmed the fix worked. PNG ↓

If you only had the interviews, you would know people were frustrated and not whether the fix actually worked. If you only had the dashboard, you would know trial-to-paid moved and have no idea which of the ten things you changed caused it. You need both, and you need them pointed at the same claim.

5. Three habits that quietly kill discovery

None of these looks like a failure from the inside. Each one is a shortcut a busy team takes without deciding to.

  • Leaning on surveys alone. A survey tells you what people say they want, in the words the survey gave them. It cannot show you the hesitation, the workaround, or the thing the user didn’t think to mention because nobody asked.
  • Treating feasibility as someone else’s problem. Discovery without a feasibility check produces a wish list. Continuous discovery still has to fit inside team capacity and the quarter’s actual priorities, or the interviews just become a longer backlog nobody works through.
  • Keeping findings in one inbox. Research that only one person sees dies with that person’s memory of it. If the team cannot point to where a finding lives, it did not really happen, because nobody can act on it next quarter.
Six stages, closing back into the next interview Ship is not the last step. The loop only works if the last step reliably happens. Grey monospace text is what each stage produces. Scroll slowly, this plays once. Interview talk to users 15+ per launch Synthesize with the builders shared decision, not a deck Prototype cheap enough to be wrong safely Test the prototype before it's built for real Ship on schedule Prism launch day Interview next launch the step most teams skip closes back to interview, not a full stop a research stage, run every launch a build stage, on the same clock ship, the middle of the loop, not the end
Ship is the middle of the loop, not the end. The last step is the one most teams skip. (animates as you scroll to it) PNG ↓

The fix for all three is the same loop from section one, run on a fixed cadence instead of an ad hoc one: interview, synthesize what you heard with the people who will build it, prototype cheaply enough to be wrong safely, test the prototype, ship, and go talk to users again. The loop only works if the last step reliably happens, and that is the step most teams skip once the launch is behind them.

Takeaways

Discovery is a loop, not a phase Five sections on keeping research running as long as the build does Hoshank Ailani · hoshank.vercel.app 1. Phase versus loop A phase answers what users wanted on the day you asked A loop runs on the build's own clock, before, during, after Prism's upfront research got the co-pilot idea right, and almost everything about how people would use it wrong Pixis, AdRoom co-pilot: shipped on schedule, adoption stalled anyway 2. The interview cadence and its filter 1 Talk to more people than the minimum calls for 2 Filter hard before anything reaches the roadmap 3 Re-run it every launch, users changed too 15+ interviews per launch, every launch, five roadmap features kept 3. Who is in the room A summary deck is a translation, and translations lose things Engineers and designers watch the interview, not just the recap A finding becomes a decision once the builder hears it firsthand the twelve minutes of hesitation the slide never shows 4. Pair the story with the number interview: didn't learn a new tool for what I half-know fix: query, creative, and action in one surface +25% / -40% trial-to-paid up, onboarding time down, same launch 5. Three habits that kill discovery quietly Surveys alone, feasibility as someone else's problem, findings in one inbox no dramatic failure, just three shortcuts a busy team takes without deciding to If your last interview was before the kickoff, the research is already stale. Book the next interview before you book the next sprint. Full post: hoshank.vercel.app/posts/continuous-discovery Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Five panels, one per section. The through-line is the same one from the top: research that stops when the build starts is not discovery, it is a snapshot.

Final Words

Pick the last feature your team shipped and ask when the team last talked to a user about it. If the answer is before the kickoff meeting, you have your next move: book the next interview before you book the next sprint.

Reply and tell me what you find. I am collecting examples for a follow-up on how teams actually run the cadence, not just the philosophy.

Cheers, Hoshank