Ignoring Problem Space - A Recipe for Entrapment

One very common way to keep people endlessly (and sometimes meaninglessly too) busy is to be in an activity trap. In product development, it is predominantly reflected in feature factories where everyone is in a build trap. The virtue of starting with “why” or starting with meaningful problems of customers - is hardly unknown to those victims. But still, we see a lot of teams appease each other, using pseudo-scientific reasons behind favoring a different starting point and - in the worst case - not even passing through a convincing problem of their target customers.

Shiny Object Syndrome - not an excuse

In today's digital product landscape, technology helps us create solutions that are only possible now because a specific technology was not available previously. Earlier, we couldn't think of solving a problem in a specific manner as we can think now. Technologies leveraging AI and ML are good examples of such disruptive technologies. But some product teams who are over-enthusiastic about trending technology without customer empathy, sometimes tend to ignore the problem space in the excitement of the technology itself. This can be thought of as a form of shiny object syndrome (SOS). Framing the problem (or opportunity) should still be the first step for similar scenarios. If we can find more than one such problem, the very next thing should be prioritizing the "problem" (look, I am not talking about solution yet) to solve. The simple idea is - by all means, we want to focus on problems which our customers consider worth solving and not building from our own wish lists.

Discovering valuable solution

If we all agree to one or a set of problems worth solving, we must get it validated to the level that is qualitatively and statistically significant in the sense that at least, 6-7 customers consider it a pressing problem which they are eager to solve and are in principle, "ready to pay for it". It shouldn't be a mere personal guess of the most vocal person in the product team or a HiPPO (Highest Paid Person's Opinion). Our claim that we “value” something stands strong only if we are ready to pay for it. How many times have we rejected a “free” gift in a supermarket payment counter? May be never because it is free! But we often think over it and sometimes reject if we are asked to pay an additional price. So how do we know that we are heading towards a “valuable” solution? Product discovery is the answer.

Customers are weak in problem space

One common challenge in this process is that the customers are usually not very strong at staying in the problem space. They often slip into solution space and start suggesting or even demanding "solutions" which is not their job as customers. It is the job of the product management to sense the underlying problem and come up with the best possible solution. Discovery techniques leverage this fact by encouraging low-cost prototype creation at different stages that allows customers to have conversation in their “comfort zone” - the solution space. Although, a prototype is often an element of the solution space, it adds value to the understanding of the problem space also.

Knowing unknown problems as a by-product of discovery

Creating low-cost prototypes for the possible solutions to the highest priority problem is the next critical step. It is perfectly fine if the initial solutions fail. It is a prototype only! We have failed fast with richer insights about the "problem". There is a higher chance that we will address the problem in a better way in subsequent attempts or we may even frame the problem differently or shift our focus altogether to a different problem we discovered earlier. In the process of discovering a perfect solution, we sometimes end up discovering a different problem as a by-product - which is not wasteful at all.

Although, the finer level details of implementation of the discovery technique may vary to a large extent depending on the organization, the domain, customer base and several other factors, the most important principles remain unchanged. It all starts from the mindset of accepting what is unknown and embracing habits of systematically uncovering reality about our customers and their problems, and finally solving them in a way that works for our business too.

Visualizing vs. Verbalizing

While it is important first to know if a problem - we want to solve - is valid for our target customers too, it is essential to acknowledge that all the different ways to solve that problem are not equally acceptable. In the worst-case scenario, some of those may completely fail to address the problem and therefore could be useless to customers. Justifying a specific solution option solely by the existence of its underlying problem is another trap we must avoid. A simple habit of framing a problem by visualizing instead of only verbalizing reduces our chances of getting into this type of trap to a great extent. We must remember that specificity of the problem or opportunity is more important than having a very high-level superficial awareness of its existence only.

Feature benefit hypothesis

Although most of the aspects discussed before are humane and cultural by nature, there are some areas where tool usage can help in establishing the required context in a better way. For example, tools which encourage writing product features around a benefit hypothesis, connect the problem space more effectively. At the same time, it offers the team with the necessary latitude for considering multiple solution options that provide the same hypothesized benefit. After all, we don't want the product team to fall in love with a particular solution option too early. Rather, we want them to be obsessed over bringing the real benefit by solving real problems. Feature benefit hypothesis constantly reminds them of this critical trait.

Defining measurable business outcomes is both an art and science. It not only needs the best of intentions from the leadership and product team but also requires disciplined practice. Reluctance in problem space pushes the team further away from that discipline which in turn makes it quite impossible to attribute a positive or negative change (in business outcome) to any specific feature set we build. The simple reason is - if we are not very clear about which specific problem a feature is solving, how to even know if we are succeeding in it or not? As success becomes a figment of imagination, a vicious cycle of entrapment starts repeating itself.