It Depends

The Only Constant in Product Management — Across Industries, Orgs, Products, and Teams

“It’s important to take deep breaths to calm yourself when you’re feeling overwhelmed at work!”  But what about if your job is spear fishing, and you’re holding your breath under water? Well, in that case, taking deep breaths while you’re working may be fatal.

Every question you have about product management or your current PM role has the same answer: 

It depends. 

In fact, it’s a bit of a trope in product management communities, even to the point of being a cliche.  But if it’s indeed cliche, that’s only because it’s true enough to bear repeating. 

“What is the best tool and format for a roadmap?”  It depends.  Who all cares about your roadmap?  What do they need to know about it and when?  Does your org have a standardized tool or template, or does everyone do something different?  What kind of product is it, and how does it relate to other products at your company?  

Anyone’s recommendation about how to roadmap is only as good as their context is similar to yours — and that assumes they’ve found the right answer for their own context, which is not a given!

In software, we don’t build the same thing twice, and I suspect that fact is at the root of the issue. In our code bases, we reuse anything that already exists and solves the problem well — classes, functions, and libraries.  In our user interfaces, we reuse styles, layouts, and interaction patterns.  And for entire software products, we only build a new product if we can’t best address our problem or opportunity by “buying” (i.e. acquiring an existing company’s product) or “borrowing” (i.e. hiring a vendor’s solution or partnering with another company to integrate with their existing offering). 

If we’re building something, it’s because it’s new and novel.  No one has built it before, let alone us ourselves. 

I imagine that industries like commercial air travel, residential construction, dentistry, and hospitality all suffer far less from this dynamic.  The same planes fly the same routes on the same schedule (ideally) over and over.  Construction standards and local building codes apply to every house in the neighborhood, and often the same floor plan is used for multiple houses in a subdivision.  Dental offices do the same procedures over and over for different patients throughout the week.  And hotels welcome new guests into the same rooms, night after night. I’m sure there are nuanced differences from day to day, but all of these industries and many others — which involve atoms rather than just bits — require a lot of repeating the same effort over and over.  So finding “the right way” to do any particular part of a job is probably much more realistic. 

But in software, where you never build the same thing twice, it’s hard to find enough similarity among situations to make any concrete tactical advice broadly useful.  

Not only do we never build the same thing twice, but in aggregate, we also make software products for virtually every industry and problem domain. And to complicate things further, we all have products at different stages of their life cycles, within companies of different ages and sizes. 

And then there’s the people we work with, literally none of whom are the same, arranged into various cross-functional teams and organizations — with different structures, functional roles, leaders, cultures, business models, and strategic objectives. 

We could go on and on, exploring all the various dimensions that make up the context that any given PM finds herself in on any given day. If we spent enough time, we could fill volumes with the various differences between one PM’s context — the industry, market, company, organization, product, and team — and that of any other PM. 

So every PM is on their own then?  I don’t think so.  But we need to be very careful what we expect PM advice to do for us. 

Any given source of advice for PMs — a book, a podcast, a blog, or YouTube channel — can’t be treated as a cohesive playbook.  We can’t just memorize all the plays and run them with our team.  We need to learn the component parts of each play and understand what makes it effective where it’s used.  Then, we need to start to build up our own playbook, for our own context, based on those underlying principles. And then be flexible enough to edit our playbook as our context evolves and our judgment improves. 

“The PM’s job is mainly talking to customers!”  But what about at a company that has a Product Ops function and a dedicated User Research team? 

“A PM needs to be technical enough to get in the weeds with engineers about tradeoffs!”  But what about in an org where Product is expected to focus entirely on problem definition and prioritization and engineers are comfortable working with Design to shape and execute on a solution? 

“PMs need to be data-driven and focused on driving metrics with A/B tests!”  But what about at a B2B SaaS startup with only 2 customers and a total of 6 users? 

Applying advice in your role, when it’s intended for a context very different from yours, will at best be unhelpful.  At worst, it will make you ineffective and make your colleagues miserable. 

It’s not the advice you need as a PM.  It’s the wisdom you develop over time — as you repeatedly take in advice, discern the principles that underpin it, and then try to apply those principles in your own context whenever and however you think they make the most sense.  The more you work through this cycle, the more you train your brain to recognize patterns and identify how best to operate in any given context and respond to each new challenging situation. 

Since we never build the same thing twice, and every context is different, figuring it out on the fly is the job.  Our work in Product is closer to playing Jazz Improvisation than classical music, so there’s no sheet music to master before we take the stage. You don’t need to memorize the “best” framework. You need to study a broad set of advice and resources, get reps applying what seems useful, ask for and listen to feedback, and then repeat — strengthening your own judgment over time. 

It always depends, and it’s your job to figure out what exactly it depends on.  It’s slow, and it’s hard.  But it’s the reality, and it can be really satisfying.  

Try to learn to enjoy it!