Product Management Is a LARP - 6 minutes read




Please support this and future similarly honest observations from an insider’s perspective about tech by minting an NFT above.

Much of the role of Product Management has become a LARP (live action role play). This is an argument not to restore the role, but to let it recede so organizations can evolve.

Product Management is over. The role that it used to be has died. In its place is a golum, whose hopes are ensnared by something that it can never have, who is always hiding in the dark and afraid of power.

It used to be that Product Management was needed to connect the business to the technology. Neither side understood the other, being completely different worlds operating in different ways and concerned with different things. The business side of tech operated like business had always done — taking a product and trying to sell it for more than it cost to build, assuming that competition is nearby with a relatively indistinguishable product. The tech side, while still new with a child-like promise of a glorious future malleable in any which way, had its roots in research departments of grand universities. If the socks-and-sandals toting caricature of senior engineers flashes some truth, it is of a world that proudly decries reality. Technology was the prime objective, customers and revenue be damned.

Enter, the “product guy”. That rare unicorn who understood capital-P Product. Someone who could be buddies with Sales, join the customer dinners both as the exotic creature from a foreign land put on display by Sales and also as the spy sent in by the techies to validate Sales' claims. Someone who could do all this without stealing the limelight from either the customer or the VP of Sales. The PM would also join engineering reviews and provide input on architecture choices based on how they expected the world to look a few years from now, talk about capital-S Strategy that they had heard from the execs, and understand what customers actually wanted despite whatever Sales said. They would pull weight on what Engineering’s priorities should be. The PM had built the trust of Engineering by understanding technology, may have even written code earlier in life, would always get lunch with them and share in their nerdy jokes. Entrusted with powers that behoove a general while being in the trenches, the PM was also the person the founder-CEO would call upon to hear harsh truths about ground reality in calendar invites innocuously titled "quick catch-up", and have their trust in making subjective but well-rounded judgement calls.

Product Managers would come to be colloquially be addressed simply as "Product" as if the corporeal form of the spirit of everything the organization was trying to build.

But times have changed and the ground has shifted. As they often do. Sometimes from beneath your feet.

The "business" side of the house are of a generation no stranger to tech. They grew up surrounded by computers and the internet and have varying degrees of comfort with its innards. They have read Stratechery and know how tech innovation drives business strategy. They can talk to engineers directly. Engineers too consider themselves "product-minded" and dream of building something people want. This is unequivocally a good thing. But it does means that product management has a weaker product-market fit (if you will) for what it does.

Organizations have changed too. They are set up in a functional heirarchy, with each function being represented at every stage. Committees all the way down. Since every function must be equal in importance, each team is led not by one person but by a '3-legged stool' (sometimes 4 or 5) where each leg is the respective functional lead on the team. If you've heard the acronym EPD, you know what I'm talking about. Product is just one of the legs on this stool, with only influence and no authority. Decisions are meant to be collaborative but if that group is at an impasse, it calls for a grudging escalation. Grudging because escalations make it harder to sweep implicit power structures under the rug. Grudging also because why couldn’t the PM leverage their influence-without-authority to get everyone to agree.

The Product Manager continues carrying out their duties in this new world — writing PRDs, filing JIRA tickets, joining the sales calls and the engineering sprint planning. But engineers are invited to the sales calls as well, and sales are invited to the engineering roadmap brainstorms for cross-pollination and to let each function see and speak for themselves. Capital-P Product is now the EPD hydra (sometimes including an R or a DS or a PMM). It is a body that collectively takes credit for success and, more importantly, doesn't know how to assign blame for failure. If you've ever been at a "retro", it is an art form in converting individual failures into sweet smelling aerosol dissipated into the air.

The mechanics of the PM role are better understood than ever before, but the true value add is less clear than ever before. The Cambrian explosion of PM Twitter thought-leadership threads and PM bootcamps get at the former, but not the latter. Not to mention that it is near impossible to define or instruct about product management without defining or instructing about the organization around it. Startups get off the ground as lean as possible, one of the founders playing head-of-product (laying down product strategy) and the early sales and engineers sitting right next to each other. Whoever has spare time that day puts on the PM hat to write product copy or do user support and or update project tracking spreadsheets or look at some metrics. Everyone talks to users as much as possible. That model can sustain incredibly well these days for a long while. At that point the company is simply too large and some exec who has seen product management at a larger company will argue for that role to be instituted. The title will say 'Product', but the role is really 'Organization whisperer' — someone who can align OKRs and can wordcel strategy docs and weekly updates to make the chaos legible to the execs.

It is a role that will continue to exist, but only because who else is around that is better utilized at herding the chaos? Product strategy by definition needs to be worked out at the top of the hierarchy (in spite of every IC PM claiming they “do strategy”). All other capital-P Product decisions are effectively decentralized at this point, across not just Engineering and Design and Research and Data Science, but often also Corporate Strategy, Chief of Staff, Policy, Product Specialists, Product Marketing, etc.

This is neither bad nor good. This is simply a natural evolution. We can do better, however — by building organizations that can solve for chaos instead of needing an entire function to create legibility into the chaos, by being clearer about lines of authority, and by not painting a product execution role in product strategy and product design colors. Operations and execution are too important to be left to unwilling caretakers.

Source: Mirror.xyz

Powered by NewsAPI.org