I was involved in a conversation last week where we were trying to unearth customer pain points. One of the software product managers explained that main pain points were integration and scalability. This is what set me thinking about the difference between pain points and requirements. The two are not interchangeable – in fact there is a parent child relationship here which if you ignore, you could end up building the wrong or a less preferred product.
Pain points are what customers are going through because they do not have a product that solves their problem. For example, before the advent of wireless devices, a customer pain point could have been that he cannot make a phone call while he was in the car – notice that nowhere in this pain point is wireless mentioned. Putting wireless into this sentence would be jumping to a solution as to how to solve the pain point. It is extremely important that product managers understand the real pain points. Here are some other examples – all cooked up for illustration.
1) I am in sales and I get a lot of customer queries via email. I need to respond to these quickly to close the deals. This is especially true towards the end of the quarter. But given that I am travelling and in meetings at customer sites, I am unable to do this because I cannot get to my email unless I am in the office and this costs me time and money. For example, in one instance last quarter I missed closing a deal worth $1M by one day. (I guess RIM probably heard this a whole lot and came up with the Blackberry – but do you see anything about a Blackberry or a mobile device in the customer’s description of his/her pain point? – does it say anything related to integration or scalability or ease of deployment in the description?)
2) I usually get out of the office after the banks have closed. Hence I am unable to get to the bank before they close to withdraw money from my account. Hence I have to remember to withdraw money on Saturday mornings, enough to last me one week. I feel uncomfortable carrying all that money around where ever I go. BTW, this is still true in a lots of places in India (what do you think could solve this? I can think of two – ATMs, credit cards)
3) I end up paying a lot of late fees because I forget to mail my payments on time or because the postal service takes more time to delivery my check to the credit card company. For example, last month I ended up paying $58 in late fees. It is hard to predict when exactly to mail the payment. I cannot afford to send the money way ahead of time because I have to wait for paychecks to get deposited (Could very well have been one of the pain points that created online banking)
You get the idea. It is very easy to fall into the trap of starting to describe product requirements and not pain points. It is not easy to do tjos because the creative part of our brains loves to start thinking about how to solve the problem. But take control – make sure that you understand the pain points very clearly before you start listing requirements or evaluating product ideas.
3 thoughts on “Pain points vs. Requirements”
You’ve summed up the point of my brand PainPoint!
You’re right about the temptation to jump into solutions without fully understanding the problem you’re trying to solve. It’s a tendency in life and not just in product development.
It’s just a semantic point, but many of us like to say that requirements should be free of design. Under this terminology, once we get into specifying solutions, we’ve done some design and are therefore not doing requirements.
For this reason, I say that a requirement merely restates a problem you’re trying to solve, but in terms of the least stringent conditions that must hold to solve or avoid the problem.
So if the problem or pain point is
“Users can’t make phone calls from my car.”
The requirement is
“It shall be possible for users to make phone calls from their cars.”
This example is oversimplified, but hopefully you get the point.
Next, product designers can specify that the product will be a cell phone with certain features, but then it’s a design specification.