How We Got Here: Three Decades of Product Management's Identity Crisis

I entered the product management world in the late 1990s, just as the dot-com bubble was reaching its most ridiculous peak. Companies were burning through venture capital at a pace that made rational people queasy, and the prevailing wisdom was that if you moved fast enough, wrote enough documentation, and had a sufficiently impressive roadmap binder, something useful would emerge on the other side.

It didn't always work that way. But it was a hell of an education.

The craft of product management has changed enormously since then, some of it for the better, some of it into genuinely strange territory. And because I've watched the whole arc play out from the inside, I have some thoughts.

The Document Era - When Paper Was Power

When I started, product management was, mostly, a documentation exercise. Market requirements documents. Product requirements documents. Feature specification sheets that ran to thirty, forty, sixty pages. There was a certain comfort in the weight of the thing. A thick MRD said, "we have thought about this very carefully." Whether that was true was another matter entirely.

The waterfall methodology ruled the land. You gathered requirements, you handed them to engineering, engineering went dark for six to nine months, and then something emerged, sometimes resembling what you asked for, sometimes not. The feedback loop was brutal. By the time the product hit the market, the window you were building for had often already shifted.

The dot-com crash clarified a few things in a hurry. Companies that survived got lean, fast. The long-form document as a proxy for strategy started to look a lot less defensible when you were watching cash burn against a development cycle that wouldn't yield a shippable product for the better part of a year.

Agile Arrives, and the Chaos Begins

The Agile Manifesto landed in 2001, and for product management, the implications took a few years to fully ripple through. When they did, it reshuffled everything.

The shift from product manager to "product owner" was, in theory, a clarification of role. In practice, it became a source of genuine confusion that the industry still hasn't fully resolved. A product owner, in the "Scrum" framing, is a role within a delivery team, writing user stories, grooming the backlog, clearing impediments. That's real and valuable work. But it is not, by itself, product management.

"A product owner manages a backlog. A product manager manages a business. Those are not the same job, even when the same person is doing both."

The rise of user stories was one of the more genuinely useful shifts of that era. "As a [user], I want to [do something], so that [value is delivered]" forced a level of empathy into requirements that the old MRD format rarely achieved. When written well, user stories kept the team anchored to the actual human on the other end of the product. When written badly, they became a cargo cult, the right format, zero substance.

Scrum ceremonies multiplied. Daily standups, sprint planning, retrospectives, backlog refinement. Product managers found themselves either deeply embedded in the delivery process or squeezed out of it, depending on how the organization chose to implement the framework. Neither extreme was particularly healthy.

The Standardization Wave - When 'Process' Became Product

Here's where things start to get a little squiffy.

As agile matured, the consulting world moved in. Scaled Agile Framework, SAFe, appeared in the early 2010s and gave large enterprises a way to apply agile thinking at scale, whilst letting senior execs still think they have visibility. Whether it actually delivered on that promise is a matter of vigorous debate. What it unquestionably delivered was complexity, layers of roles, ceremonies, and artifacts that made some organizations feel like they were doing the thing while quietly avoiding the actual transformation agile was supposed to create.

Rally (now Broadcom's Rally Software) built a product management and agile planning tool around these scaled workflows. Useful in places, genuinely capable of becoming a bureaucratic weight in others.

And then there's McKinsey. Look, I have nothing against management consultants in principle (ok, that's a lie 😳), but McKinsey's agile transformation playbook is a masterclass in taking a philosophy built around simplicity and wrapping it in enough layers of strategic framework that it becomes unrecognizable. Their "agile organization" model adds governance layers, centers of excellence, and talent architecture diagrams that would make the original authors of the Agile Manifesto put their heads through a wall.

The irony is thick: a movement born from frustration with over-engineered processes became, in the hands of large consultancies, another over-engineered process.

Product Management Finds the Classroom

Somewhere along the way, product management became a credentialed profession. Elite MBA programs at schools like Kellogg, Stanford GSB, and Haas now include dedicated product management tracks. There are certificates, bootcamps, and three-month intensive programs promising to turn motivated applicants into product managers.

I want to be careful here, because I don't think education is the problem. Frameworks, economics, market analysis, organizational behavior - these are real skills and learning them formally is not a waste of time.

But here's what the classroom struggles to replicate: the battle scars.

Product management is learned primarily through getting things wrong in real situations with real stakes. The MBA curriculum can teach you how to write a business case. It cannot teach you what it feels like to be in a room when engineering tells you the thing you promised sales won't ship for another quarter. It cannot teach you how to hold your ground when a VP has a pet feature they want prioritized over the thing your customers have been screaming for. It cannot teach you the specific, ugly art of making a call with incomplete data and living with the consequences.

"The MBA teaches you the vocabulary of product management. Experience teaches you the language."

I've interviewed many MBA grads for product roles over the years. The smart ones know what they don't know and come in hungry to learn it. The ones who struggle are the ones who believe the framework is the job.

What You Bring Into the Room

This is what I care about most.

The prior experience a person brings to their first product management role matters enormously, and not in the way most job descriptions acknowledge. Most postings want "X years of product management experience," a circular requirement that misses the point entirely.

What I've watched work: engineers who learned to ask why, not just how. Sales people who got frustrated with products that didn't match what customers needed. Consultants who got tired of giving advice and wanted to own the outcome. Technical writers who started asking uncomfortable questions about the features they were documenting. Field service people who saw firsthand how products failed in the real world.

These folks arrive with something that can't be taught in a classroom and can't be installed via a Jira plugin. They arrive with domain credibility, with pattern recognition built from direct exposure to the problem space, and with the interpersonal muscle memories that come from navigating organizations under pressure.

I came up through semiconductor capital equipment. When I joined the ranks of product management, I already understood the physics, I had spent time in the customer's manufacturing environment, the language of yield and throughput and cost of ownership were part of my vernacular. That foundation meant I could have conversations with customers, engineers, and sales that were grounded in shared reality. That's not a minor advantage. That's the whole game.

When someone walks in from outside the domain, with only a framework and a certification, they are starting from a significant deficit. Not an insurmountable one, but a real one. The best thing they can do is acknowledge it, find people who know what they don't, and spend the first year asking more questions than they answer.

What Hasn't Changed

For all the evolution in methodology, tooling, and credentialing, the fundamentals of this job have not moved.

You must understand the business. You have to understand the customer. You have to synthesize both into a direction that makes sense, and then you have to persuade a roomful of smart, skeptical people to go that direction with you. The process for organizing that work has been refined, often improved, and sometimes dramatically overcomplicated. But the work itself, the actual thinking and persuading and judging and deciding, that has always looked the same.

The frameworks come and go. The tools evolve. The certifications pile up.

The craft, the real craft, is still built the same way it always was. Slowly, through exposure, failure, and honest self-assessment.

That hasn't changed since I walked into my first product review meeting in 1998 with a binder full of MRDs and absolutely no idea what I was doing.

What a long strange trip it's been. Time to listen to some Grateful Dead me thinks.

Drop a comment below or reach out if this resonates, or if you think I've got it wrong.