How to Sell if Your User is not the Buyer
Example: Dev = user; CTO = buyer
I recently wrote about how your ideal customer is one who values your product the most”. And then quickly, in one of my private communities, I had this question pop up:
But how you would talk to your ideal customer if they are not the ones who try the product?
In my case -- I totally agree. CTOs / Director of Engineering are probably the ones who make decisions. But it is developers who try the product first.
In the article you talk about messaging. I get it. But how practically you can reach out to decision makers?
Let’s dissect this question here and get to the root of this question here, right now.
This is the "the user is not the buyer" problem.
Sure, it's a tough one, and I don't think there's a one-size-fits-all solution.
Here’s the key… it depends on one thing:
→ Who actually has the power?
(and hint, it’s not always the person with the credit card)
Let me explain…
Scenario 1 - Smaller org charts
Your product is used and bought by smaller companies, they have CTOs/directors, but it's pretty flat, and they are in build mode. These are likely early stage or smaller companies still trying to figure out their market fit or value proposition.
The user (developer) might have the power. Here’s why…
The CTO's incentive is to reduce time to market/iterate. The faster they are to market and iterate, the faster they learn, the faster they find PMF, the more likely everyone keeps their jobs (and maybe they get a big payout win 3-10 years from now, or at least that's the promise from the CEO).
The user/dev has the power because of the time constraint.
They're likely to come to the organization with knowledge - it's why they were hired. So, their suggestion on what to bring to the table in terms of dev tooling will be massively important.
They might even setup a free account to use before anyone notices, "just to get things done".
Eventually they have to level up to a paid tier and voila, the company has just been trojan-horsed.
Scenario 2 - Larger org charts
The CTO/directors/leadership are the ones who have the power because there’s different constraints other than time. In this case, let’s just say security is the primary constraint.
No user/dev is going to be allowed to install software themselves. This comes from top-down.
Thus, the sales cycle is going to be long since you have to sell the value differently and there’s likely a vetting and due diligence type of process they have to go through to choose your product over another.
The users/devs don't have much of a choice because the primary value/risk isn't UI/UX/DX or whatever the user/dev cares about. It's security + outcome/output.
Now here’s the thing… The person with the credit card is who we typically would call the "decision maker" (and in the original question, it was called the “ideal customer” even).
But the reality is, they aren't always the one with the power. It depends on the constraints they're under.
It's also not “who tries the product first”, as the original question states.
It's “who has the leverage”?
Who has the power, the constraints, and/or the incentive to push it through the most?
Subsequently, this is who values it the most.
IMPORTANT POINT: I’m getting picky about defining “value” here. It needs to be actionable - something within the bounds of reality. Someone who says it’s worth N to them, but doesn’t have the means to actually trade N for it, doesn’t really matter at the end of the day.
Let’s get back to it…
If your user/dev values it more than the holder of the budget, then you only have one thing to do….
The CTO will never write the check for the value the user/dev deems it’s worth.
That said, as a dev, I've paid for tools out of my own pocket that mean enough to me to do so if it's valuable enough. And in that case, the incentive and value isn't because the company will win... it's because I'm going to look great when I make the company win.
Different incentives.
Different payoffs.
But, with that in mind, let's get more specific...
Let’s get more specific…
I posed this question back to the OP: “What's the typical path for adoption (that works best for you!)?”
Perhaps for you, it goes something like this:
User/dev registers
User/dev runs free trial on a local environment
User/dev gets a the value right before the do a pull request, so they can see the before and after scenarios (highlighting any issues)
User/dev sees value (Note: here’s how to master the “aha moment”). They see it will save them time with QA’ing their own changes, perhaps it could even be automated?
User/dev tries to convince leadership it's necessary to get it paid for
Leadership tests/sees process, checks budget, decides yes/no
Leadership gives approval for purchase
User/dev/leadership purchases
User/dev continues to use it and propagates among other user/devs in the co.
In this case (change based on the assumption of the scenarios above, small vs big orgs, user flow, etc), here's some questions to figure out:
What's the real incentive behind why the dev suggests the tool? Does the dev want it because it helps them be awesome / reduces the pain of doing their job, or because it'll help the company goals?
What's the real incentive behind why the leadership buys it? Because they'll see it'll take less time for the dev to do their job, they'll be better at it, thus getting to the goals of the company?
If those things are true, I would do these 2 things….
Give the user/dev the tools they need to convince their leadership that it's a slam dunk (for their incentives). Translate the value from the user/dev’s terms into the leadership’s terms.
Note: It's best if this isn't explicitly declared to them like "here's how you convince your leadership this is a good idea" but more like "here's a report showing how much time you were going to spend doing it in the old way vs how much time you actually spent doing it this way". Also, make these actual, real numbers as much as possible or the dev won't use the report because they’ll know the numbers are inaccurate.
I'd also do some customer interviews here with the devs to figure out how those conversations usually go with leadership. What do they need to make that conversation go faster/easier? What stops them from buying?
Find the friction, smooth it out.
The meta point here is that you're not going to talk to the credit card holder; the user/dev is going to do that for you.
Give them the best possible chance at convincing the leadership. Make them look awesome for even bothering the leadership with a choice like this. Make it obviously awesome for them to decide “yes”. These users/devs are your sales people. Treat them as such in the sense that if they win (product does what the user hopes and dreams it will, getting them to the promised land), you win ($), and then they win again (look good, systemically removing friction in their job/process, etc). Not to mention, the leadership wins and the company wins.
Now go, and proselytize those devs. ;)
If you’re a founder who wants to get unstuck, reduce churn, get through that revenue plateau, generate more leads, and more… Get in touch today
🧢 Hat tip to Yuriy Gerasimov from Diffy (visual regression for Wordpress and Drupal) for the being the muse this week! Thanks for letting me write about our chat, Yuriy!