Look for the core problem behind the solution
The IT sector is often considered different from all other industry sectors. Its focus on user needs can explain this. The IT sector understood something that the other sectors are struggling to learn.
The voice of the customer is at the center of the success
Car manufacturers can spend years and millions designing cars. And when releasing the vehicle, they discover that it doesn’t resonate with the potential users.
Whatever the industry and the company’s size, listening to the users is a must. But even now, this isn’t a common practice.
Customers’ feedback is essential. Customers’ feedback is material to the success of the company. The IT industry has understood this for a long time. Other sectors are only beginning to understand this. And they are now starting to put the user at the center of their attention.
A company cannot be agile and grow without listening to the voice of the users. This is particularly true in the present context of volatility.
The voice of the customer fuels the company’s strategy to adapt to market evolutions. In these times of economic downturn, this is even more critical.
Would you rather take a bet on a product? Or would you instead build confidence that it will generate revenues?
Would you bet your survival on gut feeling?
Listening to the customers is a good start, but not enough. But a company that doesn’t listen to customers is doomed.
Don’t become user-led
Listening to the customers is a good start. But what you are listening to is not directly actionable. At least, it would be best if you did not act upon it without a more in-depth analysis.
The user feedback has a bias
The users base their feedback on their context. The user genuinely wants to help you. And for that, he tries pushing solutions. He explains what he would like to have to perform what he wishes to achieve. However, he doesn’t explain why he hopes to accomplish this. He doesn’t explain the “job to be done.” He gives you the workaround that he would like to use.
Likewise, he describes the patch he would like you to apply for his symptoms. Furthermore, this solution depends on his technical skills. It is also peculiar to his context. There is no guarantee that this solution can solve the issue of any other user. Imagine if a doctor acts on the patient feedback:
The patient: doctor, I have pain in the chest. Please give me some pain relief.
Would you not like the doctor to go deeper and investigate your concern to see whether you are having a stroke?
Being User-led is the easy way
Listening to the user and following the loudest voice is the easy way. It may even bring some growth for your company temporarily.
Your product manager determines which feature request has the most votes. He can even perform quick research. He determines how much revenue represents the users who voted for that feature. Based on this, he prioritizes the feature in the backlog. Then, he releases an upgraded product that will please at least this segment of the users.
But your strategy is now made by users with interests divergent from yours. They are pulling you in every direction.
Eventually, you find yourself with the following:
- The product is becoming a collection of loosely related features;
- It is no more clear what problem your product tries to solve;
The users are not more feeling bound to your product. They don’t resonate anymore with it. They finally change their minds, churn, and fall in love with another product.
User-led strategy prevents you from generating value for the customer and your company.
Product managers usually spend too much time elaborating on solutions and executing them. Product managers should spend the vast majority of their time researching. As in school, the answer is in the problem statement when it is well understood.
Will Agile save you
Agile promotes building an initial solution as quickly as possible. Then you build the complete solution via iterations.
It looks like you could:
- Begin with building the solution requested by the user
- And then iterate until you have a suitable solution.
On each iteration, you build what the user requests more. You know you have solved the whole problem when there is no more request.
But this will take forever!
And this is a wrong application of agile. Agile is about speed and reactivity, not thoroughness.
You use months of development time to escape from some days or weeks of research. This is not a good bargain. Developing a solution is time-consuming and expensive, much more than researching. So don’t take that shortcut. Do your homework and ensure you go to the root problem before launching a solution.
Anyhow, what will be the interest in iterating on the wrong problem?
Don’t be user-led, be user-focused
Being user-focused means ignoring or even going against explicit user wishes to serve the user better.
Determine the problem behind the solution to become user-focused
Being user-focused means putting the user value at the center of your concerns. This doesn’t mean acting on every request the user makes. This means understanding your users’ pain and how your product can solve it.
Being User-focused means focusing on solving the right problems and generating value for the user.
You start from the solution proposed by the user because this is the only information you have. From it, you work your way to discover the problem the user is trying to solve. This is best achieved by active contact with the user. Don’t only listen to the feedback the user spontaneously gives you. Ask questions to uncover the hidden problem behind the solution. It would be best to lead the communication by letting the user speak.
Evaluate how the user’s context makes the problem specific. And make it as general as you can.
Companies do not usually do this because active listening to the user is not easy.
Efficient product managers master these skills.
They ask open questions to discover the problem the user is trying to solve.
Don’t hesitate to spend that extra hour listening to the customer and understanding their problem. Put yourself in their shoes, understand what they want to achieve, and feel their pains.
When you identify the problem, state it as clearly as possible. It exists several types of frameworks for that, one being the “Job to be done.” Use the one that you are comfortable with. Don’t stop at the solution given by the user, and determine what particular problem the user wants to solve.
It is easier to find a solution that brings significant value to the user. This also puts your product in a better position than the competition.
But is this problem the right one to solve?
Well, it is probably not the right problem to solve!
The users’ pains are mostly “Undesirable Effects” (UDE) of a more in-depth issue.
The UDEs are the tip of the iceberg. And your mission is to solve the iceberg!
By solving the UDE, you treat symptoms. You change the user’s life only on the surface. It will not be enough to turn him into a raving fan.
Solving a more profound problem may change the user’s life and turn him into a raving fan.
A short example to illustrate
Imagine you are selling an application to create a personal knowledge system.
You collect feedback from your users:
- one wants to have several levels of folders
- another wants nested tags
- another wants sub-pages
You can quickly implement all these requests one after the other.
Your software now has several levels of folders, tags, and subpages.
But, it becomes too complex and confusing. The users feel overwhelmed. They don’t know how to organize their documents. They spend more time managing the application than their knowledge system.
The users had a simple problem: they wanted to organize their notes and ideas.
Now it is up to you to suggest a solution that satisfies the users. It may be opinionated. It may not even please everyone. But you bring a solution to a more in-depth problem. And if your solution is sound, you will have brought value to the users. They will recognize it, and they will go on using your product.
How to know that we are solving the right problem?
Collect from users the UDE relevant to the domain of your product that you want to improve. Usually, 3 to 5 UDEs are enough. You need to take care that not two UDE are the same issue described with different words.
If possible, takes UDE from different user segments to enlarge your analysis’s reach. Try also getting UDEs from “normal” and power users.
With this, you will cover, as far as possible, the whole spectrum of issues your user base faces.
From your list of UDE, you must now find the root problem. You can use several methodologies for that (the 5 WHYs, the Current Reality Tree — CRT — from the theory of constraints, etc.). I use CRT. It needs some training. But it is easy to explain, and its logic makes it simpler to align the stakeholders.
Now you have the root problem that requires resolution. And you also have the confidence that solving it will bring value to a broader sample of users.
This problem has significance for more users. So, it is more worth solving.
The solution you build may be more complex but is mostly more complete. It solves all the identified issues at once. The solution is not a patch. It is a real solution to a real problem, even if your users do not recognize it at first sight.
The business contains examples of root problems that were difficult to uncover. This is true in any industry, and solving them brings massive benefits.
A steelmaker industry was offering a productivity bonus to its employees. This bonus made them produce more of a kind of steel sheets that were quick to manufacture. Unfortunately, this steel was not the one most requested by the customers. They changed their bonus policy. It was enough to increase their earnings and reduce their inventory.
When managing a railway equipment industry subsidiary, a cement plant contracted us to repair two old locomotives. It was a project of about 100,000 USD. While discussing with the client to understand his problem, we could detect more in-depth problems that we could potentially solve. Building the logic tree made us discover a greater pain. We also determined that the locomotive repairs would not alleviate this pain. Their main issue was that the locomotives had nothing in common with the other machines they used in the quarry.
We proposed modernizing the two locomotives with the same engines and gearboxes used in their chargers and other giant trucks.
We ended up with an order of 2 million USD and opened a new market for our company. (More details in the full article)
You have the root problem and the solution. Don’t jump into development right now
It would be best if you had patience. All the time spent researching doesn’t guarantee that this is the right problem to solve.
Take a deep breath and take one step back.
Take the time to experiment. This is the correct way of acting in an agile organization.
Make an MVP, a prototype, a design, a handwritten sketch, or whatever is relevant to your domain. Then look for early feedback. This will tell you whether your solution alleviates the users’ pains. It may tell you how much this solves their problems. No feedback is too early.
This approach validates, as far as possible, your hypotheses before committing the total budget for the production of a solution.
Unlock your growth
When designing the solution for the root problem, never lose sight of your company’s goal.
Whatever its mission, your company’s goal is “making money today and even more tomorrow.” — The goal, Eli Goldratt
There is no shame in that; this is the nature of the business.
Your mission only tells how you will make money; it is not a goal in sine.
Keeping this in mind, consider the root problem you found as an opportunity to solve a problem your competitors have not yet discovered. Build an unfair advantage. One that your competitor will have no choice but to match.
Create a “mafia offer,” an offer so good that no one can refuse it. Create a killer feature.
Innovation is not constantly inventing brand-new technological breakthroughs. Innovation is using existing and proven technology to solve an issue that the competitors have not yet identified.
Solving root problems will secure growth. It delights users and turns them into raving fans.
This looks quite like a cocktail for success.
When phone users wanted to have their emails in their pockets, Steve Jobs offered to have the whole internet in the palm of their hand.
Don’t think blackberry — think iPhone.
Didier Varlot is a product and project manager, mentor, and investor. He has worked on large infrastructure projects in several industries for the last 42 years.
He now helps startups and companies integrate project and product management into their processes.
Book a call with Didier to discuss your need
Subscribe to his newsletter
