Sean Murphy explains to a client why startups should just sell the results to reduce a prospect’s perception of risk in a new tool.
Just Sell the Results
This is a a new kind of blog post for me. This is an audio from a recent conversation with a prospect where I have removed a few key details to preserve their anonymity and then edited and amended the transcript to make the key points from the dialog clear as a stand alone article.
Direct link to download: https://traffic.libsyn.com/secure/skmurphy/Pay_for_Results.mp3
Successful startups don’t ask early customers to pay until they have delivered the result they promised. This type of offer pulls all of the risks to the startup side of the table. Now they can have a conversation about the value of what you are promising separate from a discussion about the probability that you can deliver it–or that the customer will be able to accomplish a task using your software. So that affects their willingness to give you a chance to work with them.
Part of their assessment of the risk of working with you depends on how much behavior change your product will inject into the customer organization. Their calculation of the total cost of your product includes the amount of behavior and process change they will need to make to get the full benefits you promise them.
A startup only gets paid by their early customers after they have delivered the results that they promised. If you cannot come to terms with this, you can never close early deals.
Your early offers to a business have to acknowledge this, at least for your first, second, and third customers–and often your fourth or fifth customer. If more than one person at the customer’s firm has to change how they do a task or do their job–even if you believe that it’s a small change–then you have to absorb the risk. Sometimes you can offer technical proof in a demo that uses customer data or solves a problem that the customer agrees is equivalent to a problem that they need solved. And that demo proves the value. But for early customers–when you don’t have real references and case studies you can share with them–that’s rarely enough.
We often work with startups who are making offers to firms they hope will become early adopters of their product. But they don’t provide proof of value–because they think it’s obvious–and they don’t make an offer that absorbs the risk until the customer sees value. So they come to us and say, “We don’t understand why these prospects didn’t buy. It was clear to us that we offered a huge benefit.”
I start by asking, “Please take me through it. What was the guaranteed payoff? What result did you guarantee the prospect?”
There’s often a short silence followed by, “Well, when you phrase it that way, it’s kind of hard to figure out. We would need to know this or that or even all of these things. And we could not quite pin down some of those factors.”
I suggest, “if you cannot figure out what the minimum improvement is, how does the person who’s paying for this have any prayer of figuring it out in advance? If you are not willing to wait to get paid, why should they take the risk? You have to pull all of the risks to your side of the table.”
Established firms who are entering new markets or offering a new product that requires a substantial change in process or workflow need to follow this rule as well. They sometimes mask what they are doing by calling it “beta,” which is Greek for “doesn’t quite work yet, you only have to pay when it does.” But they have to recognize the same fundamental truth that if a customer views a product as risky or unproven will only pay once they have seen a real result based on their situation or a situation that is substantially the same.
There is a second factor that’s punchline to an old IT joke.
“Q: Why was God able to build the world in six days? ”
A: He did not have an installed base.”
Let’s say that you can demonstrate that your software can turn base metal into gold–in certain limited situations that match a few prospects’ needs. One of those prospects may complain to their incumbent vendor, “I saw a proof of concept today where this startup showed that they could turn scrap iron into platinum; why can’t at least use your software to turn lead into gold? This startup is just three guys in a garage in Tacoma. I am paying you guys a million dollars a year: when will you ship that capability?”
The incumbent may say, “Of course, that’s on our roadmap for early next year. If you can wait six months, you’ll have it.” At which point the startup may win the deal if they can start converting the prospects lead into later in a few weeks, or they may win it in six months if the incumbent fails to deliver and the prospect is no longer willing to give them the benefit of the doubt.
A more honest incumbent may say, “As much as we love you, we cannot solve just your problems. We sell products, not custom solutions. We need to solve a problem that a hundred of our customers have. We don’t think the limitations you can live with will be acceptable to enough of our customers to make this a viable product.” Of course, a large firm’s view of revenue required to make a”viable product” may be one or two orders of magnitude more than what a startup can live with–at least in an early market.
One way that you can sell a result, and sell it faster than an incumbent can respond, is to structure it as a service–or a technology-enabled service. This approach shields a prospect from the risks, complexities, and usability issues that a new product often presents. They only need to pay for the result once they see it.
Related Blog Posts
- Better Results Outsell “Cheaper” When Stakes are High
- Quick Thoughts on Selling For Software Engineers
- Sell Results Not Method: If they don’t want the result your software delivers you have a problem. If they do, focus on the outcome much more than how you do it and make sure they want the result.
- William Pietri: “People won’t pay you to solve problems that you know they have, only the problems that they know they have.”
- Five Things to Remember When Selling A New Product
Image Credit: “Value / Cost Dashboard” © Olivier26 Licensed from 123RF