पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 14 · Build

Talking to users while you build: the weekly five

Research is not a phase that ends when building starts. Five short sessions a week, booked like stand-ups and triaged every Friday, keep the sprint honest without throwing it off course.

Pathshala, The Founder Library · 11 October 2026 · 7 min read

Two worn wooden chairs and a small table stand against a wall outdoors in black and white. — Photograph: Peter Dyllong · Pexels

Founders talk to users constantly before they build and almost never once the build starts. The sprint fills the calendar, the backlog feels like knowledge, and three months later the team ships something carefully made for the customer it imagined in week one. The fix is not more research. It is a small amount of research that never stops.

This lesson sets up the weekly five: five short sessions with users every week of development, a fixed mix of what each session is for, a way to recruit them without a research team, and a Friday routine that folds what you learn into the next sprint without tearing up the current one. The figure shows why five is enough for a round, and why the sixth person is better spent next week.

Why five, and why every week

Jakob Nielsen’s Why You Only Need to Test with 5 Users rests on a model he built with Thomas Landauer. The share of a design’s usability problems found by n users is 1 − (1 − L)ⁿ, where L is the share a single user reveals; across the projects they studied L averaged 31 per cent. Five users find about 85 per cent. His recommendation is the part founders skip: if you have budget for fifteen users, run three studies of five rather than one of fifteen, fixing the design between rounds. Each round tests a better product and finds the problems the last round’s problems were hiding.

A team that builds every week is producing a new design every week. A study done in March tells you about the March product. The weekly five turns Nielsen’s three-rounds advice into a standing habit, so that every build gets its round. It also matters because most of what a team ships does not work as intended. The Microsoft experimentation paper by Ronny Kohavi and colleagues found that only about one third of ideas improved the metrics they were designed to improve. Watching five people use a change is the fastest way to find out which third you are in, days before the numbers can say.

Move the first slider down for a complex product, such as accounting or logistics software, where each user exercises a smaller part of the system. The number of users needed for a thorough round rises quickly. That is an argument for narrowing each week’s sessions to the part of the product that just changed, not for running bigger rounds.

The five sessions, and what each is for

Two usability sessions on the current build. Give the user a real task in the part of the product that changed this week, ask them to think aloud and say nothing. Write down where they hesitate, what they misread and what they try that does not work. These two sessions catch the problems the figure counts. Two recent-behaviour interviews. Not about the product but about the job: the last time they reconciled payments, booked a technician or chased an invoice. Use the five questions from Eric Migicovsky’s How to Talk to Users, starting with “Tell me about the last time that you encountered this problem”, and avoid his three mistakes: pitching, asking about hypotheticals and talking too much. The [customer interview lesson](/library/the-customer-interview-done-properly) has the full protocol.

One session at the edge. A user who churned last month, one who signed up and never reached the [aha moment](/library/activation-first-session-that-decides), or someone from a segment the company is about to target. This is the session most teams skip, because the conversation is uncomfortable and the person owes you nothing. It is also the one most likely to tell you something the rest of the week could not.

Thirty minutes each. Two and a half hours of user time a week, plus about the same again for notes and recruiting. For a team of five working forty hours a week that is about three per cent of its time, spent on the only input that tells it whether the other ninety-seven per cent is pointed the right way.

Recruiting without a research team

Migicovsky’s simplest advice is the one that makes the habit possible: collect phone numbers at sign-up, so that when the data raises a question you can call someone. In India add a line asking which language they prefer and whether WhatsApp is fine, and build a standing pool of users who have agreed to be called. Fifty people in the pool, each asked no more than once a month, keep five sessions a week supplied.

A vendor serves tea at a roadside stall on a street in Jodhpur. — Go where the job happens. A session at the counter shows what a video call never will. Photograph: sajhad · Pexels

Make it easy to say yes. Offer fixed slots, say Tuesday and Thursday afternoons, by WhatsApp with a one-tap reply. Go to the user when the job happens somewhere physical: the shop counter, the clinic reception, the godown office. The [field research lesson](/library/field-research-watching-instead-of-asking) covers what you see there that a video call hides. A small thank-you, sent the same day, matters more than its size.

Use a short survey to decide whom to call. Superhuman, as its chief executive told First Round, asked users how they would feel if they could no longer use the product, tracked the share answering “very disappointed” weekly, monthly and quarterly, and built half its roadmap around what that group loved and half around what held back the “somewhat disappointed”. The answers sort your pool: talk to the very disappointed to learn what to protect and to the somewhat disappointed to learn what to fix.

Who is in the room

The founder or product lead runs the session. The engineer building the feature in question attends, camera off and silent, at least one session in five. Teresa Torres’s Continuous Discovery Habits is written for the product trio, a product manager, a designer and an engineer who interview customers together, and the reason applies to a team of four. A finding relayed in a ticket is an instruction. A finding watched first-hand is a fact the engineer owns, and they will often see a fix the product lead could not.

Notes go into one shared document in a fixed shape: date, user, segment, session type, what they did, exact quotes, and a one-line “so what”. Record with permission and say how the recording will be used, as the [DPDP lesson](/library/dpdp-act-what-it-requires-of-your-product) requires of any personal data you collect.

One session changes nothing. A pattern across three changes the next sprint. Nothing changes the current one except a defect that stops the job.

Folding findings into the sprint

The fear that stops teams doing this is that research will derail the plan. It does only if every session is allowed to change it. Run a Friday triage, thirty minutes, that sorts the week’s findings into three bins. Fix this week: small, clear and inside the part of the product already changing; a confusing label, a missing confirmation, a default that is wrong. These go on the next release train. Evidence for a spec: a problem bigger than a fix, which gets appended to the problem block of the relevant spec with the quote and the count. Tally: everything else, written down with a count beside it and left alone.

Clay cups stacked in tall columns at an outdoor market in Ghaziabad. — One observation is a cup. Three of the same, from three different people, is a stack worth carrying into the next sprint. Photograph: Veyant Singh · Pexels

The rule that protects the sprint: one observation is an anecdote, three of five sessions is a pattern. A pattern earns a place in the next sprint’s planning; it does not interrupt the current one. The only exception is a defect that stops users doing the job the product exists for, which is a bug and is fixed now. Over a quarter, the tally column is the most useful document the team owns. Items that keep coming back are the problems worth a spec; items that never recur were noise.

A week in practice, for a clinic-booking product in Pune. Both usability sessions show receptionists missing the new reschedule button, which sits below the fold on a small phone: fix this week, move it up. One interview reveals that patients rebook by calling the clinic rather than through the link the product sends, because the link expires overnight: evidence, appended to next month’s reminders spec with the quote. The edge session, with a clinic that churned, blames the monthly invoice format: one mention, tallied. In week seven the invoice format reaches its third mention from three different clinics, and it goes into planning with the three quotes attached.

The weekly calendar

Monday: confirm five slots for the week from the pool and decide which session types each is. Tuesday and Thursday: two or three sessions each day, the builder attending at least one. Same day: notes in the shared document, a thank-you sent. Friday: thirty-minute triage into fix, evidence and tally; update the counts. Once a month: refresh the pool, rerun the “very disappointed” question, and read the tally from the top. Twelve weeks of this is sixty conversations and twelve tested builds, and a team that has had them will argue less about what users want because it will have watched them.

The figure uses Nielsen and Landauer’s published model and average; your own share of problems per user will differ by product.