The ‘Why’

A product manager seated on the word 'why'

When people ask me what product managers do, I tell them that product managers are responsible for the three W’s: 

  • The ‘why’
  • The ‘what’
  • And the ‘When’

In simple terms, it means that:

  • Product managers decide what the developers should work on.
  • They explain why it should be worked on.
  • They determine when it should be worked on, after considering all other options.

I believe many veteran product managers will agree that the ‘why’ is the most important of the three. I definitely support this view. The reason is that the ‘why’ encompasses both the pain and the value. If you truly understand why a feature or product needs to be built, it means you have uncovered a real pain and know how your customers’ lives will improve when you solve it.

And solving the real pains of your customers or users is, of course, your ultimate goal.

You may argue that the ‘what’ is equally important. This refers to the actual solution you decide to build to address the pain. While the chosen solution is certainly important, you will soon discover in your career that there is more than one way to solve a problem. In other words, there could be several solutions to each pain, and many of them will work just fine. 

However, your customer may have several pains, but those are rarely equally important. Identifying and addressing the right pains may make or break your product.

If you find a remedy for small pain, it will probably not be enough to make your product a must-have for your customers or users, and your product will be perceived merely as a ‘nice-to-have’.

Hence, identifying the right pains is the key for building great and successful products.

Only then comes the phase where you think about the right solution to this pain, and as I noted above – on many occasions – there will be more than one possible solution, and the road for identifying it and building it is quite methodological and known.

And while there are known approaches for identifying pains & underserved needs, sometimes it can be more art than science. The reason for this is that very often the customer is not really capable of describing the pain, while they are quite good at describing the solution they want.

Example from real life:

When I ran my startup, Newsfusion, with my partner, we were in the business of producing news feeds for any topic and passion. At some point an opportunity knocked on our door with a tier-1 customer.

The customer told us that it’s crucial for them that we will be able to produce a news feed based on an IP address, so that a user from the UK will receive a news feed in English, and a user from Spain will receive a news feed in Spanish.

At the time we did support all the languages the customer wanted, but we didn’t have this specific capability. And while it’s not that complex to develop such a capability we didn’t think it’d be the right approach in this case.

Therefore, we went back to the customer and tried to understand what they are really trying to solve for. We simply asked them:

“What are you trying to solve with this capability you’ve been asking us about?”

And they replied:

“We want to make sure that each of our users, in any of the markets we operate in, will get the news in the language they speak when using your service.”

Ok. This is what we suspected. So then we replied:

“Ok, but relying on an IP address is not very reliable. Why don’t we show some dialog to the user the first time they launch the service and ask them what language they want? Would that be an acceptable solution?”

And the customer thought about it for a second and said ‘yes, that makes sense’.

This is just one example among many that I’ve seen in my career when customers and users tell you what they want instead of the problem that they are trying to solve.

Faster horses

I’m going to use a bit of a cliché here, but I haven’t found a better quote than the one credited to Henry Ford:

“If I had asked people what they wanted, they would have said faster horses.”

The takeaway here is that people are drawn to what they know and how they are used to solve problems. In the case of Henry Ford he understood that the pain here is that people wanted to travel much faster from A to B. This is the pain. Horse is a possible solution, but evidently not the best one.

The same will happen again and again in the course of your career and you need to develop the instinct to spot this early on.

It can be your customer, or someone speaking on their behalf – could be someone from one of the business teams, such as customer success, sales or support, who just got off a call with the customer.

“So listen, Nati” – they would tell me. “I just had a call with Bob from SuperBob.com . Regarding the analytics report in their dashboard – they would like to know if we could add a few columns there – mainly zip code and phone number”.

Now, at this point we have a couple of options:

  1. We can document the feature request and work on it when it fits in one of the sprints. OR
  2. We can try to understand why the customer is asking for this and try to uncover the pain they are attempting to resolve

What’s the right approach? 

It highly depends on the size of the feature and how it fits in the big picture. If the feature is small, doesn’t involve a lot of costs, straightforward and applicable to many customers – then don’t bother. Reaching out to customers and talking to them – can be very time consuming. Add it to your backlog and then it’s just a matter of prioritization (what we call – the ‘when’).

However, in the specific case above, it could be, and that happened to me in reality, that the dashboard of the company serves dozens of customers. 99% of them don’t need these two columns and it will just clutter their display. On the other hand – the customer who’s been asking for that was a strategic customer.

If you take this request to execution you are going to degrade the experience for many of your customers. If you ignore this request you’re going to anger an important customer. What should you do?

Exactly what we just discussed – you get on a call with that customer and ask them why they need these columns. Maybe you will be able to talk them out of it.

So in the case that happened to me I got on a call with the customer and they insisted it’s crucial to them and explained to me why. No matter what their reasoning was. What matters is that I got convinced they need it as well.

Understanding their pain, and understanding why it’s important left me with the understanding that they must have this data. However, does it mean they need to have it in the dashboard? 

After consulting with my data engineering team I came back to the customer and asked them if it’s ok if we’ll write their data with the custom columns to an S3 bucket that they can read from.

The customer was actually excited about that and told us that this is even a better solution.

So we managed to dodge this bullet and make the customer happy. There was also an added bonus – our infrastructure for exporting data via S3 bucket served many other customers later down the road.

 

Now this tale ended quite well, but it’s true that from time to time you will have to compromise and maybe even sacrifice some of your less important customers to make your more important customers happy. However, from my experience – those cases are quite rare as long as you don’t accept each feature request as a mission you must execute upon.

When a feature request is landing on your table that doesn’t resonate with you – your goal is to understand why it is there and what hides behind it. I call it ‘mastering the why’.

You’d be surprised how often, when drilling down to the underlying pain behind the offered solution, you can come up with better solutions which are usually applicable to a large number of customers and not only for the customer who was asking for this feature.

The 5 ‘whys’

I will wrap up with a technique I often use with customers (or other stakeholders I need to serve) to understand the underlying pain. The technique is called ‘The 5 whys’. I didn’t invent it. It’s used in several domains and not only for product management. There are plenty examples on the web and you can also read about it this Wikipedia entry:

https://en.wikipedia.org/wiki/Five_whys

But essentially it drills down to keep asking the customer ‘why’ in all different shapes and colors until you reach the root underlying pain. Of course, you’ll need practice on this a bit because you don’t want to sound like a nudging and annoying kid. There are plenty of ways to ask ‘why’.

 

That wraps up this post. Good luck with mastering the ‘why’!

 


If you liked this post – would you be kind to click on the ‘like’ button below? Also – while there – why not share it with someone who can benefit from it?

 

+3
Liked it? Why not share it?