How-to Start Loving Problems
Finding “real” Customer Pain Points
Introduction
People face problems on a daily basis and tend to see appearing problems as obstacles. We organise life to work so well, such that minor deviations from the plan can shake our daily routine. The good thing I can tell you is:
Stop seeing problems! Start seeing opportunities!
This article will give you insights into the concept of pain point analysis — one of the mightiest instruments in a venture design and the number one strategy in product development. Once you grasp the main idea behind the concept, you will perceive daily problems from an entrepreneur’s point of view and make a step forward to activate your creativity and ingenuity in order to solve them! And bear in mind! The golden thumb rule of business is
A customer’s pain is a business opportunity!
The rationality behind this thumb real is a customer with pain is willing to pay for relieve. Exactly this is the spot where a new business opportunity arises.
The Four Types of Pain
Before we start to build a solution, we have to name the problem. This is the first step of the pain point analysis (PPA). You can only start to develop the solution, when you understand the problem — never underestimate this fact! The better you understand the problem, the better your solution will be. So make sure to spend enough time on the problem definition.
The classic analysis defines four kinds of pain points
- financial
- process related
- productivity
- support pain points
Let me give some example. Your electricity bill is too high and gets more expensive every year. You don’t understand why you have to pay that much for electricity, since your appliances have efficiency class A ++. This is a classic financial pain point. Such pains are most evident, since they are directly measurable through the price tag. Not instantly measurable, but more exhausting are the process related and productivity pain points.
Let’s think of another example. You work in a team and your team leader has to coordinate the team to work most efficiently. The company you work for loves pens and papers — so they never make their mind on purchasing software to do all the team planning. A classic Productivity Pain Point, which can be solved trough centralised team management software.
Let’s spin further the example: you work in a team, and your team leader holds multiple team management apps. None of them are compatible with each other. Your leader coordinates each division — the technical development, the business unit, the quality management — with different software solutions. He still spends most of his time updating the different apps with new information from the other division apps, since they work remotely and not centralised. This is an example, where the previous productivity pain point changed into a process related pain point.
Now the example shows a team with different divisions, a team leader, and too many not compatible team management apps. The leader is annoyed, since the company’s technical adviser recommended this multi app solution. He hasn’t gotten the right help. A Support Pain Point.
To conclude, a productivity pain point and a bad solution led to a process related pain point, which gave rise to a Support pain point. And lastly, the electricity bill comes in with a new record volume, since everybody is sitting at their computers, trying to coordinate trough every management software.
Name your Pain Point
Pain points are everywhere and they are linked. Analyse this system of linked problems and define the exact problem in this chain to name your pain point. Extract the problem to a minimum to get a clear pain point, otherwise again you will get a subset of pain points. Iterate a few times to get your clear pain point.
Keep the before mentioned types of pain points in your mind like rough road maps you can stick to while analysing. This will help to understand related problems you already conquered or problems of others you have seen. Try to see the problem from the exterior. Think in the point of view of colleagues, superiors, outsiders. This will help you to understand the objectivity, since pain points are subjectively perceived, as they appear on a personal level.
Solution Iteration through Interviews
Once you extracted the pain point, you have to prove that it truly is a pain point. You have to interview every group, your problem and therefore your solution is interfacing with. The solution idea will be shaped trough the input you get from the future customers. Nothing is worse than a solution nobody wants to use, since it is a solution for a problem that is not a pain.
You have to challenge the paint point to get a clearer understanding. And most of the time you have to differentiate pain points for target groups. The challenge is to find the perfect solution for all of the parties. This solution should be at first very straight forward — avoid too much different content in your first solution, it will distract you and your interview partners from the main problem. Something takes too long — find a faster way to do it. Invent a software that saves time trough a centralised planning feature. Only develop this very simple feature, don’t get distracted by the possibility to implement other nice to have, but minor features. Every other feature will be found in the future, once customers start using your first feature and demand for more. Don’t underestimate double-sided pain points, since one target side can be very pleased, but the other side didn’t have the pain point, you thought of. This will lead to the fail of your solution, since one side cannot work without the other. Let’s look at our running example of the management software: it will help to safe time, but it has to be cheaper than the monetary savings it provides. If the licence fees for the software are higher, the company’s financial department won’t approve it. Otherwise your solution would simply lead to other pain points like in the before mentioned transformation from a productivity to a process related pain point.
You have to iterate trough your solution and make changes again and again, until every target group has got its very own, very painful pain point. Painful in the sense of loss of money or time. Only if this step is processed well, you will find customers for your solution, which then is a product you can offer.
Make the Pain Point Measurable
We’ve already explained the explicit pain point and the product, now we have to quantify it. If it is a financial pain point in the first place, the measurement is quite easy. Expensive Electricity trough appliance usage is the value’s name, and the definition is how much you have to pay for the usage of your appliance per usage, per month or per week. This computer takes with a daily usage of 8 hours 400 kWh (400 000 Watt Hours) per year. Multiply it with the price of the electricity, e.g. 0,3€ per kWh and you will get yearly costs of 120€ per computer per year. Now you have three parameters you can optimise: lower the electricity price trough a better delivering contract, improve efficiency trough new computers or lower the usage trough more efficient software. The yearly costs represent the absolute point, which will make possible solutions for the pain point measurable. If you can lower the price you pay for the electricity by 20%, this value will directly lower the costs by 24€. Multiply it with the number of computers at work, and you will get a number big enough to make one prick up his ears. You have to make the pain point countable, to let people see how much money or time they can save by using your solution.
Optimisation and Process Pain Points are usually measured in time units, since the nature of processes and their optimisation describe temporal procedures. Typically you use the working hours of employees and the respective salary, or for machines their times of operation and the specific costs, therefore you can measure their costs per working unit, for example 3000€ per month for their salary, 5000€ operation costs for a day. Since employees do different tasks throughout their labour time, you have to analyse how much time they spend on a specific task. For instance, everyday 2 hours are spent on synchronising with the team, if information isn’t distributed centrally. With a 40 hours working week, you’ll get 10 hours for just coordination work. 1/4 of the whole working time means 750€ of a specific employee cost are spent for this work. Of course, this calculation is simple, but it is fully sufficient to begin with, since it unveils if there is any measurable pain, and therefore any demand for action.
Optimisation trough more efficient software was the before mentioned example, where we implemented the team management software. Let’s continue this example. Your team leader has received the new software, of course the centralised version which is very effective and lowers the team management planning time tremendously. The team saves 250 hours a week, which before were spent on planning and synchronising with the team. The whole team works 1000 hours a week. This measurement can be enhanced with money value: let’s assume, an hour of the team development time costs 1000€. The effectiveness rate rose to 125%, relative to the rate before the software was implemented. The team works 25% more on the real topic than before and develops therefore more quickly. Since they are working better than before, the company saves 250 hours times 1000€ per hour each month by providing a solution to this pain point. Again, the calculation is simple at this point, but it is enough to prove the urgency of a solution. The higher scale with view on the whole department even amplified the appeal for purchasing your product.
Conclusion
Take the problems as they come, think of solutions, develop products. As simple as it sounds, as laborious as it will be. But your work will be rewarded every time you find a new solution to improve everybody’s life, and once you started doing so, you will hunt for new problems you can defeat!
