The Mom Test, ch 3: Asking important questions

This chapter expands on an idea that was mentioned in an earlier chapter: You should ask questions that will help you validate or falsify the key hypotheses your product depends on.

He breaks these hypotheses into two categories:

Market/customer hypotheses: Do people actually want your product, and can they afford to pay for it?
Product hypotheses: Can you actually build the product?

(I'm reminded of Brian Balfour's very interesting market/product/channel/model framework, which could be an even more useful breakdown.)

It's important to be right about both types of hypotheses. Sometimes you need to do research in order to validate them both; other times one of them is obvious.

For example, Fitzpatrick points out that you don't need to do any market validation for whether people will pay you to get clicks on their ads. They absolutely will. The hard thing is being able to develop a product (or content) that will get people to look at and click on those ads. You should spend your time confirming that you actually can do that, rather than talking to potential advertising customers.

And if your product is a simple web application with no fancy technology, and you can build web applications, then you can probably focus all your validation energy on talking to customers, because you're already confident about the product side.

Even with a product that isn't very technically challenging to build, some customer segments won't need much validation. If you're building an ecommerce platform, you probably don't need to ask existing merchants if they'd be interested in being on the platform. If you can deliver them customers, they'll join your platform. You need to focus your efforts on the customers, since it's an open question whether you can deliver them, given the huge number of existing ecommerce options. (The equation flips if you promise customers they can buy everything at half price --- at that point, you can almost certainly deliver customers, and the question becomes whether you can convince merchants to sell at half price.)

As a way of working through these ideas in more detail, I'll use Fitzpatrick's insights to think about how to improve the validation of Get In Touch. I touched on this briefly in my Chapter 1 post, but I'll go deeper here.

I'm confident that I can build the product, and if people actually want it, I'm also confident I can figure out how to market it effectively.

The biggest questions I have are about whether people actually care enough about the problem I'm trying to solve. Here are a few different angles of attack on the hypothesis that people do care enough to spend money and time using a new app.

If, three years from now, the app had loads of paying users, what would need to be true that I could discover through user interviews?

People would need to have a burning problem that I can actually solve. Related questions (copied from The Mom Test): What are your big problems right now? What are your big goals and focuses right now?
Those questions are also good if I'm talking to someone who either doesn't seem to care much about the problem space, but seems open to continuing to chat.
Questions a bit more focused on my problem space (paraphrased slightly from chapter 3): How seriously do you take keeping up with friends and family? How much time do you spend on it each week? Do you have any (related) major aspirations? Which tools and services do you use for it?

If it turns out people don't care enough about this problem, what evidence could reveal that?

People *say *they're upset about their ability to keep up with their friends, but haven't taken easy actions to try to solve those problems. Related questions: Have you tried looking for solutions? Have you tried any of them?

What are other failure points of Get In Touch?

At least some people need to be willing to pay for a product like this. If people have a real pain point, but object to paying for an app when Facebook/Gmail/etc. are free, then Get In Touch will fail, even if it provides more value than it costs. Question: When was the last time you paid for a service related to socializing, relationships, or dating?

Fitzpatrick writes:

Pre-plan the 3 most important things you want to learn from any given type of person (e.g. customers, investors, industry experts, key hires, etc). Update the list as your questions change.

Here's what I think I'd want to know from these types of people:

Customers:

Do they care at all? Figure out if they have any pain points or aspirations when it comes to relationships and staying in touch.
What have you tried already? Get concrete about what problems they care enough about to try solving.
When did you pay for a service related to relationships? Assess willingness to pay, and identify which specific problems are promising to pursue.

An industry expert, e.g. someone who has previously tried building a product like this:

What are the problems people seemed to care the most about?
Which problems do people complain about, but don't actually care very much about?
What's the most interesting user problem you'd have loved to dig into deeper if you had had the time and resources?

If you're an extremely talented engineer/scientist/etc., then you can actually build things few other people can build, and maybe you'll be most successful working on hard technical problems (the product side of the equation Fitzpatrick talks about).

But if you're merely competent (I am a competent-but-not-brilliant developer, for example), then perhaps a more promising path is doing good user research to discover market opportunities.

You want to find tractable problems that people care about a lot. There are lots of them, but the central premise of The Mom Test is that it's easy to hear the wrong thing when you ask people questions. Fitzpatrick gives an example (slightly abbreviated):

You: "How often do you go to the gym?"
Them: "Not really ever."
You: "What would you say is your biggest problem with going to the gym?" This is where the conversation goes horribly wrong. Instead of figuring out whether staying fit is actually a real problem, we're prematurely zooming in on it. Any response we get is going to be dangerously misleading.

So one way to think about this is that when you aren't confident about what someone cares about, you'll probably want to start broad, to figure out if they care at all about the problem space you're working on. If they are, then you can drill down based on their responses, always making sure you're not asking them detailed questions about things they don't actually care about. When you drill down far enough, you'll find a problem small and concrete enough that you can solve it.

One final thought. What if I get user feedback that indicates there's some interest in something like Get In Touch? How do I decide if it's enough to warrant spending time on?

The very excellent book Decisive by the Heath brothers recommends deciding whether or not to do something without comparing it to some relevant alternatives. In my case, what else would I do with my time if I didn't spend time developing Get In Touch? I'd probably focus on one of my other ideas. So it could be worthwhile for me to spend some time exploring one or more of those ideas at the same time I'm exploring Get In Touch. If I get pretty good evidence people are interested in Get In Touch, but really strong evidence they're interested in Project X, that could be a good sign I should pursue Project X instead. On the other hand, if I immediately get strong, positive evidence about Get In Touch, I probably don't need to keep multi-tracking --- I'll be better off focusing my efforts.