Below Water Level

What You Will Learn in this Post
Defining the problem before moving to solve it, amplifies the impact of all activities in the product lifecycle.

Not defining a problem compounds the friction and misalignment with every step.

More than a decade has passed since I had the following conversation with a manager, but recalling it still makes me feel cringey about my behaviour.

Me: We need a new server.
Manager: Why?
Me: The web app is not responding fast enough.
Manager: How do you know a new server will help?
Me: :~{ Stumped !!!

I did not know what problem I was trying to fix. It was a profound lesson then, that is totally worth the memory of the pain of learning almost two decades later.

Clarity and Value

A problem is the origin of all value. Clarity about value emerges from defining the problem. Once a problem is clear, this clarity is amplified by the subsequent steps in the product definition cycle. The reverse is also true. Without a problem definition, the friction and breakdown compounds as one proceeds further down the product development and launch lifecycle.

Here is how this works.

The Range of Clarities

Clarity #1: What to Build

When a problem is clearly defined, teams are able to figure out the exact points of intervention. They can create or violate constraints. Teams can gauge the complexity they need to address. Interactions with other systems and impact on other systems can be understood. With the problem in hand, it becomes easy to determine the change we want to bring about, what gaps we need to plug and what the end state should look like.

Those are serious benefits right there, even without considering all the downstream factors, which I discuss below.

Clarity #2: Value to Customer

A clear problem definition helps everyone in the company understand the customer struggle that will be overcome. Only with clarity about customer problem can one see the value that the customer will derive from any solution to the problem. Absent a problem definition, it is hard to see why any solution would resonate or appear attractive to the customer.

Clarity #3: Customer Archetype

Many times when we get into solutions-mode, we get too excited by our ideas and technicalities. Even when problems are known, we overlook who faces those problems. At other times, we talk about customers in the abstract, as “users”, “clients”, etc. In the excitement of the solution, we even forget that the solution is in service to a real human.

A good problem definition forces one to consider not just the struggle but who faces it, whose life will change if we address the problem. Knowing who we are solving for can drastically change the definition of the problem.

Clarity #4: Value for Business

A problem clarifies who the customer is and what value they derive. Understanding about customer value creates visibility about the value for the business. If you know how much value the customer will get, you could use that information to determine whether and how much to charge.

If the problem definition itself is not clear or has not been communicated, people within and outside the team will struggle to understand why the company should be investing precious time in a project.

Clarity #5: Sales Enablement

Clarity the customer segment enables the GTM functions to determine their sales and marketing plan. Who will we sell to first, who next? What signals of pain should we be looking for in qualification conversations? How much time should sales invest at different levels of pain?

A good problem definition along with the customer definition helps sales understand who not to sell to.

Sales is able to understand the customer organizational dynamics that will come into play with the problem. Why will any one buy? Who will make the buy decision? Who will be the influencers in a solution for the defined problem? Where will the budget come from to pay for the solution?

Clarity #6: Budget

Once you understand the value of the problem for the business, it helps inform how much time and money we should invest in solving this problem.

Clarity #7: Timing

Many times a problem, even though very clearly articulated, is better left unsolved till some time in the future. Because of other priorities, competition for resources, market issues, a problem may be better off addressed later. However, such a discussion cannot even begin without a clear articulation of the problem and the value for the customer.

Clarity #8: Competition and Alternatives

Understanding of the problem helps gauge who else is solving that problem and to what extent.

Competitive evaluation is a place where almost everyone goes wrong. Product teams focus on solutions and then determine who else has similar solutions. The solution set ends up defining the competitive set, making it a head to head frontal assault, which usually drives down prices and leads to waste.

The trick is not to compare solutions but against problem definition: who else is solving this problem? How well or how badly? How is this problem currently solved by customers and what will be the switching cost? Why will any one buy when they already have an alternative in place?

Clarity #9: Internal Alignment

A successful product is the result of many different disciplines and functions coming together. Most of these functions and disciplines tend to be downstream consumers of the problem definition that takes place upstream or early on in the product development cycle.

The success of your stakeholders is crucial to your success. If they feel certain launches will impact their jobs and their success, the problem definition is crucial for them to grasp and align around. Developing champions among those functions and disciplines, getting support for launch, etc. depends on you and your stakeholders understanding the problem. For this, you need to connect the problem to: Who all will be impacted, How does this problem impact their goals, their lives, and how can we align the problems and solutions to their success as well?

Clarity #10: Strategy

Strategy is about making choices regarding the organization’s purpose, the product and problem scope, the structures and systems that will help achieve the purpose.

A problem definition helps clarify how the proposal fits into the overall landscape of the product. Does this problem fit into the strategy currently in play? Are we best suited to solving this problem? Is this going to lead expansion into a new segment or does it help plug gaps in the offering for the current core segment?

Clarity #11: Placement and Staffing

If the problem is clearly defined, it helps to determine which is the best team to solve this problem. Not knowing the problem, it is easy to fall into a trap of design- or engineering-driven placement of the work into a team.

Many times it so happens that the right team to place a problem is one that is far removed from how the problem shows up for the customer. Knowing the problem supports taking a systems-wide view and determining the best team and staffing needs to solve the problem.

Clarity #12: Gauging Success

A solution is in service of a problem and the problem is an obstacle in helping achieve an outcome. Knowing the problem helps define what exact outcome would be achieved. It helps cross-validate whether the outcome or KPI is influenced at all by the problem and solution being considered.

Clarity #13: Solution Coherence

Knowledge of the problem makes it possible to articulate the attributes and factors that will make the solution coherent with the problem. Once a prototype has been designed, having a defined problem allows comparing whether the prototype solves the problem.

Comparing the prototype or the proposed solution against the problem helps understand to what extent the proposed solution helps overcome the defined problem. A problem helps teams to decide whether to invest more time or call it good enough now. The team could also use such problem-to-proposal comparisons to explore other possible solutions which could help move the needle further.

Clarity #14: Early Adopters

Having figured out the contours of the problem, its value and the customer archetype who will find it valuable to solve it, it becomes possible to canvass and recruit early adopters and in some cases even get them to sign up with a letter of intent or even a payment to fund the development.

End Note

Benefits of defining problems amplify as the team proceeds further down the product development lifecycle.

On the flip-side, a team that has not done problem definition proceeds down the development lifecycle, will find breakdowns, friction and conflict compounding each step of the way. As more and more of the aspects above come into spotlight, the team will find itself mired deeper and deeper into providing responses that feel like band-aids rather than well-considered, researched counters. They will find less and less support and enthusiasm from other teams and disciplines, whose own jobs and successes depended on first defining the problem.