Why Great Startup Ideas Die Before They Scale

Okay, so a founder walks in with this brilliant idea. Everyone claps. What actually makes it brilliant?

Start with Y Combinator's framing. The whole goal is to make something people want. If an idea doesn't connect what a team can build to a real need, it's just, it's just clever.

But clever sounds like enough when you're pitching.

Right, and that's the trap. An idea is a starting hypothesis. Not proof of demand. Y Combinator tells founders to launch so they can learn whether the product meets customers' needs.

So the idea is almost like a, a guess you write down?

Exactly. And the learning loop is launch, talk to users, use their feedback, iterate. That's the whole engine.

Where do the guesses come from, though? Is there a pattern?

Jessica Livingston of Y Combinator has a take I like. Start by solving a problem you have yourself, then learn quickly whether others share it.

Because you've lived the pain?

Personal experience gives a founder insight. But Livingston cautions the product can't just serve its creator. It has to move beyond you.

Hold on—doesn't that contradict the personal-problem advice?

It's a tension, not a contradiction. And it's big enough that people argue about it. Take a listen to how Shawn Zhang put it on the Founder's Story podcast. [[CLIP:97fd62bd-617f-4f47-b364-63b76fb035f0:Founder's Story — Shawn Zhang:35422]]

'As long as you have a problem, you have a business.' That's, that's very clean.

Clean, but notice what he's rejecting—building a cool technology first and then hunting for someone to sell it to. He calls that a recipe for disaster.

So problem first, tech second. What happens after launch, when nobody shows up?

That's where Paul Graham comes in. He argues founders often have to recruit their first users manually rather than wait for them to arrive.

Manually? Like, one by one?

One by one. And then watch which early users are most enthusiastic, and go find more people like them. For hardware startups he even describes founders assembling products by hand—he calls it 'pulling a Meraki.'

Pulling a Meraki. Okay. But surely at some point that doesn't scale?

And that's the sequencing question. Graham's 'startup as a vector' framing pairs what you'll build with the early, often manual work you'll do to get going. In B2B, a founder works closely with one customer, adjusts the product, then looks for shared needs.

So don't scale until—

Exactly. Y Combinator cautions against scaling product or team before the product is wanted. Building scale infrastructure too early just wastes time and effort.

Which is why so many founders stall. They build for a crowd that never confirmed it wanted the thing.

Which is why the early stage is basically two tasks—write code, talk to users. That's it.

Okay, but how often does any of this actually work? Do we have numbers?

The U.S. Bureau of Labor Statistics tracks cohorts of new establishments over time. One figure that stopped me: 34.7 percent of establishments born in 2013 were still operating ten years later, in 2023.

A third. That's... a coin flip weighted against you.

And survival varies by industry, business cycle, and location. Health care and social assistance consistently ranks higher; construction lower. Startups that hit a recession early generally show lower five-year survival.

Wait—the 2018 cohort? Anyone?

57.3 percent survived five years. The highest five-year rate in that table. Timing really is its own variable.

So with those odds, why does anyone start? What do startups give back?

BLS describes startups as the main source of net employment growth. Existing businesses collectively have mostly been net job destroyers—startups are the net job creators in their debut year.

So the idea is the hypothesis, the users are the proof, and the odds are brutal but the upside is real.

That's the lens for everything ahead. Which raises the question we'll keep circling—what makes an idea not just good, but great enough to build a company around?

Look, I keep coming back to this. One person sees what nobody else sees, and drags the future into the room. That's the story I believe.

And it's not a dumb story. It's just incomplete. So let's actually test it against the evidence, both directions.

Fine. But if the lone genius is a myth, why does every founder biography read like one person's vision?

Because the story can obscure the mechanics. Research on inventors describes collaboration and learning between inventors as core parts of producing innovations.

Even the archetypal founder stories hide collaborators once you look closely. Here's Peter High on the Technovation with Peter High podcast, on the talent around Steve Jobs. [[CLIP:8b41da2c-6a44-44d9-9a2d-1421a2e58615:Technovation with Peter High (CIO, CTO, CDO, CXO Interviews) — Peter High:28343]]

Wozniak, Lasseter, Catmull. So the lone-genius biography is really a staffing chart with one name on the cover.

Okay, but that's vague. Do we have actual numbers?

We do. A study of more than 65 million papers, patents, and software products, spanning 1954 to 2014, published in *Nature*.

Sixty‑five million? That's not a sample, that's, that's a civilization.

Right. And the finding cuts both ways, which is why I like it. Smaller teams tended to disrupt existing ideas. Larger teams tended to develop them.

Wait. So my lone‑genius instinct isn't wrong?

Partly right. Same individuals produced more disruptive work in smaller teams than in larger ones. The effect wasn't just different people choosing different team sizes.

Huh. And the big teams?

Their work built on more recent, popular developments. Small teams reached further into the past for their raw material.

How would a person even measure 'disruptive' across millions of things?

Citations. Work counted as more disruptive when later papers citing it didn't also cite many of its references. It breaks with what came before.

So one person's ordinary week, a small team, they're, they're hunting in old libraries nobody visits—

Stop. Yes, that's the picture. And the lone genius sits at the extreme end of it.

But give me a case where the big collaboration was clearly essential. For example—

Margaret Hamilton. She led software teams for NASA's Apollo program.

Led. So not a lone genius either.

Over 400 people were working on Apollo software by 1968. Her team designed priority‑driven software that could set aside lower‑priority tasks during an overload.

And that mattered when—

During Apollo 11's lunar landing. Mission Control's confidence in that software helped the decision to proceed. One person's vision, hundreds of hands.

Okay, so teams win? Because I sense a 'but' coming.

Good instinct. The Nature researchers concluded both small and large teams matter. They support a mix of team sizes, not one best size. These are tendencies, not rules.

So which part of teaming actually does the work? Is it just having people around?

That's the question Google asked with Project Aristotle. They studied what made their teams effective, and the answer emphasized how members work together, not simply who's on the team.

And Google is a perfect example of that, a two-person origin that turned on how the pair worked together. Here's the Corporate Atlas podcast on how it started. [[CLIP:c55b3a4d-08de-4441-822f-133e9fa09775:The Corporate Atlas — Google's Origins and PageRank:32705]]

Two people, one research project, one reframed question. Small team, hunting for an insight nobody else had framed that way.

Give me the list.

psychological safety, dependability, structure and clarity, meaning, and impact.

Psychological safety, that's... people feeling safe to ask dumb questions?

Safe to take interpersonal risks. Asking questions, admitting mistakes, offering ideas. And Edmondson tested this in 1999, 51 work teams at a manufacturing company.

And what did she find?

Psychological safety was associated with team learning behavior, and that learning mediated the link to performance. She also separated it from plain confidence in the team.

Which is the mechanism I was asking about. It's not critique, it's that people can speak—

Which is why a lone founder who believes their own myth may go unchallenged, and a founder who hides inside a big team is less likely to disrupt.

So I pick the small team, I guess.

That would be my choice, for the most disruptive stage. But it holds up because the finding shows the same person tends to be more disruptive in smaller teams—it's not about hiring geniuses.

So picture an ordinary week. Rent's due, money's short, and some conference is filling your city. It doesn't sound like a startup story yet.

And yet that week in San Francisco in 2007 is where Airbnb starts. Brian Chesky and Joe Gebbia couldn't afford their rent.

That's it? Rent trouble?

Rent trouble plus one observation. A design conference was arriving, and hotel space was limited. Two ordinary facts, pushed together.

So what did they actually do?

They made a simple website offering three air mattresses and breakfast. Three early renters each paid eighty dollars.

This is how Evan Carmichael on the Evan Carmichael - Believe: Unlocking Your True Potential podcast tells that moment. [[CLIP:48703d0f-016e-45fe-9743-3ee2c6107be8:Evan Carmichael - Believe- Unlocking Your True Potential — Evan Carmichael:20297]]

Barely affording groceries, and the answer was literally on their floor. Wild is one word for it.

Eighty. So the company that, that reshaped travel began with air mattresses on a floor.

And it gets better. The company's own history dates first guests to October 2007, and the official launch, as Airbed & Breakfast, during SXSW in March 2008.

And how did that launch go?

Two bookings.

Two.

Two. But then the founders got emails asking when the site would serve Buenos Aires, London, Japan.

Okay, but hold on. I've been broke during a conference. Lots of people have. Why them?

That's the real question, and there's research on it. Scott Shane studied entrepreneurs who all encountered the same MIT-invented 3D-printing process.

Same technology, same—

Same invention. But they identified different opportunities, shaped by information they already had. Prior knowledge of markets, customer problems, ways to serve customers.

So seeing the thing isn't the, the ticket. Many people encountered that invention, right?

Many did. A notably small number saw a business in it. The entrepreneurs in Shane's interviews weren't even looking for a venture—they described recognizing it almost by accident.

Almost by accident. That's the part I don't love, honestly. It sounds like luck.

It sounds like luck until you look at what researchers call alertness. Three connected activities: scanning for information, connecting disparate pieces, and evaluating whether it points to an opportunity.

So the accident lands on the person who was already paying attention.

Exactly. For example, think of AptDeco. Reham Fagiri had an uncomfortable time selling furniture while moving. Her co-founder Kalam Dennis couldn't sell a couch.

Two furniture frustrations, one marketplace. But wait—how do I know a frustration is shared and not just mine?

You test it the way the DoorDash team did. They interviewed 60 small-business owners, and heard a Menlo Park bakery turned away 10 to 15 delivery orders a week.

Turned away orders. Demand they couldn't serve, sitting right there.

And they went further. Team members worked part-time as Domino's and FedEx drivers to learn delivery operations firsthand.

So Dennis delivering his own couch at AptDeco is the same move.

Same move. Living the problem, then watching the model in practice. Steve Blank's framing helps here: test assumptions by speaking directly with prospective customers and gathering evidence.

Rather than writing a plan first?

Blank says a business plan is most useful when customers, channels, competitors, and costs are already known. Early on, they aren't.

But Airbnb's big wall was trust, wasn't it? Strangers, homes, money.

Their S-1 describes trust between strangers as a central design challenge. Profiles, messaging, two-way reviews, secure payments—those were the trust-building features.

And AptDeco had its own version—didn't they change something midstream?

They did. Outside moving companies produced poor service and higher prices, so the founders changed their approach.

So the willingness to dwell on an ordinary annoyance... that's, that's the founder trait hiding in a normal week.

Most people feel the frustration; the founder stays with it long enough to see the problem underneath.

Which means next time I'm stuck in a slow line or turning something away... I should ask who else is standing there with me.

That's it. The idea sneaks in wearing yesterday's clothes.