Whether you’re writing a business plan for your personal startup (the tech equivalent of the Great American Novel that every hack journalist plans to write), a report for your customers, or a proposal for your managers, sooner or later you’re going to have to describe a customer problem — the justification for creating a product or launching a project.
Frankly, the majority of customer problem descriptions I’ve seen and heard — including those I’ve been involved in — have been either poorly thought out or complete B.S. I know I won’t always be allowed to use this, but as a consultant and as a poor fool who still dreams of his own startup, I’ve written a checklist of six criteria that a real customer problem must meet:
- It uses the customer’s language, not yours — if any words or ideas need to be defined or explained, then it’s probably not really a customer problem.
- It describes a business need — it should not mention the proposed technical solution (such as a social network, CMS, etc.).
- It is recognizable — the customer is already familiar with the problem or with a very similar one, and doesn’t need to be convinced that the problem exists (though she might not be aware of its severity).
- It is quantifiable — even if you can’t assign a number yet, it is the kind of problem that has a cost expressed in concrete units such as money, time, subscriptions, support calls, page views, etc.
- It is compelling — you can demonstrate potential benefits, savings, etc. that justify the time, cost, and effort for the customer to try to solve it.
- It is succinct — you can
describethe problem meaningfully in a single, short sentence (of course, you’re always free to elaborate it somewhere else).
The passing grade on this checklist is 100%. If only one checklist item is missing, the problem is likely just wishful thinking — if your product or project succeeds, it will be despite your idea of the problem, not because of it.
Note: It’s actually easy to come up with problem descriptions that meet all six criteria; what’s hard is coming up with problem descriptions that meet all six criteria and have credible technical solutions.