What should I do when a client starts with a solution?
It has become an adage. Start with a problem, not a solution. Everyone working in product knows this. It’s practically a commandment. “Thou Shalt Not Start with a Solution”. Yet so often clients commit this cardinal sin. Why? And what can you do about it when a discovery is initiated with “I have an idea for an app” and you’re tasked with reverse engineering a problem? Well first let’s understand why it’s a problem (no pun intended) to start with a solution.
Why you SHOULD start with a problem
A huge part of a product-centric approach is to build something that not only performs the function for which it was designed but also to build something people want to buy and use. The best way to get people on board with an idea is to understand them. What are their needs, frustrations, motivations and fears? What makes them tick? What prevents them from ticking? The only feasible way to get people engaged in a solution is for that to be the solution to one of their problems. If you understand them, then you can understand their problems. If you understand their problems, then you create feasible ways for them to be resolved. It feels obvious. And when you think it through it seems ludicrous that anyone try and do it the other way round. But that isn’t always the train of thought. Sometimes sudden inspiration strikes and a great idea is generated. This idea might be rooted in the application of an existing idea in a different market or a personal experience where the client believes they are the user persona. Whatever the origin, a solution has been conceived without starting at the problem.
“Who is it for?”
“Everyone!” or “Everyone who drives!”.
🚩🚩🚩🚩🚩🚩🚩🚩
If something is for everyone then I can guarantee it is for no one. There are people who aren’t on social media at all. With its billions of users, Facebook still isn’t for everyone. What “its for everyone” means is there is nothing in the solution that people with any specific problem can relate to in the product. People buy differentiated products when they feel something speaks to them directly. This is true even at the largest product level. Sometimes the problem is superficial and intangible (like portraying status by having a certain brand of car or clothing) but the problem is specific and the solution is brought by the companies that understand that problem-holder.
Starting with a problem is seeing the round hole and building a round peg. Starting with the solution is building a square peg and trying to jam it in every hole until it fits. The issue is, even if you do by chance find a square hole, there is nothing intentional about your pursuit of the right hole and you will find it hard to repeat. There may not even be a square hole and then your peg-creating efforts would be completely wasted.
So why do people do it?
Well as alluded to above, ideas sometimes seem to come from nowhere. Or they seem like they do. Often there is an assumption made that the client hasn’t fully validated. This is usually at least one of two things. They have a specific experience that they feel the solution would have alleviated and then follow on that assumption with a series of more. Other people have that experience, they find that experience significantly inconvenient and they are willing to change what they are currently doing to use this new solution. The other thing that happens is there is a popular trend (AI at the moment) and the client finds a way to shoe-horn it into a solution for their industry.
Of course, when building a new product, you always need to make assumptions. But these assumptions should be validated first and foremost with the people you are aiming to help. You may be completely right that a problem exists where this product would provide a solution. But is it significant enough? Are people willing to go through the process of change required to adopt it? Are they willing to pay more than it costs you to build it?
And as for the popular technology trend? It may well provide an uplift in the experience of the intended target. But does it solve their root problem? Is it the best way to solve it? Or is it a “cool” feature that doesn’t provide enough value on its own to be considered a product? If it doesn’t strike at the heart of their problem, it will be a fad, at best.
So what can you do?
- Accept the idea — When presented with a solution at the beginning of discovery, you should accept that the idea has been conceived. There is no use pushing back completely and throwing the baby out with the bath water. Use this as the foundation of your questioning. The solution may well be valid, so you may end up there anyway. But set expectations around how you will get there i.e. through understanding the core problem.
- Challenge the assumptions — Work your way backwards, through conversation with the client, to figure out where the idea has come from. It is likely that there is a problem in there somewhere. Find that problem.
- Validate any assumptions — There will be assumptions made about who the product is for. If you do get something akin to “everyone”, then dig deeper. Get to the core of the assumptions and make them testable. If you can, eliminate any assumptions not based in reality but for anything you cannot eliminate, frame them in a testable way. Ultimately, neither your opinion or the client’s is important; the market will decide so position assumptions to be tested by that market.
- Create strong, detailed personas — To fully test assumptions about the problem and then the solution, you need to be clear who will benefit from the solution and what their significant pain is. Be very focused when creating the personas. The more specific the personas, the quicker you can validate if they really have the problem that you’re trying to solve.
- Relate the original solution back to the problem and personas — Once you’ve got to the root of the problem and have a clear idea of who has that problem, go back over the original idea that was presented. You can clearly highlight which elements of it go to solving that specific problem and which elements were superfluous. Use this as a teaching point to ensure that you always start with a problem in future and then continue to build a solution based on the problem, not the original idea
- Be open to the possibility that there is no problem — What might happen, is that you find there is no significant pain, no customer who really needs the solution and therefore the idea is not viable. Make sure that the client is aware that this is a potential outcome from the beginning. “Do nothing” should always be an option when evaluating any type of action, and building a new product is no different. It is likely that a problem will be uncovered during this discovery period, but if it has nothing to do with the original idea, that is ok. Never let the client force the original idea in spite of the findings of discovery.
Conclusion
Although it is common best practice, starting with a problem isn’t always how projects start. Ideally the client will have a clear idea of the significant pain that a specific persona will have and want to test a solution against those assumptions. However, frequently the first few steps are skipped and you will encounter an idea that isn’t based on a specific problem. Stick to first principles and manage the expectations of the client through the steps above to guide them towards something valuable, in a process-driven way.