It's all about the Why!

While thinking about products, it is very easy to see them as a set of features or capabilities, thinking about continuously delivering new features and may forget the initial goal i.e. the customer problem or THE WHY.

As someone who is part of the development team that builds products, your perspective may be very different from that of the customer, You may claim you know in and out of the product features, and roadmap and can deliver great solutions and can keep pushing new features. The thinking may sometimes be biased by known information.

For the customer, it doesn’t matter about how many iterations of sprint effort or your knowledge of the product, the only thing that matters is the value that the customer gets out of the product & features.

Like one of my ex-manager used to say about a solution that doesn’t have a good problem statement (I am a big fan of this statement)

So what who cares, Why and What problem does it solve?

Focus on the customer

When we are asking ourselves about “Why and what problem does the feature solve” for the customer, the focus shifts to the customer. Sometimes you may end up with two approaches, one is solving a problem for the end customer and another solving a problem for the business, most of the problems that you solve for your customers contribute to the business.

ex: Happy customers translate to Happy Business.

The switch in focus on the customer enables the product team to be more focused on the problem they are solving compared to the solution. Generally, the amount of effort that goes into learning about the customer problem is way less than implementing the solution.

It is essential to build a culture to ask “Why” in every aspect of the product development lifecycle. Here are some ways to do so.

Encourage to define user stories with WHAT and WHY

As a <persona>, I want to <feature> so that <reason>.

Generally, in many user stories, you’ll notice we miss the “so that reason” and if we do so we are more focused on the WHAT and building solutions and forgetting the problem. Just adding persona/customer in the statement doesn’t make it customer-centered.

The below example is a very general story format I've seen, you’ll notice that it is very clearly instructing WHAT and missing the WHY.

“As a manager, I want to be able to approve my engineer timesheet”

Let's retry the same statement with a WHY

“As a manager, I want to be able to approve my engineer timesheet so that the engineer gets paid weekly for the time worked”

Here adding the additional WHY context will change your understanding of how the feature impacts the customers & as well create empathy for your customers.

Question on the problem

Before you start developing a roadmap, story, task, code, testing, releasing take a few minutes and ask yourself questions like

• Why are we building this?
• What problem does the new feature solve?
• Is this the problem that we should work?
• Is this the best way to solve this problem?
• What are other alternatives?
• Who exactly has this problem?
• Do we have any data about the problem?

Share more knowledge about the problem with everyone involved

Most often, we tend to share user behavior with the business stakeholders only, UX research is shared with the Product Manager or Product Owner. Having a common understanding is very critical to have the right feature to be delivered in less time, Sharing problem information across teams enables common understanding and importance/impact on the work they are doing will enable them to work on the right things.

In conclusion, having a good understanding of customers and thinking about customer problems enables you to focus on what matters most and brings high value to your product features i.e. It’s all about the WHY!