How many user interviews do you actually need before you build?

Ask this question anywhere and you get a different number depending on who answers. Five, because that's the usability testing figure everyone half remembers from Nielsen Norman Group and quietly applies to a question it was never meant for. Fifty, because one well known startup studio says that's roughly where patterns stop being coincidence. Twenty, because a founder on a podcast did a year of daily interviews and still wasn't sure he'd done enough. None of these people are lying. They are answering a different question than the one you're actually asking.

The question that matters isn't "how many." It's "when do I stop," and those feel the same until you notice they aren't.

What I actually did

I talked to fourteen people over about three weeks, all founders or people building a side project, mostly from two Slack communities and one where I just messaged people whose tweets about feature decisions I'd seen. I asked them how they decided what to build next, not whether they'd use an app like mine, because by that point I'd already read enough about Jobs To Be Done to know that asking people to imagine a future product gets you polite lies.

By interview nine, I had heard the same two sentences, in different words, often enough that I could predict them before people finished saying them. "I built it because I could, not because anyone asked." And: "I only found out it was wrong after I'd already shipped it." That was my signal to stop, not a number on a spreadsheet. Interviews ten through fourteen told me the same thing again, which felt like confirmation at the time and, in hindsight, was actually a warning I didn't read correctly.

The number was never the problem

Here's what fourteen interviews got right. It told me people make feature decisions badly, on vibes and loudest-request-wins, and that a structured set of questions followed by a clear verdict would feel like relief rather than homework. That part of the idea has held up through thousands of App Store downloads.

Here's what fourteen interviews got wrong. Every single person I spoke to was, like me, already past the idea stage. They had a product, or close to one, and were deciding what to add next. Appray's early build assumed that was the main use case, because it was the only use case in the room. It took about two months of support emails to notice that a large chunk of my users were opening Appray before they had anything built at all, to decide whether the idea itself was worth the weekend. The interview questions I'd written, and the whole flow around them, quietly assumed a product already existed. I had to rewrite three of the eight question rounds to stop assuming that.

Fourteen was not too few. Fifty would not have caught this either, if all fifty people had come from the same two Slack communities. The problem was never the count. It was that I interviewed one kind of person very thoroughly and mistook that thoroughness for coverage.

The actual signal is repetition across different rooms, not inside one room

Hearing the same answer nine times from people who already know each other, follow the same newsletters, and read the same three blog posts about MVPs is not nine independent data points. It's one data point said nine times with different punctuation. I didn't understand that distinction clearly enough while I was doing the interviews, only after.

What I'd tell myself now: stop counting people and start counting rooms. If the same sentence comes back from a Slack community, a subreddit, and someone you cornered at a meetup who has never heard of either, that's three real confirmations. If it comes back nine times from one Slack community, that's one confirmation that got repeated, and you should go find a different room before you trust it.

So what number do I actually give people

If someone asks me directly now, I say: however many it takes to hear the same problem from at least three places that don't talk to each other, and no fewer than that even if the first three agree immediately. In practice that has usually meant somewhere between eight and twenty for a narrow problem, more if your idea tries to serve more than one kind of person, which mine quietly did without my noticing.

The uncomfortable addition to that answer is that you can do the right number of interviews, interpret them honestly, and still ship the wrong first version, because the people you managed to reach were never the full picture of who you'd eventually serve. I don't think there's a number that fixes that. There's only noticing it faster than two months, which I didn't manage the first time and now actively watch for, including inside Appray's own question flow, which still occasionally gets rewritten for the same reason.