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
describesummarize the 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.
Quoderat 
2. I’m suspicious. Customers don’t give a sh.. about business needs? Why should they?
4. Counting is part of the analysis surely? Not the problem definition?
5. Not IMHO. It may be, from the organisational perspective. It may actually
cost the business to solve this one. Still good from the customer perspective?
6. I’d prefer ‘summarize’ to describe. This to retain 1, which is key.
regards DaveP
Thanks for the comments, Dave.
#2: Sorry for any confusion — I’m talking about the customer’s business need, not mine. Companies don’t buy software, for example, because RSS, Atom, or Semantic Networks are cool; they buy software because they want to do something with it. What they want/need to do — not how they’ll do it — is the business need.
#4: Counting is part of the analysis, but the problem itself has to be quantifiable so that that analysis can later take place. There has to be something there that you and the customer can count, or else it’s all fuzzy, hand-waving stuff.
#5: I think there might be more confusion here — for me, the customer is the one who we expect to fund the project or buy the product. It might be an internal customer (say, the division in your company from whose budget the funding will come), or it might be an external customer. If the customer’s problem isn’t compelling, why would they bother spending money on your project or product?
#6: Yes, I think “summarize” is a good change, and I’ll edit the posting accordingly.
That’s also a great checklist for “What makes a good bug ticket”.