The ‘Why’

Kid with toy shovel

As a product manager or a product leader dealing with the ‘why’, the ‘what’ and the ‘when’ is a big part of your job. I guess this is not news to you. 

As I see it – there is a hierarchy between those terms, where the ‘why’ is usually the most important, then the ‘what’ and last is the ‘when’. Of course, given a specific reality and set of conditions those may shuffle, but generally this hierarchy holds for most scenarios.

I claim that the ‘why’ is the most important from the 3 ‘w’-s since it encompasses both the pain and the value for remedying this pain. When designing a new feature or planning a new product there is no escape from addressing the ‘why’. And when the pain is properly identified or understood then the transition to the ‘what we need to build in order to fix the problem’ becomes rather natural.

The ‘when’ deals with the priority, and in many cases it’s rather technical.

Of course the ‘what’ and the ‘when’ can get messy and complex at times and may possess a challenge of their own. I’ll devote posts for those in the future, but today I’d like to focus on the ‘why’.

When drilling down into the ‘why’ I think it’d be beneficial to make a clear distinction between two cases. The first case is when we are adding new features to an existing product and the second is when we consider introducing a totally new product into the world. The latter is much more entrepreneurial in its nature and therefore much more complex. I’ll devote the next post to it.

Today let’s dive into the more straightforward case of ‘why’ we should add a feature to one of the products we’re responsible for.

Well… let’s admit it – in real life, and especially for product managers at the beginning of their journey – the ‘why’ is, very often, not a rocket science. If your customers keep asking you to add an ‘export to CSV’ function to your dashboard – then you probably just need to go and do it, right? You may stall on the ‘what’ part for a minute, to consider which columns to export, what range, etc…, but the ‘why’ is obvious – a lot of customers are asking for it, and hence there is a clear volume of demand.

However, very often, and probably more than you think, the ‘why’ is not so clear, especially, by the way, when customers ask for features.

Back then, when my partner and I were running Newsfusion, we dealt with news aggregation. It was mainly a B2C business, but from time to time B2B2C opportunities emerged, where other businesses reached out to us to see whether they can embed one of our feeds within their consumer facing product.

In one of those cases a business representative reached out to us and asked whether we can deliver news stories based on IP addresses. Specifically he wanted us to offer an API where we receive an IP address and return matching content as a result. It was a big business so we immediately looked into adding this feature. Turns out this feature was quite challenging to implement and it didn’t make sense to us to devote these resources just to build this feature.

Instead, we reached out to the prospect and simply asked him – ‘why’? Why do you need this feature? What problem are you trying to solve?

Long story short – turns out the prospect wanted to show content which is relevant to 5 countries they were operating in. Lucky for us – we already supported these countries and their languages and we actually had ZERO work to do.

That was a great lesson for life.

More often than you think – customers and other internal/external stakeholders will come to you with solutions. It’s your duty to deconstruct the solution and drill down to the pain hiding behind their ask.

I’m gonna be drawn a bit to cliches here, but I haven’t found a better quote then the one below which is 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 – most likely a sales or a business guy from your organization who just were on a call with the customer.

“Hey Nati, I just had a call with X. They really want us to offer an API when they inquire where their data is ready”.

At this point you have several options:

  1. You can proceed to the ‘what’, define the feature and hand it over to the R&D.
  2. You can document the request in some features requests backlog and forget about it for the time being
  3. You can try to understand why the customer is asking for this so dearly and try to uncover the pain they are attempting to resolve

 

What’s the right approach? Option 1 is almost NEVER the right thing to do, even if it’s a big customer.

Based on the prominence of the customer and the attention you can spare I’d either go for option 2 or 3, with option 3 being the clear preference.

So, if you can spare the attention, or if you are forced to do so by your boss, or reality (e.g. a risk of customer churn) then go and chat with the customer. Understand why they need it now.

If you are playing it right, possible outcomes may be:

  1. You understand the pain, and you discover that another feature planned for later this quarter, can actually address the same pain. For example – it’s already on the roadmap to offer a notification service the customer can subscribe to and be notified when the data they are interested in is ready and it can be also pushed to them. The customer is really fine with this solution and willing to wait for it.
  2. You understand the pain. You have several solutions in mind – all of them are simpler than the solution offered by the customer. You brainstorm it together with the customer and agree on one of them.
  3. You understand the pain and indeed the solution requested by the customer is the way to go. Now it’s just a matter of priorities.

 

If you could spare this time then you’ll probably discover that the customer is much more willing to work with you on a solution that works for both of you and they may even agree to a much more flexible timeline in terms of deliveries. It all goes back to how important is this customer or how representative this customer is for their segment. You won’t have the time to chat with each and every one, so be smart and sensitive to your time when managing this.

However, more often than not – you will discover that it was worth your time. You will notice that you have a much better understanding of your customers’ pain and you will have much more confidence in the features you choose to put on your roadmap.

You will also discover that you can consolidate & generalize features to serve a bigger segment of your customers. For example – one customer may ask you to segment their audience by geo, another customer will ask you to segment their audience by interests and another one by age. Ok… so it probably makes sense to offer an audience tool which offers custom segmentation based on several parameters, right? The engineering team would love you to come with this approach rather than coming to them each time asking them – ‘eh.. guys… can you also add a segmentation by age?’

I will wrap up with a technique I often use with customers (or other stakeholders I need to serve) for understanding 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 here:

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 cause. 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’.

With that in mind – I’ll close with this example:

I once went on a series of interviews with some digital publishers. They all threw solutions at me: “I need a personalized home page”, “I need to reduce the number of ads”, “I need the page to load faster” and more…

When drilled down to the root of their pain – they all asked for the same thing – they wanted to improve the engagement with their readers, and specifically the time readers are spending on their site. We were already working on some solutions for that, none which were mentioned by the customers. When we suggested it to them as an alternative approach – most of them were really happy to try it as the remedy.

So when considering new features – focus on the ‘why’ and the pain it addresses. Make sure you got it right before proceeding to the ‘what’ (the remedy).

On the next post we’ll cover the ‘why’ when inventing new products. Stay tuned as it’s gonna be exciting!

Related posts

A man is buttoning his suit

The CEOs You’ll be Working With

The previous posts were somewhat ‘heavy’ so today I’d like to have a shorter and lighter post. Hence, today we’ll be discussing the various types

Two robots sitting back to back

Asta La Vista Baby!

Maybe I’m late to the party, I don’t know, but it took me some time to process it. I gave it a lot of thought

An advanced robot leaning forward

Never Say Always

Ideals, principles and values People just love to hold on to them. I get it.  It gives us a sense of control over the chaotic