"I spoke to the team more, and unfortunately, we're a no-go for proceeding with the pilot. Best of luck!"

That’s what the email reads, and inside, you panic. You were ready for ups and downs (it’s a startup, after all), but the outright failure of your very first pilot seemed unthinkable. Do you not have product/market fit? Is the product not differentiated enough? Is your whole idea just worthless?

Sitting back, you suddenly feel like a failure. You think about your co-founders, your network, the people who encouraged you to start this business, and the many founder stories you’ve read over the years. It’s your first pilot, but it feels more like the first domino starting to fall toward your ultimate demise. 

Technical founders without go-to-market experience tend to be unfamiliar with this kind of failure. When their first pilot fails, they feel alone. When they search for articles to find solace or advice, they find endless success stories and impossible-to-replicate pivots. 

But I'm here to tell you, from my experience working with dozens of early stage technical startups like yours, that everything is fine. Tons of now successful startups failed some their early pilots and ended up figuring things out; the key is that they learned from those failures and used those lessons to make concrete changes to their plans. It's not a death sentence, it's part of the game.

To help you wrap your head around this counterintuitive idea, I'll run through a few common failures scenarios that I see and what you can learn from them.

Failure scenarios and what you can learn from them

To make this easier to follow, let's use a walkthrough example. Imagine you're an experienced backend engineer with a decade or two of experience working on observability tooling. You and a few longtime coworkers leave your current gig to start an observability company, focusing on lowering costs and improving insight yield on those massive piles of telemetry data.

There are about a million ways for you to fail. The name of the game is specificity – making sure that from every failure, you learn a specific, actionable lesson. If your company falls apart because of cofounder drama, a hostile board, or because your idea was dumb in the first place...then there's not much specific product or go-to-market information to learn from a failed pilot.

Let’s run through a few common scenarios I see when founders fail their early pilots. In each of these, there are concrete things you can change and improve based on the information that failure gives you. Failing is good!

Scenario 1: failure to tell a compelling story

In this scenario, you get strong initial interest because the problem you're working on (observability) is very real. But when you get into conversations with your prospects, and pilots progress, you keep hearing things like,

"Isn’t [your_product] just a tweaked [incumbent_product]?"

"How is this different from the 6 other observability vendors who keep advertising to me?"

They don't get how you're unique and differentiated relative to competitors.

In this case, you didn’t tell a compelling story, which (post forthcoming) is one of the hardest things to do as a founder coming from a technical background. Observability is a crowded market, and you're not going to stand out just talking about groups of features or a different architecture. This is a very useful lesson that you (a) would never have learned if you didn't fail, and (b) can use to improve in the future.

Scenario 2: specific product failure

In this scenario the pilot goes well initially, but your design partner starts running into product issues: missing features, half-baked screens, and consistent bugs. They understood the value of what you were doing, wanted it to work, but the product just wasn't there – or if it was, they didn't push through the cruft to find it.

This is a common failure mode. You most likely went to market too early, and don't have a basic viable product that can solve the problem. You can also go too far in the other direction, and put yourself in a cave working on a perfect product that nobody ends up wanting. But a failed pilot that teaches you that you need to spend time improving your product? That's valuable.

Scenario 3: failure to find the right design partner

In this scenario, which is extremely common among founders I work with, they find a design partner via an existing relationship (often a friend). And even though the pilot gets off to a good start, at some point it inevitably goes cold. It could be a product issue, changing priorities, or anything else; but the main point is, the design partner just wasn't that committed to the problem in the first place. By the way, this is exactly why you need to charge for your pilots.

The valuable lesson you learned here is how important it is to really get specific about who your design partners are. Just because someone is willing to work with you doesn't mean they're a good design partner: you need to be able to learn from your engagement. A smart person once said that the primary payment changing hands in a pilot is feedback, and you should spend your time finding people who will give you that detailed, relevant, useful feedback.

Failing some of your early pilots is fine: it doesn't mean you're doomed, and plenty of the companies that you look up to dealt with the same. But when you fail, make sure you can learn from it. And instead of dreading the "we won't be proceeding with the pilot" call, you'll actually, sort of, maybe welcome it.