Discovery happens at every kickoff, then delivery pressure wins and the calls go quiet. Why episodic discovery fails the strategic decisions that arrive between projects - and how to make every user contact compound instead of evaporate.
Think about the last time your team ran user interviews. Almost certainly it was at the start of something: a new initiative got approved, a discovery phase appeared on the plan, calls were scheduled, notes were taken, a readout was presented. Then the build started - and the calls stopped. Not by decision; nobody decided anything. Delivery filled the calendar, and the next interview quietly became something that would happen at the next kickoff.
If your team works this way, it is in the majority, including among teams that would describe themselves as user-driven. A head of product at an edtech company described her team's steady state to us without any embarrassment, because there is nothing unusual in it:
"We have a channel with a few thousand learners in it - when there's a hypothesis to validate, we send a survey there. Once in a while we'll interview users for testing. But there's no fixed cadence for any of it."
- a head of product at an edtech company
Notice what this setup is good at and what it is not. A channel with thousands of users answers the questions you already have: post a survey, get a signal, move on. What it never does is keep your understanding current - it responds to hypotheses; it doesn't generate the exposure that produces them. And the interviews that would generate that exposure hang on individual initiative: on most teams, discovery between projects happens only if a PM personally decides to reach out, and personal initiative is precisely the resource that delivery consumes first. Everyone we've interviewed tells a version of the same story - discovery is real at the start of an initiative, then people get busy, and the calls go sparse. The backlog doesn't suffer; surveys and support tickets keep it full. So nothing visibly breaks.
The standard diagnosis of this pattern is a discipline failure, and the standard prescription is to try harder: book the weekly slot, adopt the habit, be more like the teams in the books. This essay makes a different diagnosis. The episodic pattern is not a failure of discipline - under delivery pressure it is close to inevitable - and the prescription that follows from it is not a better calendar. The real failure is one of accounting: each episode of discovery produces something that evaporates, so the episodes never add up. To see what evaporates, start with where the cost actually lands - because it is not where most teams look.
Here is the strange thing about working between kickoffs, with no discovery cadence: day to day, nothing hurts. Features still ship, and mostly they are not even bad. That is because feature decisions are local - the context they need can usually be scraped together from tickets, survey answers, and a couple of calls scoped to the feature itself. A senior PM at a B2B software company described how her team budgets for this, and it is entirely sensible:
"It really depends on the urgency and scale of the feature. Because this feature involved a lot of departments, we needed to do sufficient discovery."
- a senior PM at a B2B software company
Discovery, in this model, is a per-feature cost, sized to the feature's risk. A PM in a Reddit thread about discovery process made the same point as a boast rather than a budget: "I can do 4-6 interviews and get an 80/20 answer on whatever I need, then spend the rest of the time building instead." At feature altitude, he is right. Four to six interviews genuinely will answer a question the size of a feature.
The bill for episodic discovery arrives at a different altitude, and usually between projects. Strategy, positioning, pricing, a market pivot, the annual roadmap - these decisions are not scoped to a feature, and no feature's discovery budget ever produced the understanding they need. One product lead told us exactly this: her team always had enough user feedback to keep building - and still found that when the important decisions came, the deep understanding of specific customers that would let them decide with confidence simply wasn't there. A product designer we interviewed made the structural observation underneath that experience, watching the PMs around her:
"The discovery our PMs do is never strategic - it never holds problems at a high level."
- a product designer at a B2B data-tools company
This is not a criticism of those PMs. Project discovery answers the project's question; that is what it is for. The inference to draw is quieter and more uncomfortable: strategic understanding is not a byproduct of shipping projects. You can run perfectly good per-feature discovery for three years and arrive at the big decision with nothing that operates at its altitude - because every episode was scoped below it, and nothing connected the episodes.
The natural response, once a strategic decision is actually on the table, is to rebuild understanding on demand: commission a research push, schedule a blitz of interviews, get grounded in a quarter. The same designer had already priced this plan, in the sentence we have come to treat as the center of this problem:
"Building the empathy to make good decisions is measured in years - you don't get it by sitting through a few calls."
- a product designer at a B2B data-tools company
If she is right - and everything we have observed says she is - then the blitz is structurally too late. What a blitz produces is a stack of fresh transcripts and a deadline; what the decision needed was the accumulated, cross-checked feel for the market that only long exposure builds. A PM in that same Reddit thread described what research-on-demand turns into when teams attempt it anyway: "discovery is supposed to reduce uncertainty, but too often it either gets dragged out unnecessarily or becomes its own never-ending feedback loop." Three months of talking, and then the window to decide has moved.
It is worth pausing on that Reddit thread, because the argument that ran through it is the argument most product organizations are silently having. One camp warned that "some people think they can outsource making decisions if they just collect enough data." The other side of the thread answered with intuition: "much of the time it comes down to the individual having good instincts and intuition about how the world works, understanding how people make choices and why a certain kind of a product will win in the market."
Data versus gut, process versus instinct - the thread treated these as opposites, and so do most teams. But look at what intuition of the kind that second PM describes actually is: it is accumulated exposure to users, retained and cross-referenced, available at the moment of decision. It is not an alternative to evidence; it is evidence that has been successfully banked. The intuition camp is right that big decisions are made from accumulation, not from a fresh data pull. Where both camps go wrong is in assuming the accumulation can't be built deliberately - that you either have the years or you don't. Whether you have the years depends entirely on whether the exposure you did get was retained. Which returns us to the question the first section left open: what happens to the understanding a discovery episode produces?
Follow one discovery episode to the end of its life. Interviews happen; the people in the room take notes; the notes get briefed to the team; a readout lands in a deck or a doc; the feature ships. Now ask where the understanding lives a quarter later. The deck is in a drive. The doc has drifted away from anything the team currently looks at. The notes mean something only to the people who took them - and mostly what remains is what those individuals happen to remember. When they change teams or companies, even that leaves. The next initiative kicks off, near zero, and schedules its own discovery phase to rebuild what the last one already knew.
This is the accounting failure. The episodes were real; the insight was real; but it was stored in forms that decay - memory, momentum, documents with no live connection to anything. The years of empathy the designer priced never accumulate, not because the exposure didn't happen, but because almost none of it was banked. Seen this way, the unit of discovery that matters is not the research project. It is the deposit: the individual piece of understanding that either enters a durable, shared store or evaporates with the episode that produced it.
And a deposit has one non-negotiable property, which the rest of this essay depends on: it must stay attached to its evidence. A conclusion filed without the words underneath it doesn't accumulate - it decays into folklore, something the team believes without being able to say why, impossible to re-examine when the market shifts or a new decision puts it under load. What compounds is not conclusions. It is conclusions that can still be audited: the pattern, plus the verbatim quotes of the people who are the pattern.
This is the specific thing CLRA is built to be: not a research tool for the next study, but the durable store the deposits go into - a problem map that accumulates across projects instead of resetting with each one.
The loop, per user contact, is deliberately light, because deposits only happen if depositing is cheap. Any contact goes in as an interview - a full transcript, the notes from a twenty-minute call, a support conversation worth keeping; if it already lives in markdown, the CLRA MCP server pipes it in without copy-pasting. CLRA's AI does the production work of extraction: it reads the note and surfaces candidate insights as highlights, each anchored to the exact place in the source it came from. You judge them - keep what's real, discard what's hollow - and link what survives to problems, framed as job stories: when I'm in this situation, I want this, so that I can have that.
The compounding happens at the problem, and this is the part no per-project setup gives you. A problem in CLRA is not a document a project wrote once; it is a container that keeps collecting. When the third initiative this year brushes against the same user struggle, its interview doesn't found a new doc in a new folder - its highlights land on the same problem, which gets heavier: more voices, more contexts, more verbatim language, its priority reflecting the accumulating weight. The map as a whole becomes the team's current understanding of its users, and every claim on it is one click from the words of the people who said it.
Then the strategic decision arrives, and the difference shows. Instead of commissioning a blitz - the too-late sprint from earlier - you open the map your team has been feeding all along, at exactly the altitude features never operate at: problems, weighted by evidence, current as of the last contact anyone banked. The empathy measured in years turns out to have been accumulating the whole time, in a form that survives staff turnover and re-examination alike.
Unlike Notion or Confluence, where research lives as documents written once and reopened rarely, CLRA is not a doc - it is a living problem map that grows with every interview your team runs. The doc model stores episodes. The map model compounds them. That is the entire difference, and it is the difference the between-projects decisions are made of.
Return to the quiet after your last kickoff - the calls that went sparse while the backlog stayed full. The argument of this essay is that the sparseness was never the disease. It was a symptom of an economy in which each call was worth too little to protect: its insight would evaporate with the episode, so when delivery pressed, there was genuinely not much to defend. Teams don't sustain rituals whose outputs they watch disappear.
Change the accounting and the cadence follows. When every contact - however small, however far from a formal study - deposits into a map that compounds, a thin trickle of calls still accumulates into something. The weekly interview stops being a discipline you owe to a methodology and becomes what a deposit into an appreciating asset always is: obviously worth the twenty minutes. And the next kickoff opens not with a discovery phase rebuilding last year's understanding from zero, but with a map that already knows - asking only what has changed.
Give your team's understanding somewhere to accumulate: create a free workspace - and if your discovery starts in online communities, the CLRA extension banks those quotes too.
