What problem is your product solving?

I’ve given the same advice to a few different people over the past year, which generally means it’s time for me to write up that advice as a blog post.

In this case, what I have been telling entrepreneurs is that they don’t have a business until they are addressing a problem that people will pay them to solve. It’s not enough to have a technology. It’s not enough to solve a problem. It has to be a painful enough problem that somebody will pay them to solve it.

The advice that they don’t have a business until they are solving a monetizable problem seems obvious, but when an entrepreneur has fallen in love with an idea to the point of starting a company around it, it is often difficult for them to step away from the idea and see things from the customer’s perspective. If a customer won’t pay for the idea, they don’t have a business, no matter how amazing the technology is, and no matter how much the entrepreneur thinks the customer needs it. I had a session with an entrepreneur last fall where he showed me his platform technology, and I asked “So who will pay to use this?” and he said “Let me show you the technology again and this amazing functionality!” and I said “Yes, the technology is great, but which users are you targeting?” and he said “Let me show you another feature!” and we went around and around.

For academic backing, I now refer to Clayton Christensen’s “job to be done” theory, where he says that customers are effectively “hiring” products to do a job. However, the job may not be the one that the product designer expected. He gives the example of studying milkshake purchasers at a fast food restaurant. When tracking who bought milkshakes, there were the expected consumers (parents buying their kids a milkshake as a treat after school, young people buying their own milkshakes), but nearly half the milkshakes were being bought by adults getting them to go first thing in the morning. The researchers asked those customers why. It turns out they had a long commute, they wanted something that would keep them from getting hungry, but they only had one hand free. Once the restaurant had that insight, they were able to target those customers with milkshakes and other morning drinks that would satisfy that need.

I love this story because it’s a reminder that even when a business thinks it knows its users and how they use its products, the users can often surprise the business with the creative problems they are solving with the product. So the best advice I have is to go talk to actual users of the product and find out what problems they are trying to solve. It is critical to go in with an open and curious mind, and observe the customer, rather than asking them leading questions like “How would you use Feature X?”; instead watch them perform their normal tasks, and perhaps ask “Why do you use Feature A in that way?” if you see something that doesn’t match your expectations (like the milkshakes being bought in the morning).

This is not novel advice by any means; for nearly two decades, I’ve been reading Mark Hurst of Creative Good, who built his agency, two books, and a popular conference on the idea of including your customers in product development. And yet it’s so easy to get wrong, because businesses far too often believe they know what their customers want better than the customers do.

In fact, this sort of hubris is the basis for Christensen’s Innovator’s Dilemma. As companies become large and successful, they confuse the successful products they created with the problems that those products were intended to solve. When they see a new cheaper product with less features, they dismiss it as a “toy”, because it doesn’t have the same features and capabilities as their industry-leading product. And then the “toy” product steals their lunch because it turns out their customers didn’t want an industry-leading product, they just wanted something that would solve their problems quickly and cheaply (e.g. Wikipedia destroying Encyclopedia Brittanica). This disruptive innovation has happened over and over again, and it will happen again because companies lose track of the problems their customers want to solve.

Entrepreneurs need to be particularly clear on the customer problem being solved, because that’s the basis of a good pitch. Back at Columbia, the advice we were given on pitching was to explain the customer problem, and how our product would solve it, in the first 30 seconds. That’s the so-called elevator pitch: a customer problem, and why the customer will buy your product to solve it. If you haven’t grabbed the investor’s attention with the problem, you might as well leave the room at that point; all the follow-up slides on technology and team won’t convince them there’s a business that’s worth investing in unless they believe in the problem.

A business is based on solving a problem that customers will pay to solve. Even though this is well-known and basic advice, I feel like I keep repeating it when talking to entrepreneurs, so I wanted to write it up to make it easy to reference with lots of links to supporting material.

P.S. As an aside, I would argue that this is also how to define your career: solving a problem that an employer will pay to solve. This is related to Cal Newport’s “rare and valuable” skills; part of what makes skills rare and valuable is that they are solving an important problem for an employer. When you are clear on what problems you can solve, it crystallizes how to pitch yourself on a resume or in an interview.

One thought on “What problem is your product solving?

  1. Entrepreneurs often cite Google, Facebook and Instagram as companies that didn’t solve a problem that people would pay for when they started, so they don’t need to think about monetization. I would argue that any company that has incredible organic user growth numbers is solving a valuable problem for people, even if they aren’t ready to pay for it. So if you can show insane growth numbers and can handle the growth (unlike e.g. Friendster), you’re fine 🙂

Leave a Reply

Your email address will not be published.