Continuous Discovery

For a long time, talking to customers was a project. Entering a new market or planning a large redesign meant budgeting a couple of months, interviewing twenty or so people, packaging the findings into a document, and then leaning on that document for the next six.

The trouble is that the document starts aging the day it appears. Writing it up takes three weeks, a competitor ships something during those weeks, and by the time it circulates, some of the behavior it describes has already shifted. Worse, the questions that come up during the three months before the next study have nowhere to go. The team crosses that stretch on instinct.

Pagedeck felt the gap directly. Mia had a well-written document from twenty interviews at the start of the quarter. Two months later someone in a meeting asked why people abandon a document halfway through writing it, and nobody could answer. That question hadn't been asked in the interviews, and the next round of research was four months out. The meeting spent an hour trading guesses and ended.

Continuous discovery closes that gap by shrinking each round of research and running it far more often. Meet one or two people every week instead of twenty every quarter, and a question raised this week can be asked next week. Evidence accumulates at roughly the speed questions appear, which is the whole idea.

Fix the customer conversations into the same slot every week and feed what comes out of them into that week's decisions. Five steps run in a loop.

1. Block a standing weekly time — Tuesday at two, say — on the calendar in advance, and keep the slot even in weeks with nobody booked. Decide to do it whenever there's room and it becomes the first thing a busy week drops.
2. Build a recruiting path that doesn't run dry. A sign-up link inside the product, or an automatic email to recent accounts, keeps a waiting list alive. Hunting for a participant from scratch every week tends to stop after two months.
3. Have product, design, and engineering listen together. When one person runs a customer interview and writes it up for everyone else, most of it dies in the transfer. At Pagedeck, Mia asks the questions, Noa takes notes, and Theo sits in.
4. Post what you heard onto the opportunity solution tree the same day — the map that hangs opportunities under a goal and candidate solutions under each opportunity. Adding to it weekly makes repetition visible, and it keeps what one person said separate from what six people said.
5. Pick one assumption to test next week. The output of this step is a hypothesis. Bring a screens-only prototype into next week's interview and a wrong direction gets caught before anything is built rather than after.

The basics of user research apply throughout the loop. Don't lead people toward the answer you want, and ask what they did last time rather than what they would do in the future.

It fits products where the team can reach users directly. In a service individuals sign up for, participants can be recruited inside the product itself, which is what keeps a weekly rhythm alive. Products sold only to companies are harder: reaching one user means going through a sales contact and booking time on the customer's calendar, and weekly stops being realistic. Those teams stretch the interval to every other week or monthly and fill the gap by reading accumulated voice of the customer (VoC) records and support tickets every week instead.

Three limits come with the practice.

1. You end up meeting the same kind of person. People who volunteer tend to be the ones using the product hard, so after a few months the team has a pile of requests from enthusiasts and has never once heard why someone left. Reach out to churned accounts separately at least once a quarter.
2. Listening is not deciding. Meeting customers weekly doesn't determine what gets built; the team still does. This practice supplies the material for a judgment, not the judgment.
3. There are stretches where it doesn't pay. Attach a weekly validation step to reversible tweaks or to work whose answer is already obvious, and two weeks of work turns into six.

"Two people said the same thing in this week's interviews. I'll hang it on the tree as an opportunity."

What was heard gets filed the same week so it feeds the next decision.

"I'll take this prototype into Tuesday's interview and see how it lands."

The slot for checking something before building it is already on the calendar.

"We don't schedule research. We're doing it every week."

Research is an ongoing activity here, not a project.

Pagedeck fixed Tuesday afternoons as interview time. Mia books two people, and Noa and Theo take turns joining. Within half an hour of finishing, the three of them decide what from that day goes on the tree. Keeping that conversation short is the rule — it's a place to stack material, not to reach conclusions.

About four months in, meetings changed shape. When Grace asks why this feature, Mia answers that nine people have described the same friction over the past six weeks. And a feature nobody has mentioned doesn't get built on someone's say-so; it gets held until the next interview asks about it.

The most common misreading is that the team asks customers what they want each week and builds it. Frequent contact makes that an easy assumption. In practice you don't ask people for solutions, you ask what happened to them. Users describe precisely where they got stuck, but their ideas about fixing it rarely reach past the screens they already know. Build requests verbatim and you accumulate features that don't fit each other while the friction nine people shared stays exactly where it was.

The other misreading is that this is one researcher's job, or one product manager's. A dedicated owner looks efficient. But a dedicated owner splits the people who listen from the people who build, and a document goes back between them — and the document loses the hesitation, the phrasing, and the three seconds someone stalled in front of a screen. An engineer who sits through one interview judges the feasibility side of the four big risks faster than one who has read ten pages of notes.