Early on, talking to people beats adding features, and the gap is not close. The largest recent post-mortem study is CB Insights' analysis of 431 venture-backed companies that shut down since 2023, published in March 2026. It found poor product-market fit behind 43% of the failures, second only to running out of money at 70%.

CB Insights' own reading is that running out of capital is usually the final cause of death rather than the root problem. Two-thirds of the product-market-fit failures were early-stage companies that never found a market at all.

What that number does and does not tell you

It is venture-backed companies, not solo founders and not indie devs, so do not treat 43% as your personal odds. Post-mortems are also self-reported, and "no market need" is an easier thing to write in a shutdown note than some of the alternatives.

What it is good for is the shape of the thing: companies with money, staff and runway still most often die because not enough people wanted what they built. Nothing about being small protects you from that. Being small just means you find out with less cushion.

Why building wins the day even when it should not

Because it looks like progress. When you are iterating, moving buttons around the screen, it feels like you are doing such important things. If you never checked that your users even want that button, you are actually wasting your time.

Research produces understanding, which does not photograph well and never feels finished.

How much talking is enough

Less than people fear. After about five people of the same kind, you start hearing the same problems repeated; by seven, roughly half of each conversation is a repeat. Three is enough to keep moving.

Then it becomes periodic rather than constant. Keep interviewing through the life of the product, the way an elected representative has to keep talking to the people who voted for them, because what mattered three years ago is not what matters now.

Why not just ship it and read the feedback?

Because of what happens to the conversation once there is something on screen. A lot of developers build and then show people to get feedback, and users get distracted by what is there. They stop describing their life and start reacting to your product. Validating the concept gets you better information than validating with the product.

And what people say they would love to do is not evidence. If someone tells me they would love to do a thing, I do not count it. What I count is what they already do.

Surveys are the tempting shortcut here and they are weaker for the same reason: you cannot probe, you cannot hear tone, and you get the aspirational answer. It is also harder to get enough survey responses to be useful than to get a handful of conversations.

What to do instead of choosing

• Before there is a product: nearly all conversation, then build the smallest useful thing.
• While building: enough conversation to keep answering the questions the build raises, and a prototype in front of people before the real version.
• After launch: analytics so you can see where people stop, and direct messages to the ones who stopped. They will tell you, if you ask honestly.

Notice that none of those three is a stage where you stop talking to people. That is the actual answer to the question in the title. It was never talking against building, it was talking as the thing that tells you what to build next.

Keep reading

How Do I Validate an App Idea Without Building It?

Validation Before Building vs. Building Then Pivoting: Which Is Less Expensive?

How to Talk to Users When You're a Developer, and Find It Deeply Uncomfortable

Learn this with me

Half of From Passion to Product is this: who to talk to, what to ask, and how to turn what you hear into evidence you can act on. It is free, six weeks and live, and weeks one to three are all research before a single feature is designed.

There is a drop-in session timed for the week you are doing your interviews, because that is the week people get stuck.

I teach the same material to engineering teams, from a one day workshop to the full six weeks, for teams who want to do their own discovery instead of waiting to be handed requirements.

Join the waitlist, get the workbook, or look at the team programs.