Using product thinking, we will always start with the problem and work through questions to understand for whom it is for, why it’s important, how we will build it, and when it needs to be built for. Thus, the WWWWH framework. Let’s look at this in more detail.

What is the problem you are looking to solve?  

The problem should be looked at from a user perspective. For example, in a company whose primary objective is engagement, which is measured by time spent, the problem should not be simply be articulated as “the Web site is old and clunky” or “it needs an upgrade.” The problems here should be articulated as user issues and associated business issues: e.g. users drop out before the page fully loads, which means low enagagement. 

Next we move on to the audience: Who are you are solving the problem for? 

A problem could be generic for all users, such as the example above. Or it may be a more specific segment of users, e.g. rural readers engage far less than city dwellers. There should be data to back up any statements.  

Once we have defined the problem and the audience that will benefit, we ask: Why is this important for users? And why is this important for the business?  

Here the reference should be back to user data/comments and to company objectives. For example, research shows that by increasing page load speed by 10%, reader engagement increases by 5%. Thus illustrating a reader problem and how it matches a company objective.  

How we will build it?

Once you have determined the problem and how it relates to both the user and company goals, it’s time to start looking at solutions. Perhaps the answer seems straightforward, but be careful to look at it from multiple angles. This is where a multi-disciplinary team really shines. The “how” will eventually need a detailed spec, something we will go into more later in the initiative.  

When does this need to be launched? Is there an urgency/time sensitivity of the problem?  

An idea or user problem may be time sensitive as it relates to an event (e.g. elections or COVID coverage). It could also be tied to an internal timeline such as an upcoming marketing campaign. Or it may need to be weighed with other items on the product roadmap, in which case the next step needs to be developed before this one can be answered. 

Two useful formulas

Here are a couple of other simple articulations of this framework that can be used as good starting statements to share internally. 

The Interaction Design Foundation formula:  

• This product is for: (Your Audience).

• It will help them solve this problem: (The Problem).

• We will do this by: (The Strategy).

• We expect a working product to: (The Objective).

The Jeff Gothelf Formula:

We believe [this outcome] will be achieved if [these users] attain [a benefit] with [this solution/feature/idea].

This is an oversimplified solution of course. This gives us a one- or two-page overview. Most of the time a full review and spec would need to be developed before something can be built out.

Define the holistic perspective

Using these frameworks will help define features for users. These may be incredible in their own right and solve a specific problem. You’re using them? Excellent, give yourself a pat on the back. 

But nothing is ever that straightforward, right? 

In addition to designing for specific user needs, we need to think about how these fit in with the whole experience. If teams work in isolation to build features, it can lead to a fragmented product that doesn’t work together cohesively.

This image from Naren Katakam is a fantastic representation of this:

We need to be mindful not to get lost in specific user problems and solutions. We need to look at how it works with the entire product experience. And that is why we need oversight of products across the entire organisation. 

If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .