Solving the wrong problem is the biggest problem for your product

Most product teams are great at coming up with best solutions to a problem but not many are great at finding and solving the right problems(that delivers maximum value to the users and business) which is far more important. From what I’ve seen this is one of the biggest challenges that many product teams have and is what limits them from maximizing user satisfaction and business performance.

What is “right” problem?

Many different definitions out there but here’s my take on it.

Problem worth solving

There could be thousands of problems to solve in a product. And in order to maximize the impact you always want to prioritize and solve the problems with highest ROI(return on investment) potential first. To calculate the ROI you need to gauge two things essentially – Impact vs Cost. Here are some data you may use to estimate the impact:

  • Size: How many people today are suffering from the problem you’re trying to solve?
  • Frequency: How frequently does it happen? Once a month? Every day? Every minute?
  • Importance: How important or severe is the problem? Is it a little scratch or pain that makes them scream?
  • Satisfaction: How satisfied are they? Not at all? Barely? Or are they already satisfied?

And as for cost you may want to consider:

  • Complexity: How complex or difficult is the problem? Is it a simple puzzle that you can easily solve? Or very complex problem that requires Einstein thinking?
  • Time & Resource: How much time and resource would you need to effectively solve the problem? Is this something you could solve relatively quickly without anyone’s help or you need everyone in the team to put in their effort for longer duration of time?
  • Risk level: Is there any risks involved? If yes would it be worth taking risks?

Calculating the ROI and making prioritization is crucial step in the process and it allows you to go after only the highest impact opportunities that can add the most value to user and business. You never want to be in a situation where you spend 6 months to fix a problem and later find out that you fixed a problem for less than 100 people, which is terrible return for amount of time and effort spent by the team.

(NOTE: I designed Asgard Analytics to make it effortless for the team to find biggest opportunities/problems to tackle.)

Real problem

You want to find the root cause of the problem, the true problem that’s underneath the surface and not easily discovered at a glance. And it usually takes time and few loops before you can really understand or identify the real problems.

Some teams take the approach of going narrow and deep on a single problem, doing as much research as possible before putting something out to the market and thinking that more time and effort they spend more chance they have of succeedding.

But this is rarely true based on my experience. There’s no such thing as perfect solution on a first try. And even if you get lucky and do get it right, people’s needs and expectations change over time(very quickly these days). Therefore this type of approach just won’t be effective.

Instead it’s more effective to approach it as ongoing research – iterative process of optimizing the hypothesis and getting closure to what the real problem is in every step.

Here’s an outline of what those steps look like:

1. Formulate problem hypothesis

Don’t spend too much time trying to do as much research as possible up front. Once again it doesn’t matter how much research you do in the beginning because you can never be sure until you validate with your users. Use both qualitative and quantitative data to help you formulate some hypothesis on what the problem could be and move onto the next step.

2. Design a minimal solution to test your hypothesis

Don’t try to design a perfect solution! The whole purpose of creating a solution is to validate your hypothesis and not for the sake of shipping things. You just need something that’s good enough to be able to validate your hypothesis effectively.

Strive to design a MVP (minimal viable product or feature). The idea is not to design something that’s too minimally where it looks like crap and doesn’t function properly. At the same time you want to avoid designing something that is expensive and will take forever to build. Design something that’s both minimal and viable and that will allow the team to move quickly. Revisit and think about what problem you’re trying to solve and brainstorm what is the very minimal thing(s) you can design to validate your hypothesis.

3. Validate with users as quickly as possible

Faster you put it in hands of the users faster you’ll be able to learn. Validating with users is the only sure way to find out whether your hypothesis is true. Two things are critical to validate: usability and value.

Before you can effectively validate value you first need to ensure that there are no problems with usability. Otherwise users may never even get a chance to fully experience the value as you intended. Here are the fundamental things to look for when validating usability:

  • Discoverability: is the feature or product discoverable?
  • Understandability: do users understand what the feature is about? is perceived value higher than the perceived effort?
  • Complete use: can users accomplish their task or get the job done?
  • Easy of use: can users get through everything effortlessly? or do they get stuck or get confused while using it?

For validating value most effective way to do it is through A/B tests. Concretely define the success criteria and what you need to measure to help you make a decision. For example, number of repeat users and repeat uses can help you understand whether users are finding value.

4. Learn and iterate

Once users start using the solution it doesn’t end there. You need to continuously observe and analyze the results. And this will help you further narrow down your hypothesis and allow you to make a decision whether to continue to iterate or move on to the next biggest idea or problem.


Poor execution is bad but what’s even worse is awesome execution on a poor idea/problem. Is your team focusing on the right problem? Or taking right approach to finding a problem?

Interested in chatting about how I can help? Let’ chat!


This post doesn't have any comment. Be the first one!

hide comments

This is a unique website which will require a more modern browser to work!

Please upgrade today!