What do Product Managers and Toddlers Have in Common?

Besides being hard on the furniture, we both ask “Why?” every six seconds.  As a product manager (PM), the thing we really need to own is the “why” question.  While we really care about the “what” and the “how”, we need to focus on the “why”.

In any product organization, there is always more work that you would like to do than you can do.  Thus, we need to prioritize.  Traditionally, PM works on the stack rank and develops a roadmap.  We then work with engineering to bring that roadmap to fruition.

The problem, of course, is that everyone in the org has their own ideas about what you should do.  Thus, anything you propose is subject to question and debate.  As you get into the details of this discussion, it is easy to fall back to opinion-based debates.  You should build feature X because your boss wants you to build it or Sales wants you to build it.  Or Engineering has come up with an amazing new prototype that looks really nifty.

So, what should you do?

Well, you shouldn’t do any of those things.

You instead should ask why we are here?  What are our goals?  How do we achieve or not achieve those goals?

In short, you need to have the “why” question totally and completely nailed.

If you understand why you are building feature X, you are way ahead of the game.  Now when you get into a discussion with Engineering or Sales or senior leadership, you start off with “We are doing X because of Y.  We believe that this is the correct course of action because of Z.”

I cannot tell you how often people have presented information to me as fact when it’s actually just their opinion.  I’ve been told, “Customers want feature X,” for example, so many times that I simply cannot count them.  When presented with this type of information you can simply accept it as true or you can dig in.  I can assure you that many of these claims do not stand up to any sort of scrutiny.  

Example conversation I’ve actually had (details redacted to protect the guilty):

Senior Leader:  “We know that customers want us to do X”

Me:  “Sorry, how do we know that?”

SL:  “They’ve told us that.”

Me:  “Why do they want us to do that?”

SL:  “It doesn’t matter, we need to do it.”

Me:  “Sorry, but the details really matter if we are going to design this properly.  Can you point me to a couple of customers you’ve talked to about this?”

SL:  “Talk to person Z, they know all about this.”

Me:  “Hello Z, SL, told me to talk to you about X.”

Z:  “OK, you really need to build X.”

Me:  “Can you point me to a specific customer who wants X?  I need to talk to them directly.”

Z:  “Why do you need that?  I can tell you they want it.”

Me:  “Details matter; I need to gather requirements.”

Z:  “That seems like a waste of time. We know what they want.”

Me:  “I don’t.  Can you give me some pointers please?”

Z: “I’ll get back to you.”

Spoiler alert: They didn’t get back to me.  

The point isn’t to bitch about leadership or whatever.  The point is that even if someone really truly believes that you need to build something, it’s still up to PM to do our jobs and figure out what the customer needs.  To figure out the “why” question.  To get into the details about what happens if we don’t build it or if we build something else that solves the same problem.

I know that my tendency to ask “Why?” and to always go back to source data drives some of my colleagues crazy.  But I do it anyway.  Some have told me that it feels like I don’t trust them.  That’s unfortunate because that’s not my intent.  Just like the telephone game, information does not travel through organizations freely.  There is always some sort of loss of detail or incorrect reporting. It’s just human nature.  We are not perfect.  So, as a PM I want the source data whenever I can get it.  The closer I am to the customer, the more likely I will make the correct decision.

And here is the lesson: If you are a junior product manager, don’t take “no” for an answer.  Get the source data.  Talk to the customer directly.  Ask “Why?”  If you are prevented from doing this, go to your leadership.  Be polite, but firm.  You must have this to be successful.  If your leadership doesn’t agree, you might not be in a healthy product organization.