My job at Amplify is working with technical founders on finding and closing their early customers. So naturally, I’ve seen just about everything there is to see when it comes to pilots and POCs – both the good and the bad. In my experience, smooth, effective pilots don’t happen by accident; they’re the result of extremely intentional planning, maintenance and discipline. This post is my attempt at writing down some of the common ways I see founders fail to accomplish these things in their pilots, aimed at helping you make your next few that much better.
P.S.: failing some of your early pilots isn’t always a bad thing.
1) Not all design partners are created equal
The first area I see founders flounder with pilots is picking the wrong design partner. A design partner is just a fancy term for an organization you’re working with on one of your first few pilots to get high quality feedback. And working with the wrong one can doom your pilot before it even starts.
The right design partner is going to exhibit a few important characteristics:
- They are meaningfully experiencing the problem you set out to solve.
- They have dedicated staff willing to spend time on fixing it.
- They are willing to pay for a solution that fixes it.
Essentially, a good design partner needs to resemble what a good lead will look like in a few years: an actual, legitimate potential customer. The currency of exchange in your early pilots (aside from actual money) is feedback: and if a partner doesn’t look like what your future customers will, their feedback won’t help you get where you want to be.
So how does this go wrong? I see a few failure modes.
The first is finding a design partner who is willing to work with you as a favor, usually because of a pre-existing relationship. This is common among engineer founders with friends at other companies who in theory are the target buyer for your product, but aren’t ever seriously going to use or buy it. Just because someone is willing to work with you doesn’t mean that you’ll get something out of the relationship.
The second is finding a design partner who is purely product curious. If they’re not getting rocked by the problem that you’re out there to solve, the relationship won’t last in the long run. Even if they think your product is interesting and want to try it, if they’re not motivated by solving a problem for their team, you won’t get the feedback you need, and it won’t convert later on.
Find the right design partner that’s really pained by the problem you’re out there to solve, and don’t just work with someone because they’re willing to work with you. If a big logo is knocking at your door, it takes incredible discipline to put them on the backburner because they aren’t actually a good design partner for you – but this is what you need to do.
2) Your pilot is a full time job
Picking a great design partner is just the beginning. I also see founders fail pilots because they don’t put enough time and effort into making sure they run smoothly.
Like the heading says, your pilot is your full time job – your design partners will rarely just “succeed” by putting your product in front of them. You need to be actively figuring out what’s blocking them, reading between the lines, and trying every day (within reason) to make them successful with the product. I encourage founders that I work with to communicate with their design partners as much as possible:
- Do whatever you can to get your design partner in a shared Slack channel with you
- Respond to anything they say as immediately as humanly possible
- Take every problem they raise seriously, no matter how minor
An area I specifically see technical founders fail here is focusing too much on product fixes and not enough on design partner hand holding. A classic example:
Design partner: we’re having trouble connecting our database to the app.
Founder: we’re shipping a new onboarding experience next week that should help!
Coming from an engineering background, sometimes everything can look like a product problem. But with design partners, a lot of times it’s not. They just need you to walk through implementation with them, fix something manually, and generally do things that aren’t scalable.
3) Your users are not always your buyers
You can pick the right design partner and pay close attention to making them successful in the product, but for a pilot to convert, you need people with decision making power to see the value in what you’re building. In 2023 StackOverflow research, nearly 35% of developers said they had “little to no influence” on technology decisions, and 41% said they only had some influence. A common mistake I see founders make with pilots is focusing too much on the end user, and not enough on the decision maker who does make that technology decision.
The line between end users and decision makers can be blurry, and they’re sometimes the same person. But the work you do on pilots needs to involve figuring out who can sign that contract at the end of the day, and bring them into the process. Your purchaser might be an engineering manager or a CTO; you need to be focusing on getting a first meeting with them – and then selling them on the value of your product – while you’re helping their team be successful in the product day to day.
No matter how much of my writing you read, you're still going to fail some of your early pilots, and that's OK. But hopefully, this post gives you a bit of a heads up for what's coming your way: pick the right design partners, give your pilots the time they need, and find your decision makers, and you'll be alright.