How first-time founders fail

Here are some “trust me bro” truth bombs for you:¹

1. First-time founders are more likely to fail than those with previous experience.
2. Founders who previously failed are only marginally more successful.
3. Previously successful founders are way more likely to succeed than either.

Therefore, if you want to learn how first-time founders fail and avoid their mistakes, it's best to ask the ones who found success after their first startup(s) failed.

So, I did. Here's what they said.

This article was first published in our newsletter, Product for Engineers. It's all about helping engineers and founders build better products by learning product skills. Subscribe here.

Paul Copplestone

Supabase is lean, product-led, and grows by word-of-mouth. It's the polar opposite of ServisHero, Paul Copplestone's first startup, a TaskRabbit-style marketplace for local services in South East Asia.

ServisHero generated early buzz, and blitzscaled its way to double-digit monthly growth by expanding into new countries.

But Paul soon saw signs it wasn't working. Retention was poor. Growth was coming from marketing spend rather than word-of-mouth. Worst of all, the company was overhiring and competing with big tech on salaries.

ServisHero is still going, but it never reached the heights Paul hoped.

What Paul learned

Paul and his co-founder thought they were following a well-established playbook, but it led to the following mistakes:

1. Premature scaling: Lavish spending and expansion are worth nothing without product-market fit. Paul took a more community-centric, bottoms-up approach with Supabase because "it's better to have 100 true fans than one million drive-by users". Scaling too soon inevitably leads to...

2. Cheating your metrics: A classic. Don't be seduced by vanity metrics, like app downloads or signups, that make you feel good. Instead, "find a metric that truly indicates PMF." For Supabase, it's “monthly active databases,” which indicates both growth and real usage.

3. Hiring people you don't need: Paul advocates only hiring someone when you have a problem that’s “big enough for a full-time hire." Not a theoretical problem or an opportunity, a burning problem you can only solve by hiring someone.

"We now have around 80 people at Supabase, so I usually say that we have had 80 problems worth solving. This forces you to do less, stay focused, and maintain velocity."

Taylor Wakefield

Before Taylor Wakefield found success with Mailgun and Teleport, he co-founded Profista, a web app and consulting company that helped business leaders track financial results and "operational drivers."

"We essentially sold BI proof of concepts to large companies like EMC and Cisco to help manage their business. We would use Tableau graphs embedded in wireframes to demonstrate the idea to them."

Profista generated hundreds of thousands in orders this way and worked closely with clients to build the workflows. Users would email spreadsheets to an endpoint, which would then automagically populate graphs in the app.

Early feedback was glowing and the product "blew the customers away," says Taylor. There was just one teeny, tiny problem. No one used it.

"We didn't do a good job of working with the individuals who were going to be actually using the product on a day-to-day basis. It was pretty clear that it didn't make their lives easier, and they were only using it because their boss told them to. In the end, the actual users revolted, and the product didn't give the managers enough value for them to keep making their employees use it."

What Taylor learned

Initial feedback and orders convinced Taylor he was onto something, but he and his team made a few classic first-time mistakes:

1. Working on a problem they didn't know well: While Taylor knew there was a problem to solve, it wasn’t one he’d personally encountered or tried to solve. In contrast, when Taylor and Ev Kontsevoy, who had worked on Profista, founded Mailgun, "Ev was solving his own problem that he understood deeply."

2. Talking to the wrong people: By working with managers as design partners, rather than the people who would use the app, Profista created a solution that didn't survive contact with reality.

3. Building a solution that isn't 10x better: Points one and two inevitably lead here, as Taylor explains:

"We were very descriptive about the solution we were building and, in the end, it wasn't appreciably better than the email and spreadsheets based workflow they were using. People don't like change, and they won't adopt a new way of doing things unless it is massively better."

Subscribe to our newsletter

Product for Engineers

Helping you become a better engineer and build successful products. Read by 25,000+ founders and engineers.

Subscribe

We'll share your email with Substack

More first-time founder mistakes

1) The wrong co-founder(s) 🤗

"Companies are mostly about people" and that starts with your co-founders. Marty Kausus, co-founder and CEO at Pylon, quit his second startup the moment he found "the right co-founders" to start a more successful venture.

They got together and "pivoted weekly" for two months before landing on Pylon, a Zendesk and Intercom alternative for managing customer operations via Slack.

A year and a half later, Pylon already has strong product-market fit.

"My biggest takeaway on co-founders is to make sure they have similar hustle, spirit, and desired lifestyle. For Pylon, we wanted to live together and live and breathe the company. We joke that we don't have 'work-life balance,' we have 'work-life integration' and that's ideal for us, while most people would find that miserable."

2) Just shipping what users say they want 👍

Talking to customers is important, but it can go too far. This was a lesson James Evans, now co-founder and CEO at CommandBar, learned in his first startup:

"Our only real advantage relative to competitors was speed and eagerness, so we shipped a ton of features. Users would ask for something on Intercom in the morning and receive it that evening. Just crazy customer service."

It felt good, but "created a ton of product debt" and led them to ship "things that we didn't really want users to use," James says. In the end, he argues, it made the product "kind of Franksteiney-freakish."

With CommandBar, James was determined to build a more opinionated product. The team only build new features for customers when they can say, with confidence "this feature will help your users and not annoy them."

3) Bad founder-market fit

Per Borgen spent three years trying to make his first startup, Propell (2012 to 2015), work. Despite reaching over a million downloads for iPad children's books idea, the venture almost broke his spirit: "I was convinced I'd never have the energy to do a startup again."

In his mind, they made two critical errors:

1. The market of people willing to pay was too small.
2. They didn't have a "strong passion" for the problem they were trying to solve.

Per and his co-founder rectified both mistakes with Scrimba, an online coding school they founded in 2016.

This time they were building for a large, highly-motivated target market (people who want to become engineers) and Per, having learned to code via online bootcamps, had strong opinions on how to do them well.

Today, Scrimba is profitable with a team of 15 and has over 10,000 customers.

He's got one final piece of advice for first-time founders:

"The worst period is before you pull the plug, not after. I felt much better after I stopped trying to save the startup, and started doing something else. The lump in my stomach completely went away."

Good reads for product engineers 📖

Avoid blundering: 80% of a winning strategy – Jason Cohen: Jason’s thesis is simple: successful founders are often the ones that avoid unforced errors, such as not seeking out the truth, and selling to Enterprise too early.

How Stripe validates ideas for new products – Daniel Kyne: Daniel shares a great summary of Stripe’s method of Customer Problem Stack Ranking (CPSR), which ranks your problem against other problems your potential customers are trying to solve.

Positive friction – Ali Abouelatta: Sometimes it pays to add more steps to your onboarding process, what Ali calls positive friction: “They [Rise] realized the more screens they added to the onboarding flow, the more personalized and advanced their product appeared to the end users.”

The engineer/manager pendulum – Mipsytipsy: ”The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management.”

Words by Andy Vandervell, who will accept almond croissants as payment.

Subscribe to our newsletter

Product for Engineers

Helping you become a better engineer and build successful products. Read by 25,000+ founders and engineers.

Subscribe

We'll share your email with Substack