Product, it's time we grow up
Considering the forced maturation of product management
(weary sigh) "They don't get it. Man...they just don't get it."
That might be the phrase of 2023 within the product management community. Exasperation has been a very common sentiment, especially in the tense annual planning cycle that's underway.
Between the difficult economic environment in tech over the last fifteen months, repeated mass layoffs, and the recent visible backlash against the product management function by Airbnb founder Brian Chesky, product management is in the hot seat.
As a function, product management is in a place similar to where design was in 2005. People know "it's a thing," but don't really understand it, and are asking the function to justify its existence.
Within the product community, there has been much debate about this. Is PM "out"? Are we really adding value? Or are we peddling snake oil, and our collective imposter syndrome is actually—gasp—right?
Let's take a breath, and a step back.
Many people in product management feel under attack. This is understandable: it feels like our professional identity is threatened. This triggers insecurity and defensiveness.
So, we push back. We say, "you know what? Maybe Brian Chesky is actually just bad at creating an empowered culture!" Or, "this is a bunch of panicked, short-sighted execs willing to sacrifice long-term value for short-term revenue." Or, truly exasperated, we fall back to old faithful: "they just don't get it."
Of course they don't get it. Most people, regardless of role, have neither seen nor experienced a strong, effective product culture. (This applies to most PMs, too.) Strong product company practices remain unevenly distributed within the tech sector, and are barely starting to spread outside tech as software continues to 'eat the world.' There is a contingent of coaches, consultants, and advisors (myself included) working to spread strong product company culture and practices, but it takes time.
To be fair, there absolutely are PMs out there doing all the right things. And there are many more who have read the books, tried everything they can imagine, and now feel stuck in and unable to change a disempowered environment that is very far from what all of us pundits say product management "should" look like.
Most of us in product are somewhere in between these extremes: we've tried some things that didn't help much, and now believe the problem is in our working environment.
When we do this, we are doing exactly what we are accused of: avoiding accountability. By displacing the fault onto our environment, we are not taking responsibility for our contribution to the situation.
Product friends: we have met the enemy, and it is us.
We need to at least consider the possibility that we are the ones who don't get it. We need to take a hard look in the mirror and consider if there is truth in the critiques of product management.
I define "empowerment" as bounded autonomy: we get autonomy to define solutions, within guardrails, in return for being accountable to driving business impact.
For at least the four years since Josh Seiden published "Outcomes Over Output," we've chanted the title as a sacred mantra. We remind each other to be customer-obsessed, vigorously nodding our heads while slapping each other on the back for how outcome-oriented we are. Look at the focus in these OKRs! See how well aligned these product outcomes are to the business! We can certify that we've now 'empowered' all the agile teams, rejoice!
Well, congrats: our cross-functional peers have heard us. Now they'd like to see the results of all those outcomes we've been going on about.
We've been talking about empowerment for years, but now that the accountability comes around...we don't like it so much.
It seems like we want all the freedom and none of the responsibility.
Management teams are asking legitimate, responsible questions about the value-add of product management. And we are not handling it well.
We react defensively when asked to justify the ROI on the product work. We get flushed and anxious when we're asked to commit to driving revenue. We stammer that we cannot possibly tell you exactly what conversion lift product can drive next year!
The problem is not that they don't get it, or that everyone else is short-sighted.
The problem is not the impossibility of predicting the future.
The problem is our immaturity as a discipline.
You know who's really outcomes-driven, and probably the best example of "outcomes over output"?
Sales doesn't know exactly who will buy or how much, and yet they have to commit to driving revenue and to making forecasts—despite those forecasts being uncomfortable, difficult, and needing ongoing revision.
We must do the same in product.
We cannot have it both ways.
Either we are leaders accountable for using the resources entrusted to us to drive business impact through the product, or we should shut up and accept being told what to build. That's it.
Delivering value—to the customer, and to the business—is the job, full stop.
If our colleagues and management are not perceiving value in the product management function, then either (a) we are ineffective at communicating the value we are creating, or (b) we are not actually creating much value.
Neither is acceptable.
How did we get here?
As a discipline, product management exploded in popularity over the last 5-10 years. This went into overdrive with the boom—and subsequent overstaffing—of PMs in software companies during the pandemic.
This expansion was driven by economic tailwinds that enabled a lot of exploratory investment in the product management field. Buoyed by a zero-interest rate environment and abundant funding, companies were willing to invest in many drivers of possible upside, including product management.
This was good. Our discipline needed time for development, incubation, and growth. This also means that right now, product management as a discipline is still relatively immature and the vast majority of practitioners are inexperienced. Collectively, our field is a bit like a teenager: it shows great potential, and sometimes amazes us, yet struggles to establish its own identity and be taken seriously.
Unlike design or engineering, the product management discipline currently lacks formal education and certification pipelines, and is primarily learned through apprenticeship. Many PMs were simply retitled from product owner, project manager, or business analyst as part of a digital/agile transformation, and had no chance to apprentice with experienced PM leaders and practitioners. Further, there is no industry-standard certification that actually ensures baseline competency for anyone with the title “product manager1.”
Together, these factors create two results. First, rather than adaptively working from principles, many product managers are overly dependent on repeating scripted processes and applying basic templates. Second, there is enormous variance in the skill levels of “product managers” and so the field is very inconsistent in the quality of the experience provided to our collaborators. Industry-wide, “product management” as a brand is very inconsistent in delivering its brand promise.
Battlefield promotion time, everyone. We gotta grow up, and fast. If the last fifteen months have shown us anything, it's that product management is out of the incubator and is being forced to mature.
Product must now be accountable for its impact, just like every other function. We must now commit to driving no-bullshit business results like revenue, growth, or market share. We have to clearly map out how the things we're driving toward (i.e. "product outcomes") are actually also driving the desired business impact.
The best product people were already doing this anyway. Now, this level of accountability is becoming table stakes.
Why doesn't this happen to design or engineering?
Both design and engineering are now considered non-negotiable means of production. Execs from other functions know that they can't do this work themselves.
In tech-powered product companies, the product management function—as Marty Cagan has long explained—is responsible for ensuring the customer value and business viability of what we make. But here’s the thing: historically, value and viability were handled by other functions. For example, in CPG companies such as Procter & Gamble, product development was led by brand managers within the marketing department2.
What we call "the right way" has not been around very long, and is mostly constrained to the tech sector. This is why the "tech as IT" mindset is one of the key issues to overcome when a traditional business wants to transform itself into a strong tech product company.
Given all this, it's understandable why people who have not spent their entire career around tech products might be confused about why there is, or should be, a separate product management function. They're not crazy or stupid.
What do we do about it?
I hope to unpack these in future posts, but broadly, we have to do three things:
Adjust our attitude
Ensure we're actually creating value
Communicate more effectively
(1) Adjust our attitude
I'm just gonna say it: we need to stop whining and grow up. If we want a seat at the big table, we need to act like we belong there.
Avoiding accountability for the results of our work, or lack thereof, is exactly the opposite of what is needed. Each and every part of the company has a role to play and a contribution to the present situation, and needs to drive results. Product is no exception.
(2) Ensure we're actually creating value
Is our work as valuable as we claim it is? We are very biased here due to the endowment effect.
We must be rigorous, most of all with ourselves. We have to do our homework to clearly establish the link between the product outcomes we are driving, and what the business needs. We need to be able to explain our business impact, even if there are other factors affecting it (e.g. lead quality, traffic volume).
If we cannot connect the dots and show how the product levers we've chosen to focus on measurably drive what the business needs, then we are probably focused on the wrong levers. This is essential going into any planning cycle.
If we are going into annual planning or forecasting, then we need to be prepared with a range of outcomes based on the levers we believe we can move, and based on a strategy. Refusing to collaborate and claiming that "we can't possibly predict the upside of these features" will only make things worse and undermine our credibility.
(3) Communicate more effectively
If we've done the previous steps, what remains is a challenge in communication and perception. Value is subjective, in the eye of the beholder.
We should now be able to give anyone in the company a simple, clear explanation of what we're doing, why, how it is driving the business, and how it might affect them. This helps enormously with the "what are they working on all day?" questions that inevitably come up in other teams.
And remember attitude: we must willingly, proactively give these explanations! Not begrudgingly or only when prompted.
Secondly, we must alter our language. We love our jargon. But even if they understand, nobody outside product management cares about our jargon. PMs are translators3, and so we need to speak the language of business: revenue, ROI, payback periods, due diligence, etc.
Product friends, it's time we grow up, step up, and show up.
Let's get to work.
Thanks to Alan Albert, Nacho Bassino, Randy Silver, Christoph Steinlehner, MJ Jastrebski, Jenne Pierce, Rich Mironov, Kristin Darrow, Andrea Michalek, Avid Boustani, David Wegbreit, and Greg Skotzko for discussion, suggestions, and/or reading drafts.
An extreme counterexample would be a doctor, registered nurse, or pilot. While there is certainly variance in the quality of e.g. doctors, when you get sick you have faith that any MD you see, globally, is at least competent. There are still outlier, amazing doctors, but the variance in quality distribution is much tighter.
Can you imagine how annoying it would be if you traveled somewhere you didn't speak the language, hired a translator to help you achieve a key project, and they wouldn't speak in a language you understand?