Technocratic Product Management

I am a grizzled veteran having first slung the Product Management bag over my shoulder in 1998, when I became a Product Marketing Manager for an Electron Microscope that was being designed and optimized for measuring photomasks, the “negatives” that print patterns on silicon wafers, that then are built to drive, well, everything in the modern world.

It was a simpler time back then. The internet was tiny, Google didn't exist, and to get on it required some technical savvy, a computer, a modem, and infinite patience.

When I began in product management, I learned to use pads of paper, to ask questions of customers, to reflect on what they told me, and to piece that feedback together to understand the market needs, and then, to define what to build.

All of this was very manual, and required a lot of phone calls, plane rides, and the creation of long documents that engineering would then interpret to build a product that would (hopefully) be successful.

Today, UX, designers, structured meetings to gather feedback (often sans Product Manager), and tons of specialized tools such as Figma, Miro, Aha!, Rally, Jira, and literally dozens more, replace the embodied product manager who synthesized the requirements from voice of the customer, market segmentation and research, and domain knowledge.

In many ways, the new world order is amazing. I would have killed to have a dedicated designer early in my career. It brings that much more to the table than letting the product manager and engineering to collaborate on the look and feel.

Likewise, the collaboration tools facilitate exercises that organically grow base of knowledge and increases the velocity of the development of products with a better chance of finding market fit.

The Compartmentalization of Product

I have had the good fortune to participate in several workshops in the recent past. These are for components of our products I am not directly responsible for, but since I have a lot of experience, and deep domain knowledge they are keen to have me in these sessions. Good, I guess.

What I have experienced is that there is a team that is composed of a product manager, a program manager (really strong project management), a designer, and a dedicated UX research person.

The team does a lot of pre-work, but instead of filling out the details, this pre-work is defining what will be uncovered, Miro boards to facilitate the interaction, and the flow.

The meetings are well attended, with stakeholders across multiple functional groups, and the UX Researcher plays the role of facilitator.

The tools are leveraged to keep the stakeholders engaged, and to encourage them to pitch in and contribute to the discussion, the framing, and ultimately to uncover unmet needs.

And boy, are there tools. Tools to whiteboard. Tools to prototype and test hypotheses. Tools to track and categorize stakeholder and subject matter experts.

Even with all these tools, with these standard processes, the driving definition of what a product will be has become somewhat “sanitized”. That is to say that the intelligence, the synthesis of knowledge, the packaging it into actionable concepts has been relegated to the toolset, requiring less insight by the product manager.

What is missing is that all these moving parts happen, and as best I can tell, the product manager is in listen mode, not contributing or guiding the discussion, nor asking clarifying questions, or even defining the envelope. Perhaps this is done out of band, either before or after the workshop, but it is strange to see the product manager utter no more than a handful of words in an hour or ninety minute workshop.

The Evolving Team

I first worked with a true UX designer in the early 2010’s. Prior to that, all my experience was that product management would sketch what they were thinking, and the development team would iterate with the product manager, slipping in actual user testing when possible, and it *usually* worked OK.

But now, we have a whole team dedicated UX Research. It is staffed with mostly fresh outs who actually got their degrees in usability research, and I gotta admit that they are impressive to work with. They are young, they are eager, and they are facile with the tools.

Likewise, we have dedicated people who are experts at usability testing. I would have KILLED to have access to this 10, 15 or more years ago. Back then, we built mockups and went on the road, lucky to get any actionable feedback.

There is also a willingness to staff a formal project manager (a PMP certified person) dedicated to the product manager and the product team. I have long dreamt about having this luxury, someone who can keep it all organized, moving on track, and handle all the day-to-day activities.

Nope, there is definitely a willingness to properly provision a product team for success.

What this can’t do

Still, all is not skittles and unicorns. These tools, coupled with the expanded team doesn’t make up for the knowledge, savvy, and experience of a true product manager. Like the LLM Chatbot AI tools, these staff members and their tool domain knowledge doesn’t substitute for intuition, connection to the domain, and the ability to synthesize disparate data into a strategy, a plan, and actionable designs.

That is the strength that a legacy product manager brings to the table. Someone who “gets” the market, the customers, the segments, the business. All the tools in the world can’t substitute for this knowledge of the market.

And make no mistake, product management at its core is still:

• Identify a problem that people have

• A problem they need to solve

• A problem that you have a novel solution for1

• A problem that they will actually pay to solve (see footnote #1)

• and a large enough segment of the market that will buy it

And that is not something that a set of tools, and discrete team members with specific skills, and the impetus of an executive’s vision to get to a marketable product.

Final Thoughts

Product Management has changed a lot in the 25 years I have been doing it. The maturity, the acceptance of the role, and the explosion of interest in it have all exceeded any expectations that I had when I was new to the role in 1998.

That said, there are still some things that can’t be bottled into a stand alone tool, processes run according to a script, and the output processed like Velveeta and handed to a development team to complete.

There is still intrinsic value in the role. Attempts to genericize it may work in some contexts, and I suspect that they will continue built tools, but at the end of the day, the product manager needs to be able to lead the discussion, and drive to successful solutions.

It might seem like I am dismissive of the changes, the new related roles, and the expansion of the basics, but I am not. What I do worry about is leaders jumping to the conclusion that they don’t need to spend an appropriate salary for a true product manager. Those roles and tools augment the wisdom and insight of a product manager, not replace it.

Don’t get me started on the threat of AI.