Last weekend I had the pleasure of hanging out with my sister, her husband, and their three-year old son, Liam. Liam is inquisitive. Ridiculously inquisitive. Every other word out of the kid’s mouth is âwhy?â
In fact, if there existed a clinical condition for âhyper-inquisitivity,â he would be its poster child. Weâd all donate to his cause and enjoy the yearly tax write-offs.
Observing him got me thinking; specifically, I wondered: how can I apply his hyper-inquisitiveness to product management?
 âOk,â you ask, “What does a toddler have to do with being a Product Manager?”
Well, aside from the urge to frequently scream and throw tantrums, we share another striking similarity: as product managers, our primary job is to ask âwhy?â Like, all. The. Time.
And I donât mean in fluffy, existential ways, but in actual pragmatic terms. Asking âwhyâ is at the core of our craft. Active listening can reveal surprising depths of customer need, which are often masked by superficial feature requests that donât address their real desires. (People asking for things other than what they truly want is a whole post unto itself. Iâll spare you all for another day.)
Ok, let’s play pretend:
Scenario 1: your top sales director approaches you saying he needs this great new optimization feature implemented ASAP.
Your first inclination as a product manager should be to ask, “Why?” He tells you itâs so that he can sell against your biggest competitor, presumably because they already have this feature. Your next question: Why? Does he really need a parity feature, or is it perhaps a better understanding of your current platform for him to position it differently? Or, is the feature request a symptom of a larger need (e.g., a new âepic,â to borrow from agile-speak)? This is where asking âwhyâ must be an evergreen practice in our discipline. Sure, pose the question in fancy ways if you like (i.e.,âCan you please quantifiably articulate the justification for your request?”). But in the end weâre all just asking the same question: (yep) why.
Scenario 2: For an upcoming ad campaign, a marketer client tells you they want to target âFemales aged 25-44, HHI of $75k/yr+, with 1-2 children in the household, who are fitness enthusiasts and enjoy consuming fashion-related content online.â
The client has a performance goal of driving leads to the website, and through their own market research or intuition – or some combination of both – they have determined that this niche audience is the way to reach those objectives. Your task, then, is to construct a targeted demographic campaign to match those criteria, right? Wrong!
If youâre paying attention here, your instinctive response should be to ask “Why?” Why does the customer care how the campaign is targeted if their KPI is to drive traffic? Would not a better strategy be to run a few experiments and let the data reveal where the strongest performers lie? Asking âwhy’ in this scenario takes the PM from an order-taker to a critical thinker.
Finally, scenario 3 (the classic): your CEO says to you, âWe really need this capability sooner than later. When can I have it?â Your question back to her? You guessed it: Why?
Now donât get me wrong, there are often sound justifications to a C-level’s request: fixing a bug, adding a new widget, the current UI looks like shit and thereâs a client demo coming up, theyâre paying your salary so youâd better just do it (ok, that one isnât soundâŚbut c’mon, we all think it). However, for the vast majority of executives’ requests, there are some recurring themes Iâve identifed over the years: fear (âSomeone else has it!”), pride/vanity (“I want to be able to say we have it.â [see also fear]), and, letâs just call it “sales optimism.â Teasing out the vanity- vs. value-requests is the key to doing your job well. You could also characterize this as finding the signal among the noise. Chaff from the wheat. However you want to characterize it is fine. The point is, donât take feature requests as orders.
After all, Product Management boils down to economics: the continuous assessment of wants (yours, your customers’, the market’s) against limited constraints (engineering capacity & time). If you have good quant at your fingertips – projected cost savings, potential revenue gain, improved KPIs  – well then, lucky you. Hard numbers make prioritization considerably easier – and upwardly defensible – and we should strive to obtain them before making any product decisions, big or small.
However, rarely do those beautiful metrics fall into our laps with a nice red bow on top. Typically we must do our homework and analyze the potential costs & benefits, which any good PM knows takes time. But, before you spend all that precious time and energy researching things that may or may not be worth it, simply ask yourself and the requester, âWhy?â In fact, ask a few times. It won’t hurt.
Then resist the urge to be an order taker. Be like Liam. Ask why.
Mega meta 