पाठशाला Pathshala · ग्राहक Grāhak, The customer · Lesson 09 · Start

From twenty interviews to one decision

Twenty good conversations produce a hundred pages of notes and, left alone, a founder who remembers the last three. Code them, count them and write the one page that decides what to build next.

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

Rows of old file folders standing side by side in a dimly lit room. — Photograph: George Diamanto · Pexels

Twenty good conversations produce a hundred pages of notes and, if nothing is done with them, a founder who remembers the last three and the loudest one. The method below turns the pile into a count and the count into one page that decides what gets built next.

It covers how the pile misleads, how to code notes, what to count, how many interviews are enough, a worked example with twenty chartered accountancy firms, the one-page synthesis and the meeting that acts on it.

The pile, and the two ways it lies

Unprocessed notes mislead in two directions. Recency: the last few interviews are vivid and the first few have faded, so a pattern that appeared early and stopped looks weaker than it was, and a one-off from yesterday looks like a trend. Volume: one articulate, angry customer fills four pages and a quiet one fills half a page, and the four pages win the argument even when the quiet customer described the bigger problem.

Behind both sits the founder’s own hope. Every interviewer hears the evidence for the product already in their head a little louder than the rest. The defence is not more willpower. It is a procedure that converts sentences into counts before anyone argues about them.

Code the notes within a day

Coding sounds academic and is not. The Nielsen Norman Group defines it simply: a code is a word or phrase that acts as a label for a segment of text. Within twenty-four hours of each conversation, read the notes and label every statement about a problem, a workaround, a cost, a decision-maker or a past purchase. Keep codes short and concrete: “2B mismatch”, “assistant overtime”, “client sends late”, “CA decides”. Use the customer’s words where they are sharper than yours.

Blank sticky notes in several colours laid out on a black surface. — One statement to a card and one code to a statement. The sorting is done with a co-founder in the room, not alone. Photograph: Eva Bronzini · Pexels

Two kinds of code are worth separating, as the same NN/g guide does. Descriptive codes say what was said: “uses Excel for matching”. Interpretive codes add your reading: “will pay to save the assistant’s month-end”. Keep both, and keep them visibly apart, because the descriptive ones are evidence and the interpretive ones are hypotheses.

Then put every coded statement on its own card or row: interview number, code, the quote, and a mark if money or time is attached. A spreadsheet works; so does a wall. NN/g’s guide to affinity diagramming describes the wall version: write, cluster related notes, label each cluster with a theme, then prioritise the clusters. Its observation that the discussion while building the wall matters more than the finished wall is worth taking seriously. Do it with your co-founder, not alone.

Count three things: frequency, workaround and money

For each code count how many of the twenty people raised it without being prompted. Then count how many of those already do something about it: a person whose time goes on it, a tool they pay for, a spreadsheet they maintain, a cost they absorb. Then, for those, write the size in rupees or hours a month as they told it to you.

The second count is the one that separates a problem from a complaint. A complaint is raised often and acted on rarely; people mention it because it annoys them and do nothing because it does not cost enough. A problem has a workaround, and the workaround has a price. The [lesson on problems and complaints](/library/how-to-tell-a-problem-from-a-complaint) sets out the distinction; the tally is where it becomes a number.

Teresa Torres’s opportunity solution tree is a useful frame for what the counts become. The root is the outcome the company wants. Under it sit opportunities, the customer needs and pain points heard in interviews. Solutions hang from opportunities, never the other way round. Her point is that limiting the tree to opportunities actually heard in interviews keeps a team working on real needs; the tally tells you which opportunity to start from.

How many is enough

Twenty is a sensible first batch for one segment, for a reason with evidence behind it. In a 2006 study in Field Methods, Greg Guest, Arwen Bunce and Laura Johnson coded sixty in-depth interviews and found that saturation occurred within the first twelve: new interviews stopped producing new codes, and the basic elements of the main themes were present as early as the first six. Their sample was sixty women in two West African countries. A founder’s first segment should be at least as narrow, and that narrowness is part of why twenty is enough.

Two practical tests follow. If the last five interviews produced no new code, stop interviewing this segment and start deciding. If they each produced one, the segment is too broad, and the [segmentation lesson](/library/segmentation-that-changes-what-you-build) is the next read, not another five interviews.

Keep a short list beside the tally for what does not fit: the one customer who described a problem nobody else had, the contradiction between what a partner said and what you saw on their screen, the code that appeared once with a large rupee figure attached. NN/g’s advice is to look actively for data that does not support a theme. A single outlier rarely changes the decision, but three outliers pointing the same way are the start of the next segment, and the list is how you notice them before a competitor does.

A worked example: twenty CA firms in Ahmedabad

A founder building software for small chartered accountancy practices interviews the partners of twenty firms in Ahmedabad, each with between three and fifteen staff, about their GST work. She codes every conversation the same evening. After twenty she has thirty-one codes, and four that appear often.

“Clients send papers late” comes up fifteen times. It is the loudest code by far, and in the room it felt like the answer. But only three partners do anything about it beyond complaining, and none spends money. “GSTR-2B matching”, the monthly work of reconciling clients’ purchase records with what their suppliers have filed, comes up thirteen times, and nine of those firms pay for a workaround: an articled assistant working nights in the week before the return, an Excel template bought from a trainer, or a freelancer paid per client. “Department notices” comes up seven times, five with paid help. “Billing clients for extra work” comes up nine times, twice with any action.

Ranked by mentions plus paid workarounds, matching scores 22, late papers 18, billing 11 and notices 12. Matching is raised by more than eight of twenty, more than half of those pay to work around it, and it leads the runner-up by a little over 1.2 times, short of the house’s one-and-a-half. The verdict is not yet a decision but a narrowing: five more interviews on matching and late papers only, asking what the partner spent on each last month. They do. Matching pulls clear, and late papers turns out to be a complaint about clients that no software will fix.

The one-page synthesis

Write one page, not a deck, with six parts. The segment, in one sentence. The decision, in one sentence: what you will build or test next, and what you will stop. The count: the top five codes with mentions, paid workarounds and the money attached. Three quotes, verbatim, that a stranger would find convincing. What would change the decision: the specific evidence that would make you choose differently. The next test: the smallest thing you will put in front of customers, by when.

The page is written for someone who was not in any of the interviews: a co-founder, an early hire, an investor. If they can read it in three minutes and argue with the decision using its own numbers, it has done its job. If the argument needs you to describe an interview from memory, the page is missing a line.

The loudest complaint fills the notebook. The problem people already pay to work around fills the order book.

The decision meeting, every fortnight

Hold a forty-five-minute meeting every two weeks while discovery is the main work. Before it, everyone codes their own interviews from the fortnight into the shared sheet. In it, read the tally first and the quotes second. Decide one thing: build, test, narrow or stop. Write the decision and the date at the top of the one-page synthesis and keep the old versions; a run of pages that each change the decision is a sign the segment is wrong, not that the customers are confusing.

Then book the next batch of interviews against the question the meeting could not answer. Discovery that ends in a page and a date compounds. Discovery that ends in a feeling has to be done again.

The counts are only as good as the interviews behind them. Twenty conversations that asked about the past will beat fifty that asked about the future, every time.