The following is an excerpt from the book: Running Lean.
In my post Don’t Ask Customers What They’ll Pay. Tell Them I covered how to uncover initial pricing for your product by first spending time to understand your customer, their problems, and their existing alternatives. In this post, I’ll talk about how you use that information to test pricing.
When to Test Pricing
The general feeling around your first release (or minimum viable product) is that it’s embarrassingly minimal so it’s more common to want to discount or give it away in the interest of learning from customers. The mindset most of us have is one of “lowering sign-up friction”. We want to make it as easy as possible for the customer to say yes and agree to take a chance on our product – hoping that the value we deliver over time will earn us the privilege of their business.
Not only does this approach delay validation because it’s too easy to say yes, but a lack of strong customer “commitment” can also be detrimental to optimal learning. Your job is finding early adopters who are at least as passionate about the problems you’re addressing as you are. Lowering sign-up friction makes sense once you’ve got a customer lifecycle that is working. Until then, the goal is maximizing learning, not efficiency.
I believe if you intend to charge for your product, you should start testing pricing even before you build your MVP. Remember from the last post, that pricing is part of the product.
Don’t Lower Signup-Friction. Raise it.
I know this may run counter to your intuition. It did with mine. Here’s a social experiment I ran recently during one of my customer interviews (and have repeated several times since then) that changed my perspective (I’ve left out the names of the product and customer):
Me: So lets talk about pricing…
Customer: Do we need to negotiate pricing right away?
Me: This is not really a negotiation. While we have been using this product internally ourselves, we need to justify whether it’s worth productizing externally.
Customer: Oh ok.
Me: So what would you pay for this product?
Customer: I don’t know – probably something in the $15-20/mo range.
Me: Well, that’s not the pricing we had in mind. We want to start with a $100/mo plan. I can understand why you don’t want to pay a lot (because you are pre-revenue) and it’s possible that we’ll offer a freemium or starter plan in the future.
Right now, we are specifically looking for 10 [define early adopters] who clearly have a need for [state top problem]. We will work closely with these 10 companies to validate [state unique value proposition] within 30-60 days or give them their money back.
You mentioned that you’ve spent several developer hours a month building a homegrown system and still haven’t been happy with the results. This product is our third attempt. Given your current homegrown system, can you build your own homegrown system, which is a non-core function, spending less than 2 developer hours a month ($100/mo is less than 2 developer hours a month)?
Customer: Yes, that makes a lot of sense. We want to be on the shortlist. When you put it that way, I can easily justify paying $1200/yr. It’s just a fraction of what we pay our developers. How do we get on the list?
Me: We’re still finalizing some product details and I’ll get back with you once we’re ready.
Customer: We seriously want to part of the initial customer list. I’ll run upstairs and get my checkbook if you want me to…
So what happened there? Why did the customer agree to paying 5x their original amount?
There were a number of principles in play that I’ll summarize:
Prizing: Oren Klaff discusses this framing technique in his book: Pitch Anything. He describes how in most pitches, the presenter plays the role of a jester entertaining in a royal courtyard (of customers). Rather than trying to impress, position yourself to be the prize.
Scarcity: The “10 customer” statement was not a fake ploy. The first objective with your MVP is to learn. I’d much rather have 10 “all-in” early adopters I can give my full attention than 100 “on-the-fence” users any day.
Anchoring: Last time, I illustrated the relativity principle in action using Steve Jobs’ iPad keynote. Even though pricing against “existing alternatives” might seem logical, the customer might not automatically make the reference themselves. If Steve Jobs saw the point to explicitly anchor pricing, none of us have an excuse.
Confidence: Most people are reluctant to charge for their MVP because they feel it’s too “minimal” and might even be embarrassed by it. I don’t subscribe to this way of thinking. The reason I painstakingly test problems and reduce scope is to build the “simplest” product that solves a real customer problem. I have enough confidence in our ability to build and am willing to put my money where my mouth is.
The Solution Interview as AIDA
AIDA is an marketing acronym for Attention, Interest, Desire, and Action. I find it a useful framework for structuring these type of solution interviews.
Attention: Get the customer’s attention with your unique value proposition – derived from the number one problem you uncovered during earlier Problem Interviews.
Interest: Use the demo to show how you will deliver your UVP and generate interest.
Desire: Then take it up a notch. When you lower sign-up friction, you make it too easy for the customer to say yes, but you are not necessarily setting yourself up to learn effectively. You need to instead secure strong customer commitments by triggering on desire. The pricing conversation above generated desire (albeit intentionally) through scarcity and prizing.
Action: Get a verbal, written, or pre-payment commitment that is appropriate. for the product above, we started taking pre-payments for the MVP and utilized a concierge MVP model to find ways to deliver continual value to our early adopters while we incrementally rolled out the MVP.
How is this Different from a Pitch?
While this might look a lot like a pitch, the framing is still around learning. A pitch tends to be an all or nothing proposition. Here, you lead with a clear hypothesis at each stage and measure the customer’s reaction. If you fail to illicit the expected behavior at each stage, it’s your cue to stop and probe deeper for reasons. For instance, you might have your positioning wrong or be talking to a different customer segment.
P.S: Watch the O’Reilly webcast I gave on the same topic here (with slides):