Pilots, POCs, and Trials
Mistaken causality and never-ending pilots
Rob here - B2B founder obsessed with sales and product-market fit. There’s a companion podcast(Spotify, YouTube). Also:
My book, The Power of PULL, is coming out July 7! If you pre-order it, you get COOL STUFF (e.g., my sales call analysis Claude skill + private AMAs) - learn more + get access HERE.
I help startups make their products easy to sell. Startups are reserving me for Q3, so if you feel like your product is not easy to sell and that needs to change, learn more & grab time here.
On Tuesday, June 9, I am doing a public sales call teardown where I analyze a startup’s actual recorded sales call. Harold, co-founder of Sliq, has volunteered as tribute. This is the first (and possibly only) time I’ll do a public one. Registration is free, but there are limited slots.
Question from a startup: We are getting into pilots, and they are going well - users are getting value out of the product and usage is going up - but we’re struggling to align on success criteria with our champions, and deals are kinda dragging along in the pilot stage. What do we do?
Answer from me: It seems like you’re thinking about pilots backwards.
The same is true of trials and proofs-of-concept (POCs), whether free or paid: These aren’t things that cause a purchase, they are things that can prevent a purchase. When you treat pilots as if they’ll cause a purchase, you’re going to cause yourself a lot of pain.
Let’s go down a causality rabbithole, then return to pilots/POCs/trials.
Causality’s arrows
Two things cause someone to buy your product:
They have PULL: They are prioritizing X right now, but can’t do it with their existing options for Y reason.
You offer something that unblocks them: It enables them to overcome Y to get X done.
If these causes are absent, it would be weird if they bought from you.
If these causes are present, there are many things that can PREVENT them from buying from you. For example:
You try to charge a trillion dollars for your product
You don’t pass a security review
It takes too much effort to implement your product
Your sales process convinces them not to buy (for example: two-hour walkthrough of every feature and the theory behind AI agents… or following a traditional sales script that feels like a colonoscopy)
You just make them feel weird (for example: signing all your emails off with “Love, Rob”… especially if your name’s not Rob)
So: Only two things can cause a purchase, but many things can prevent a purchase. This is true beyond purchases, of course: Many things will cause a startup to fail, but only one thing can cause a startup to succeed (finding PULL!) Beyond startups, this distinction also applies to job satisfaction, health, happiness, relationships - each has a different set of things that cause X and things that prevent X.
Now, the hard part: Fixing the things that prevent purchases =/= doing the things that cause purchases.1 Having a clean SOC 2 compliance report won’t cause them to buy from you, though not having it might prevent them from buying. Same with a good demo, a good sales process, or customer reference calls! We all learn this the hard way when we spend a ton of time making our product easy to adopt (e.g., adding a free tier) and realize that no matter how easy it is to adopt, nobody wants to adopt it.
Because of this, we need to approach “things that cause purchases” and “things that prevent purchases” differently:
You should design your business around “things that cause purchases” - from your ICP to sales meeting structure to your product description to your actual product.
“Things that prevent purchases” should be designed out when possible, and minimized and expedited otherwise.
So: Back to Pilots, POCs, and trials. These things are NOT the causes of purchases (remember, there are two: “PULL” and “fit”), they are things that can prevent a purchase - and should be avoided if possible, and if not, crushed like a checklist item.
Most of the time, pilots are unnecessary.
Why are we even doing a pilot? Usually: Because we offered it! We brought it up, the customer didn’t. Why do we do this? It is actively introducing a thing that can only prevent a purchase!
Rule #1: If the potential customer doesn’t propose a pilot, don’t propose one.
Usually, we can go straight for a big-kid sale - whether that’s a smaller initial contract or a good ol’ annual deal.
When necessary, pilots should be treated as “things that can prevent a purchase.”
Some people actually need pilots, of course. But many times they are asking for a pilot just as a way to not say “no” to an eager-beaver founder, or because they’re skeptical and don’t believe the product will actually work (if/when it does work, then they’ll decide if they want to buy it). Some of these pilots might convert. But it wouldn’t be weird if they didn’t convert, and you’ll find they tend to eat up a ton of your time and drag on forever while your investors ask increasingly uncomfortable questions about why they haven’t converted yet.
Rule #2: If the potential customer asks for a pilot, don’t just say yes.
Before committing to a pilot, you have to (1) make sure they believe there’s PULL + fit, and (2) frame the pilot so that it’s more like a security review than an audition for American Idol.
When they ask for a pilot, say something like this: “Happy to scope one out! We tend to do pilots once you are convinced that this is a fit to bring into the org and all other boxes are checked - what else do you need to assess to confirm we’re a fit?” Then: “What else needs to happen in the org to get to the point where a pilot makes sense?”
This approach will reveal deals where they’re not sold, not serious, where they would have wasted your time in a pilot - and it will give you a chance to either reset these deals or kill them.
Once you’re past this step, it’s time to frame the pilot.2
The frame is not, “What do you need to see in order to conclude that the pilot is a success and you want to proceed with the purchase?” This question frames the pilot as an audition that they are judging rather than just another checkbox after they’ve made the decision to buy that everyone expects to clear, and only won’t clear if something goes horribly wrong. Which gives them the ability to defer their purchasing decision and delay other purchasing actions (e.g., going through contract review or whatever), waiting to see what happens during the pilot. By doing this, you are making the pilot a bigger thing than it needs to be - not something you want to do with a “thing that can prevent purchases.” Hence: longer pilots, slower purchases, and lower conversion rates.
So we need to frame the pilot closer to “What are the conditions under which you won’t buy as a result of the pilot?” And then: “Assuming that doesn’t happen, is there anything else that needs to happen before you purchase?” This leads to a more tightly scoped pilot, with less chance to go off the rails or drag on forever.
And that’s what I think about pilots. And causality.
Love,
Rob
I do not yet have a better way to describe “things that cause” vs. “things that prevent”. There is a much cooler way to describe this (a la “fragile vs. antifragile”). Please send ideas.
In time, you’ll have templates for “how companies just like you have approached their pilots.”
This is super helpful, thank you! Would motivation factors vs hygiene factors from Herzberg’s two-factor theory of job satisfaction fit for “things that cause” vs “things that prevent”?