The Most Important Question in Product Management

The Most Important Question in Product Management

Every time someone from outside my IT bubble asks me what I do at work, I explain that I define the what. It is ultimately up to me which initiative a team will work on at which point in time, and what exactly falls into the initiative’s scope.

As a Product Manager, I am not necessarily responsible for the how — the technologies and process, or the who, even if more often than not I do have strong opinions on these matters.

So, I am the what, but this by far isn’t the most popular question I use at work. Enough with the suspense — my basic tool, the question I repeat relentlessly and without shame, which I believe to be crucial to a product’s success — is why.

Why should we do it?
Why are you asking for it?
Why are we even discussing it?
Why is it more important than other things?
Why do you think it solves the problem?
Why now?
Why this team?
Why do you believe that?

This question makes sense in more context than just Product, obviously. In engineering, I am a big fan of the “five whys” method used, for instance, in incident reports. You ask the same question many times to finally reach the root cause of an issue. In Product the “root cause” is a little different — we ask “why” to to get to the underlying need, hidden behind proposed solutions and prematurely defined requirements. If we understand the why — the problem we are solving for — we could perhaps develop a better solution: cheaper, more aligned with our strategy, maybe already existing.

Here is an example (imaginary) conversation around 5 whys for engineers:

Issue: We missed out SLA this month.
1st why? Because the cluster stopped responding.
2nd why? Because the database was unable to deal with the surge in traffic.
3rd why? Because we did not invest in scaling.
4th why? Because 2 months ago we were dealing with 10x smaller traffic and never thought it would change so quickly. All performance tests were green.
5th why? We did not align with Marketing who ran a new ad campaign and had predictions about traffic changes.
Solution: Invest in scaling, starting with circuit breakers on the database. Introduce monthly syncs with marketing.

And here is one (less imaginary) for Product:

Issue: CTO wants to know if we are planning to introduce the complex page sources search to our page.
Why do it? Because it is offered by one of the partners we are integrating with.
Why are they doing it? Because they believe it helps retain users, and users mean money.
Does this really retain users? Well, let’s check how many people are actually using it -> 0.001 of users are familiar with this feature
What is the cost of losing these users vs cost of developing the feature? The cost of development vs the loss of this cohort of users over a 2-year-long timeframe is $-30000.
Solution: Don’t do it.

A good practice I am trying to introduce any time I have influence over other Product Managers is this: make sure every higher-level backlog item contains information about the “why”. What problem are we trying to solve? Who is requesting it? What is the incentive?

I want to end this argument with a warning. “Why” is a charged question that can put a lot of people in their defense mode if there isn’t enough trust between you or if they lack self-awareness. Can you really talk to stakeholders like that? When in doubt, I choose the oversharing route. I explain my way of thinking and the reasons for asking: limited resources, the need to potentially remove other goals, the desire to serve their goals better.

It is usually fine.

Then again, you don’t work in Product when you need everyone to like you.