#cookebooks: The Mom Test, by Rob Fitzpatrick - to build a product, rely on facts, not opinions (because everyone lies to you)

Recommended by: Jake Jones and Gabriel Silva

Score

4.1 out of 5

What's the premise?

Product builders waste time talking at customers, pitching pre-conceived ideas (e.g. "I have an idea for a great recipe app - would you buy it?"), and looking for compliments (which are then falsely registered as a buy decision/ positive feedback).

To build a product that people want: ask about a specific problem the customer has faced, and how they solved it (instead of your idea). Specific information about the past is more valuable in addressing need than generalisations about the future.

What did I learn from it that I can apply now?

• The customer owns the problem. You own the solution. (This is absolutely foundational in product building - for more on why this split of accountability is important, see here.)
• Some problems reported by customers are, in fact, not problems. If the user didn't try to solve the problem before (or doesn't see a personal cost in their workaround), they likely won't use your solution to it.
• Avoid asking customers questions like "Have you ever...?", "Would you ever ...?", "Could you possibly ...?". These questions bias your customer. Generalities about the future are useless to product building - you need actual data about actual present pain.
• In the scoping/ building phase, avoid customer compliments at all costs - a compliment is a lie. "Love bad news" - a firm yes/ no, gathered through tough and direct questioning, is 10x useful than a generic "wow" or a future promise to use a product (which is just a kind way for a customer to say they don't want it).
• You cannot prove a product idea just from customer interviews - you have to start building in parallel.
• Focus - there are too many ideas! "Startups don't starve - they drown".

Should you read it?

Since I moved in house, I've always been most interested in building skills that private practice generally neglects: strategy (not for the likes of associates), negotiation skills (often assumed, incorrectly), and engagement and leadership skills (generally not prioritised in PP - billing and client relationships are what get you promoted, and anyway a new cohort of associates will be along in a month or so).

I think this is true of a lot of IHC - they land in a business where they are not the product; they realise pretty quickly that being an ivory tower subject matter expert isn't going to get them very far; and they adapt.

But, even among experienced IHC, some legacy PP behaviours remain - for example, risk perfection - i.e. beating the risk out of everything you touch, and carrying out diving catches to "save" the business (when this diminishes accountability) - and assuming that your colleagues care how hard you work (they don't). The most impactful of these legacy behaviours is a lack of customer centricity.

PP lawyers make assumptions about how their product is experienced, and what clients need. They rarely test those assumptions - in fact they might even assume that they know better than the client what the client needs. This is how you get all the shitty law firm apps, among other things.

But! In-house teams are increasingly getting the importance of customer centricity. Here's a message from a fellow in-house lawyer, who wrote to me over the weekend:

How did you identify the processes that you wanted to make more efficient/ problems that needed to be solved? How did you go about designing the solutions?

I've received variations on this question from many counsel. It boils down to: where do I start? And my answer is always the same: find out what is the most pressing need of your biggest customer, and start there. And that's what this book is for: to help you understand what your customer actually wants, and to avoid you wasting your time and resources building products that your customers don't care about.

So:

• you should read this book if you are making your first forays into building products for your internal customers, and you haven't done customer discovery before; or you're in sales development and you're wondering why customers keep ghosting you.
• you should not read this book if you're an experienced product developer.

Would I read it again?

I would.

Here are things that you might not like about it: (1) it's very, very short (and yes I see the irony in complaining about this after whining about how long all the previous books are - but this is formatted like a kids' book, barely cracks 100 pages, and yet it weirdly is very expensive); (2) the author's style, which is borderline grating; (3) obviously the name is dumb. But anyway: it's good. It contains important truths about product development. It's a great place to start. Try it!