35% of Failed Startups Cite 'No Market Need' - Are We Still Building Solutions Searching for Problems?

[product_david]

I came across the latest CB Insights data on startup failures, and I had to stop and reflect. 42% of startups still fail because there’s no market need for what they built. Not funding issues. Not team problems. They built something nobody wanted.

In 2026. With all the frameworks, validation tools, and “customer-centric” rhetoric we have now.

The Near-Miss That Taught Me Everything

Last year, we were six weeks away from launching a feature that would have consumed 40% of our engineering capacity for Q3. Beautiful roadmap. Elegant architecture. Executive alignment.

Then I did 15 customer interviews. Not one person had the problem we were solving. Not. One.

We’d spent three months describing features instead of validating problems. We were building a solution searching for a problem.

Three Signals You’re Making The Same Mistake

After reflecting on this and talking to other product leaders, I’ve identified three red flags:

1. You can’t name 10 people who have this problem urgently

Not “might be interested.” Not “said it was cool.” People who are actively suffering from this problem today and would pay to solve it tomorrow.

If you can’t name them by first name and company, you don’t have validated demand.

2. You’re describing features before describing the problem

Listen to your pitch. Are you leading with “We built X that does Y” or “Users struggle with Z, and here’s how we solve it”?

If your deck starts with architecture diagrams and not customer pain points, you’re feature-first, not problem-first.

3. You spend more time on roadmaps than customer conversations

How many hours did you spend on your quarterly roadmap? How many hours did you spend listening to customers describe their workflows?

If the ratio is inverted, you’re building in a vacuum.

The 2026 Context: Agentic PMF

Here’s what makes this even more critical in 2026: Users don’t want dashboards anymore. They want agents.

If your product requires 20 clicks to achieve something an AI agent could do in one, you don’t have product-market fit in the current market. The bar has shifted from “does this work?” to “does this work autonomously?”

The problem isn’t just validating need. It’s validating need in the context of what’s now possible.

Validation Techniques That Actually Work

So what do you do instead? Here are the validation methods that have saved us:

The 40% Rule: Survey your users. If at least 40% say they’d be “very disappointed” if they could no longer use your product, you have PMF. Below that? You’re still searching.

Problem Interviews Before Roadmaps: Talk to 20 users about their workflows before designing solutions. Ask “What did you try today that didn’t work?” not “Would you use this feature?”

Smoke Tests and Landing Pages: Build the promise before building the product. If nobody signs up for the waitlist, nobody will pay for the product.

Willingness to Pay: Don’t just ask if they’d use it. Ask if they’d pay for it. Ask how much. This is where interest becomes demand.

The Uncomfortable Question

I’ll be honest: I’ve built features nobody asked for. I’ve prioritized based on executive opinions instead of customer evidence. I’ve been seduced by the elegance of a solution before validating the problem existed.

Who else is willing to admit they’ve built for the wrong problem?

And more importantly: How do you balance validation discipline with competitive urgency? Because there’s a real tension between “move fast” and “validate thoroughly.”

Would love to hear how others are navigating this in 2026.

[vp_eng_keisha]

David, this hits close to home. I’ve lived this twice in my career, and both times it was painful.

The Beautiful LMS Nobody Asked For

At my previous EdTech startup, we spent six months building what we thought was a revolutionary learning management system for K-12 teachers. Beautiful UI. Sophisticated progress tracking. Integration with 15 different tools.

We showed it to teachers and they said: “This is impressive… but it doesn’t fit our workflow at all.”

We’d built for an idealized version of how we thought teaching worked, not how teaching actually worked. We interviewed administrators and tech coordinators. We didn’t spend enough time watching teachers in their classrooms.

The Engineering Tension Nobody Talks About

Here’s what makes this so hard from an engineering leadership perspective: Engineers want to build. Product managers want to validate. Executives want to ship.

Those three forces create organizational pressure that overwhelms validation discipline. I’ve been in rooms where the VP of Sales says “Our biggest competitor just launched this feature” and suddenly we’re building without asking if our customers even need it.

As VP of Engineering, one of my most important jobs is to slow the team down before we write code. That’s uncomfortable. Engineers feel blocked. Product feels like we’re moving too slow. But the cost of building the wrong thing is always higher than the cost of validating first.

What Actually Works

At my current company, we implemented a simple rule: No code until 20 user interviews.

Not “Let’s talk to customers at some point.” Not “We validated this in a survey.” Twenty actual conversations where we watch people struggle with the current state and describe their workflows in detail.

It’s added maybe 3-4 weeks to our initial discovery phase. But it’s saved us from building features nobody uses at least four times in the last year.

The Question I’m Still Wrestling With

Here’s what I want to ask you and others in this thread: How do you balance validation rigor with competitive urgency?

Because there’s a real risk of over-rotating. Some teams use “we need more validation” as an excuse to never ship. Analysis paralysis is real. I’ve seen teams spend six months validating and their competitor ships in two months and captures the market.

So where’s the line? How do you know when you have enough validation to start building?

[eng_director_luis]

David and Keisha, I’m with you on the importance of validation—but I want to push back a little on the idea that more validation always leads to better outcomes.

The Flip Side: Eternal Validation Can Also Kill You

In financial services, we face strict regulatory requirements. When we build a new payment processing feature, we can’t afford to get it wrong. So yes, we validate extensively.

But here’s what I’ve also observed: Some teams hide behind endless research as a way to avoid the discomfort of building and shipping.

I’ve worked with product teams that spent nine months “validating” and never shipped. They kept finding new customer segments to interview. They kept refining their personas. They kept debating problem definitions.

Meanwhile, a competitor shipped a “good enough” solution in three months and captured the market. By the time we were ready, the conversation had moved on.

My Framework: Three Validation Milestones, Then Ship and Iterate

Here’s what’s worked for me in leading engineering teams:

Milestone 1: Can you name 10 customers with this urgent problem? (David’s test—I love it)

Milestone 2: Have at least 5 of those customers said they’d pay for a solution?

Milestone 3: Can you describe the minimum viable version that solves the core problem?

If you hit those three milestones, you build and ship. Then you iterate based on real usage data, not more hypothetical conversations.

Because here’s the truth: Customers don’t always know what they want until they can touch it. Steve Jobs was famously skeptical of focus groups. Sometimes you have to build to learn.

The Engineering Reality: Pivots Demoralize Teams

Keisha mentioned slowing teams down before writing code—I respect that instinct. But I’ve also seen what happens when engineering teams are constantly pivoting because validation is never “good enough.”

Engineers get demoralized. They stop caring about quality because they assume everything will get thrown away. Turnover increases. Your best people leave because they want to build things that ship.

So my challenge to you, David: What does “good enough” validation look like?

At some point, you have to make a bet and ship. The question is: what’s the minimum bar that lets you confidently place that bet without another six weeks of customer interviews?

[cto_michelle]

This is a great discussion, and Luis raises an important tension. But I want to reframe the question: This isn’t just a product problem. It’s an organizational design problem.

Why Do We Keep Building Solutions Searching for Problems?

The root cause isn’t that product managers don’t know how to validate. It’s that our incentives reward shipping over learning.

Think about how we evaluate product teams:

• “How many features did we ship this quarter?”
• “Did we hit our roadmap commitments?”
• “Are we moving as fast as our competitors?”

Nobody asks: “How many bad ideas did we kill before writing code?”

My First Year as CTO: Three Features Nobody Used

When I became CTO at my current company, we had a backlog of 47 “validated” feature requests. I inherited a team that was shipping fast but not moving the needle on retention or revenue.

Within my first three months, we shipped three features that had been on the roadmap for over a year. Beautiful implementations. On time. On budget.

Usage after 90 days: 4%, 7%, and 11% of active users.

We’d built three solutions searching for problems. And we celebrated shipping them.

The System Fix: Change What You Measure

Here’s what we changed:

Old OKR: Ship 12 features per quarter

New OKR: Validate 15 customer problems per quarter, ship solutions to the top 5

We started measuring:

1. Number of customer problems validated (not features ideated)
2. Number of users with urgent pain (not stakeholders who “like the idea”)
3. Willingness to pay data collected before roadmap commitment
4. Ideas killed in discovery (we celebrate these now)

The result? We ship 40% fewer features. But the features we ship have 3x the adoption rate.

Luis’s Question About “Good Enough” Validation

Luis, you asked what “good enough” validation looks like. Here’s my answer:

Good enough = You can describe the current painful workaround in detail.

If you can’t describe what users are doing today to solve this problem (even if it’s terrible), you haven’t validated the problem. You’ve validated interest in a theoretical solution.

Problem validation isn’t about predicting the future. It’s about understanding the present so clearly that the solution becomes obvious.

The Provocative Question

What if we rewarded product managers for killing bad ideas instead of shipping features?

What if “We talked to 30 customers and decided not to build this” counted as a successful quarter?

Because the most expensive thing a company can do is build the wrong thing. And we keep doing it because we measure activity instead of impact.

[finance_carlos]

Coming at this from the finance side, I want to add a lens that often gets overlooked: No market need = No revenue. The math is simple, but we keep ignoring it.

The Revenue Validation Gap

David, Michelle, Keisha—you’re all talking about problem validation and adoption metrics. But here’s what I see from the finance seat:

Most “validated” features have zero willingness-to-pay data.

Teams will show me surveys where 80% of users say they want a feature. They’ll show me interviews where customers describe pain points. They’ll show me competitive analysis proving the gap exists.

Then I ask: “Did anyone ask if they’d pay for this? And if so, how much?”

Silence.

What I Learned at Square: Usage ≠ Value

At Square, we built features that small businesses loved using. High engagement. Great NPS. Positive feedback in every customer interview.

But when we looked at the unit economics, some of those features were destroying margin. Customers loved them because they were essentially free. The moment we tried to monetize them, usage dropped 60%.

We’d validated interest. We hadn’t validated economic value.

The Pricing Question Nobody Wants to Ask

Here’s the validation question that makes everyone uncomfortable:

“If we charged you per month for this, would you cancel and find another solution?”

Not “Would you like this feature?”
Not “How important is this to your workflow?”
Not “What would you pay for this?” (people always lowball)

Ask the cancellation question. That’s where you find out if there’s real need or just casual interest.

The Latin America Reality Check

We’re expanding our B2B payments platform into Latin America right now. We did extensive validation in the US. Customers loved the product. Clear market need.

Then we launched in Mexico and Brazil.

The workflows are completely different. Tax requirements are different. Banking integrations are different. Risk tolerance is different. What counted as “validated need” in the US didn’t transfer at all.

Market need is always contextual. You can’t validate once and assume it applies everywhere.

My Challenge to Product Teams

Luis asked what “good enough” validation looks like. Michelle said you need to describe the current workaround.

I’ll add the finance version: Good enough validation = You have pricing data before you commit engineering resources.

Not “Would you pay something?” Not “This seems valuable.” Actual data on:

1. How much would you pay monthly?
2. What would make you cancel?
3. What’s your budget for solving this problem today?
4. Who controls that budget?

If you can’t answer those four questions with data, you haven’t validated market need—you’ve validated curiosity.

The Question I Want David to Answer

David, you mentioned your fintech startup almost shipped a feature nobody wanted. How did you handle the conversation with finance and leadership when you killed it?

Because that’s the organizational tension nobody talks about: Killing a feature after three months of investment feels like failure, even when it’s the right call.

How do you create a culture where saying “We validated this doesn’t have market need” is celebrated instead of punished?