Learning From Failure Without the Drama

Suman SharmaSuman Sharma

Startup failure stories are usually told like movies: the big bet, the crash, the lesson.

Most real failure isn't like that. It's quieter. A wrong assumption that cost a few weeks. A check you skipped. A feature nobody used. Small things that add up, and that are easy to leave out of the story.

What this means

Failure, in the useful sense, is when reality doesn't match what you expected.

That happens constantly when you're building something new. It isn't a sign you're doing it wrong. It's the main way you learn anything. What matters is whether you notice it, understand it, and change something.

What I learned

I wrote a full list of things I got wrong building HairOver. Looking at the list, there's a clear pattern. Almost none of the mistakes were about skill. They were about skipping the step where you check against reality:

  • Pricing without checking the app store's real fees
  • Redesigning the landing page without checking what visitors did
  • Showing match scores without checking if they helped anyone choose
  • Pre-writing posts without checking if the events had happened

None of these were dramatic. All of them were avoidable. That's the kind of failure I think is most worth learning from, because it's the kind you'll repeat if you don't notice it.

The common types, simply

Bad assumptions. You believed something that wasn't true. "People will pay for this." "This pack is a better deal."

Pricing mistakes. Costs left out, tiers that don't make sense, prices copied from someone else.

Marketing mistakes. Wrong audience, wrong message, measuring likes instead of customers.

Unnecessary features. Things built because they were interesting, not because users needed them.

Weak distribution. A good product nobody finds.

Poor positioning. People don't immediately understand what it's for or why it's different.

Ignoring feedback. Hearing something uncomfortable and explaining it away.

A simple way to review a failed experiment

After something doesn't work, I try to answer four questions. It takes ten minutes:

  1. What did I expect? Be specific.
  2. What actually happened? Just the facts.
  3. Which assumption was wrong? There's usually one main one.
  4. What will I do differently? One concrete change.

For example, from HairOver's pricing:

  1. Expected: a 64% margin on the $7 pack.
  2. Happened: the real margin was about 58% once the app store's 15% cut was included.
  3. Wrong assumption: that revenue was the full sale price.
  4. Change: platform fees go into every model first.

Short and specific. No drama needed.

Sunk cost

Sunk cost is continuing something because of what you've already put in: "I've spent three months on this feature, I can't drop it now."

The problem is that the three months are gone whether you continue or not. The only real question is: from here, is this the best use of my next month?

It's hard, because stopping can feel like admitting the past effort was wasted. It wasn't. It taught you the thing you now know. That's what it bought.

Bad decisions vs bad luck

Not every bad outcome means you made a bad decision.

A bad decision is one that was wrong given what you knew, or could easily have checked, at the time. Leaving out the app store commission was a bad decision. The information was one search away.

Bad luck is when you decided sensibly and it still didn't work: a platform change, a competitor launch, timing.

The difference matters. You fix bad decisions by changing your process. Bad luck, you mostly accept, and try to make sure your next decisions give you more than one chance to get it right.

What to do

  1. Keep a short "expected vs happened" log for every experiment.
  2. Run the four-question review within a week of anything not working.
  3. Name the one wrong assumption, not a list of ten.
  4. Ask the sunk-cost question monthly: "If I were starting today, would I start this?"
  5. Share the lesson publicly, specifically. It helps others and keeps you honest.

Mistakes to avoid

Manufacturing drama. Most useful failures are small. Don't inflate them into a story.

Blaming luck for decisions. Be honest about what you could have checked.

Blaming yourself for luck. Some things just don't work out.

Reviewing without changing anything. A lesson you don't act on isn't learned yet.

Hiding failures. They're the most useful part of the journey for everyone else.

My current thinking

I expect to make more mistakes with HairOver, probably bigger ones, as the stakes grow. What I'm trying to build is a habit: notice fast, review honestly, change one thing, and keep going.

Key takeaway

Most failure is quiet: a wrong assumption or a skipped check. Review each failed experiment by comparing what you expected with what happened, name the wrong assumption, change one thing, and judge decisions by what you knew at the time, not by how they turned out.

Next: When a Project Becomes a Business.

Frequently asked questions

How do I learn from a failed experiment?

Compare what you expected with what happened, find the assumption that was wrong, and write down what you'll do differently. Keep it short and specific.

What is the sunk cost fallacy?

Continuing something because of what you've already put in, rather than because of what it's likely to return from here. Past effort is gone either way.

Is every bad outcome a mistake?

No. A good decision can still turn out badly because of luck. Judge the decision by what you knew and could reasonably have checked at the time.

Contact

Get in Touch

Want to call me? book a call and I'll respond in the available time slot. I will ignore all soliciting.