Rule 46: Find the problem that customers will pay to solve – and solve it
This rule, coming from Mara Kreips of Pivotal PM, is essential to any successful product.
Rule 45: Find the problem that customers will pay to solve – and solve it.
The key to bringing a successful product to market is first to intimately understand the customer’s problem and then to provide a solution for which they are happy to pay.
The “solution in search of a problem” is an ongoing quip among technology product managers. Those of us with more than an iota of tech industry experience know that company leaders (i.e. founders with a strong technology background) often confuse “what we think is cool and can build” with “what actual customers will pay us to build.” You might have great examples from other industries – perhaps even from your own company. In the apparel world, the “portable office tie” is a memorable example. This was a conventional-looking necktie that concealed an armory of office supplies, including scissors, ruler, paper clips, pens, stationery, business cards and a wallet. (Do a web image search on “portable office tie” if you don’t believe me.) Some may think it’s an interesting, even cool, idea, but who would actually pay for one? Trust me, you never want to product-manage “the solution in search of the problem”. It’s much more fun to a) know exactly who needs to solve exactly what problem, b) provide them with a great solution and c) watch them repay you with a smile – and cash. The way to get to c) is to have a crystal-clear understanding of the problem that is painful enough that the customer will pay to solve it. This is a product manager’s market research “holy grail”. To that end, here’s a handy list of questions that I’ve used for both commercial and internal product initiatives:
- Who has the problem? (List all stakeholders – buyers, influencers, direct and indirect users)
- What is the problem? (It may be different for each stakeholder)
- What are examples of his/her pain? (Specify the stakeholder; and quantify the effect of the problem if possible.)
- What is the potential benefit of solving their problem, i.e., how would his/her life be better?
- Will the customer pay to solve this problem? How do we know? (Note that “payment” may include cross-charging for internal projects or willingness to view ads in exchange for a free product.)
If you can answer these questions, and then communicate your insights to the rest of the product team, you’ve got a fighting chance of launching a very successful product. In my own career I’ve managed winning products by tenaciously focusing on the customer’s problem. At one cash-strapped company I led a tiny but intrepid team through the research, planning and definition of a brand-new product in just 10 weeks. (Note: if you’re an Agile practitioner who’s scoffing at this “glacial” pace, kindly note that I led this work before the widespread adoption of Lean/Agile technologies and I’m talking about full product definition, not iterative.) Since neither I nor my colleagues had any prior knowledge of the subject matter (payroll accounting), we spent most of our research time with customers in their offices, observing them on the job and asking many questions about what was most painful and onerous in their daily work. We had no other way to succeed at our research task – there wasn’t enough money or time to go beyond developing a deep understanding of a handful of real people’s problems. Happily, our work resulted in the launch of a successful product a few months later. The product was so well-received that it actually outlived the company.