Problem vs. solution in digital products

Lex van Zalingen
4 min readMar 5, 2021

When starting on a product you might ask yourself ‘who are we building this product for?’ The answer most likely describing your view on the target customer.

Let’s skip ahead a couple of weeks. You most likely performed research on your target customer, their needs and problems and how those would relate to your product. You know a lot more about your customer and their pain points now, which is great input for building a better product.

The key lies in what you do next.

Photo by Matt Artz on Unsplash

As someone working on digital products you are prone to get wrapped up in a battle between stakeholders and users. Stakeholders tend to think in solutions. Which is great when you are in solution mode. But when you are still in problem space, solution mode is the last thing you actually need.

Let’s look at the problem and solution space quickly, following Product Guru Dan Olson’s definition.

Problem space is the area in which you find customer problems, (underserved) needs or benefits that your product should address.

Solution space is how your product would address the customer problems, needs or benefits.

The issue in practice

Using a fictive product may help us understand the issue. We will be looking at a fitness application that helps users stay fit at home now that we are all struck by COVID-19.

Potential users might tell you in your research phase that they are struggling to stay motivated. A user researcher would tell you to ask more questions like:

  • Can you tell me something about how that makes you feel?
  • Can you tell my why staying fit is important to you?
  • Can you tell my a little about why you feel you are struggling to stay motivated?

Stakeholders might jump straight to solution mode and say: “I know what we need! We need a journal so that users can log their progress and stay motivated because they see that they are progressing!”

Well, will it? Will it help the user stay motivated? Will it help solve the customer problem at hand? I guess I do not need to tell you the answer, but I will anyway. It might, but we do not know.

What we see happening here is a stakeholder or someone on the product team jumping to solution mode too quickly. Although it is very tempting to do so and it might not even be totally wrong, we need to hold our horses a bit longer. We need to understand the customer problem fully and only then we can jump into solution mode.

Ask more questions, try to understand why the problem is occurring and what implications the problem has on the life of the customer. Use techniques like shadowing and in-depth interviewing to uncover more of the qualitative truth. Once you have learned about the customer’s truth, try to quantify it to see whether solving this problem will actually result in a viable business case. Without quantity and viability, there will be no product.

That does not mean though that we will stay in the problem space until the end of time. In fact, there will be constant back and forth between problem and solution space.

What would the right time be to jump into solution mode? I’d recommend asking yourself these questions:

  • Have you uncovered a clear customer problem / an underserved customer need?
  • Do you know the impact of this problem on the life of the customer and what would it mean to the user if it were to be resolved?
  • Is there a quantifiable market for this problem, or is it a one-off?
  • Can we create a viable business opportunity in resolving this problem?

Note that not all questions need to be answered with a fine-grained answer that you spent months developing. As with ‘lean’ methodology overall, the answer needs to be ‘good enough’ to make you take the leap.

The leap

You can develop an artefact that resembles your solution, but restrain yourself from develop the entire solution without validating it first. I have learned first-hand that this happens. We jump into solution mode with full force when we think we know everything there is to know, but I can tell you that this beautiful assumption is never true.

Before investing heavily in what you think is right, validate whether it actually resolves the customer problem you uncovered, the (underserved) needs you looked into and whether it provides the benefits to make it truly valuable.

Looking at our fitness app again, let’s assume for a second that the journal seems to be the right thing to build. Design it, prototype it, test it and learn from it. When you validate your solution, you basically test whether the conclusions that you drew from your time in problem space are true. You can easily do so with a simple but effective assumption list.

We are going to call our target persona Peter for now. We know that Peter is struggling to stay motivated. His goal is to stay fit. Our research thought us that this might be due to the fact that Peter is not able to see his progress clearly. The journal might simplify this for Peter.

We test with 5–7 x ‘Peter’ and we learn that the journal does not contribute to solving the problem as we thought it would. We invalidated our hypotheses and from the tests we’ve learned that a journal is not worth the investment as it does not solve the customer problem we uncovered.

Circling back

We go back to the problem space, we check whether the problem we uncovered is still valid and we try again. Does this seem inefficient to you? Think about the amount of cash that we saved by restraining ourselves just a tiny bit and not building the journal feature. If we did just go for it, we would have invested a lot to develop the journal and we would be stuck with an unsuccessful feature. We did great!

--

--