This was written as part of the rough draft for Deploy Empathy, a practical guide to interviewing customers.
Like it? Order the book:
One of the things we most want to know when creating a product is whether anyone will pay for it.
The thing is, like asking “What are your problems?”, asking what someone will pay is the literal inverse of the answer we want (more on that
), and it doesn’t yield very good results.
The good news, there are a bunch of ways to figure out willingness to pay.
There are plenty of ways to do this with live tests, and these tactics are extensively documented elsewhere: price tests, smoke tests
, the list goes on. These tools are worth being aware of and using when necessary.
These tools in particular are good with solving the “people are just being nice” problem that books like The Mom Test talk about:
You: Would you pay $10 for this?
Person: Sure, yeah.
You: Ok, pay me $10.
Person: Oh, uhhh….
Asking about a specific price can often cause awkwardness and lead to not very good data in return.
How you can ask people what they would pay…without asking them what they would pay.
At a high level, the way to ask someone what they’d pay without asking them what they’d pay is to ask what they’re currently paying.
They might be paying in terms of time, in terms of money, or, most likely, both.
What we also want to find out is the frequency of those time or money payments.
The idea is to map all of the problems we hear on a 2x2 grid of pain and frequency. Problems that are highly painful – lots of time, people, or steps involved – and high frequency are our prime fishing groups for product ideas.
Low frequency/high pain can be a good quadrant (like buying a house) as can high frequency/low pain (conventional “pain killers”). But you should avoid low pain/low frequency problems like a crowded indoor space without ventilation. (I used to say “like the plague,” but…)
In the same way that you apply this to the overall problem selection process, you also want to apply this to thinking about pricing and pulling information out about how much someone might be willing to pay.
Let’s work through some examples.
Person: [describing a tool they use for the part of the process you solve]
You: Can I ask much you pay for that?
You: And is that monthly, yearly, as you use it…
It gets a little more complicated when your product solves multiple steps of a process that people currently use multiple tools for (remember, this includes manual tools). But it’s worth dealing with this complication, because solving multiple steps can be a gold mine.
In that case, we would want to break down the individual steps and see how much time/money is spent on each one.
For example, let’s say you’re creating a no-code automation tool that helps university alumni departments figure out which cities to hold fundraising events in. (This is a fictional conversation.)
Person: …So first I get the online fundraising data for each donor in the last 5 years from our payment processor, and then I put it in Excel, then upload it to a tool to normalize the addresses and add the metropolitan statistical areas to find the nearest major city, and then I make a pivot table to see which cities we get the most money from, and then I pull in another spreadsheet with where we’ve held fundraising events the last year and how much we got from those events, and then I see which cities have the highest online donations but we haven’t held any events in, and then that’s the list I give to my manager for us to figure out where to hold the events.
You: Ok, wow, that sounds like a lot of work. I’d like to break it down a little. Can you tell me how long it takes you to get the data from the payment processor?
Person: Well, I have to pull the right data, and sometimes I have to change the export a little because it doesn’t save my settings so I end up having to do the download a couple of times, so maybe half an hour. I also have to use a physical two-factor key to log into it, and I admit sometimes I sorta lose it in my desk drawer. (laughs) That’s probably the most time consuming part.
You: Hah, okay, that makes sense. And the step to normalize the data and add the major cities, how long does that take?
Person: From the time I go to the website to when I can download the data, about 15 minutes.
You: Wow, okay, sounds like that part is fast. How much does that cost?
Person: Usually about $15 I think?
You: And is that monthly, or one-time, or…
Person: It’s just whenever I need it.
You: Ok, gotcha. Moving on to the part to create the pivot tables and bring in the data about the in-person fundraising events?
Person: Gosh I don’t know, two days, maybe three? I have to get that fundraising data from another system and it can be tricky sometimes. The formulas never seem to line up the same way, so I can kinda use my spreadsheet from last time but not really.
You: Oh, so it sounds like this analysis is something you’ve had to do multiple times?
Person: Yeah, we do it every year as part of our planning process.
You: Gotcha. So you said it can take a day or two to create that final list.
Person: Well, gosh, honestly maybe even a week sometimes! It’s just so finicky. I have to get the data from that other system, and I can’t get a spreadsheet, only a PDF printout, so I end up having to enter it all myself. And often times I need help using it, so I have to chase down someone in another department to help me. But you know, it’s worth it.
You: Just out of curiosity, if you can tell me, how much do these new city events bring in in any given year?
Person: About $2-3 million in a given year. They’re a big part of meeting our fundraising goals.
So from a pain and frequency perspective with an eye towards price, what did we learn here?
- The person uses a combination of manual tools, in-house software, Excel, and SaaS
- The only tool they currently pay for with money for this specific process is the SaaS (Geocodio in this case), which is $15
- This is a low-frequency, high-pain activity. It happens once a year but takes a week
- It’s a high-payoff, critical activity that nets the department an additional $2-3 million in fundraising revenue per year
If we add up the time spent:
- Gathering the initial data: 30 minutes
- Uploading the data: 15 minutes
- Combining the data and doing the analysis: a week
If we add up money spent:
- Gathering the initial data: free
- Uploading the data: $15
- Combining the data and doing the analysis: free
But it’s very expensive in terms of time, and looking at the payoff, there’s a reasonable chance they’d pay for something that could connect all of that software. If your no-code automation tool could allow them to set this up once and then get the analysis back within 30 minutes, we can probably charge a good price for that on an annual recurring billing cycle (since this is an annual task).
The questions to ask
The next time you want to figure out how much someone would pay for something, here are the questions to ask.
Note that when you’re asking about what people pay for things, you want to be extra polite. Say “Can I ask…” rather than “What do…”
- Can I ask what you’re currently paying for that [tool] you mentioned
- And can I ask how often you pay that?
- Could you tell me how long [particular step] takes you?
- Can I ask how often you have to do that?
When you ask these questions, keep the pain and frequency matrix in mind. You might find it helpful to literally map all of the different problems you’ve heard onto that matrix to help you choose which problems to solve.
I suggest keeping an eye out for the high pain/high frequency problems in particular.
Once you’ve decided on a problem, these questions will tell you what kind of billing model might work (usage-based vs subscription vs some combination).
Determining the final price will involve more work on your end (it’s one of the most complicated parts of having a business in my opinion), but finding those high pain/high frequency problems and nailing the billing model to match customer’s mental model of the activity is the first step.