Is Your Product Manager Hurting Platform Engineering?

Almost everyone in platform engineering agrees that you should treat the platform as a product and the developers as customers. Great platforms will be ones where real-world problems are gracefully solved rather than those that scratch an itch for the platform engineers.

The common advice that goes along with this knowledge is that you should put a product manager in place. However, a recent conversation in the CNCF community challenged this cookie-cutter guide to product management for platform teams.

When people say you need a product manager, they mean your team must have certain skills and product management tasks are getting done. For example, you need to keep the platform focused on its users and be able to assess whether features bring the intended benefits. You need to take the platform to teams in the organization and show them how it could help them.

You don’t need a product manager to achieve product focus; in some cases, it may be counterproductive to add one.

Think Like a Startup

Startups are usually formed around a small group of people who are deeply interested in solving a specific problem. Many technology startups are created when developers find something frustrating and develop a tool to solve the problem.

A great product emerges when these developers can extrapolate their specific first-hand experiences to build empathy with others who have unique problems with similar shapes. They don’t just solve their own specific use case; they can solve a whole category of use cases.

These are the engineers with a product mindset. They can combine direct practitioner knowledge with information from others to find innovative ways to improve work for many people.

This is how Octopus Deploy was created. In 2010, Paul Stovell was frustrated that deployments were so painful when so many other software delivery tasks had been automated. Why was build and test automation a solved problem while deployments were such a mess?

The key to turning this personal frustration into a commercial success was a product mindset.

Paul said, “Customer feedback is like oxygen. It fuels innovation in the product development process. You ship something, listen to the feedback, and ship something else because you have built a deeper understanding of the users’ unmet needs. If you let something get between developers and this essential feedback, it suffocates innovation.”

Having a product manager from day one can lower oxygen levels for your platform team. Feedback may be filtered, delayed or misunderstood, massively reducing its value and making good outcomes less likely.

Platform engineers should bathe in the full, grainy details of the feedback and use it to enrich their understanding of the tasks their customers are trying to complete — and where they are underserviced when completing those jobs. This helps the platform team create innovative solutions that may solve multiple unmet needs.

You don’t have to use the Jobs To Be Done (JTBD) framework here. The crucial detail is that by immersing yourself in the customer’s needs, you can come up with ideas that solve many pain points instead of falling into the feature-factory trap of solving problem after problem.

You need to understand the broad set of problems to develop an appropriately abstract solution.

This is a compelling reason to delay or even avoid adding a product manager.

What Happens at Scale?

While it’s tempting to think ahead to what happens when your platform has achieved total adoption, been spun into a subsidiary organization, and had a conference named after it, it’s worth understanding that scale is not why you’ll add a product manager.

The goal of a platform team should be to solve valuable problems at scale while scaling sublinearly themselves. That means getting more developers interested in adopting golden paths, not trying to create paths for every conceivable scenario.

When teams make choices based on wanting the support your platform offers, you scale without having to encompass new technology stacks. This is more desirable than trying to gain further adoption by supporting esoteric team choices.

If customer teams expand, your platform team shouldn’t have to.

There is an industry-wide problem of software managers thinking it’s their job to stop programmers from being distracted, so they can spend more time typing code. As a result, increasing numbers of software developers never speak to a user or customer. This has led to disconnected roadmaps that don’t add value to the products being developed.

If you need to scale your platform team, preserving direct communication between platform engineers and the platform’s users is vital. You may find that reorganizing into path-based teams can help you grow without losing touch with customers.

Value Non-Coding Contributions

When a software team gets busy, non-coding tasks gradually erode. The outcomes can range from misguided productivity initiatives to just different celebrations for different activities. For example, when a team completes a feature, there’s cake; but when someone gets valuable insight from a customer, there’s silence.

When a team gets “commit myopia,” they start banging out features that nobody wants. This problem is compounded when the organization celebrates the rate of added features, even if they’re of no value. Individual contributors are sensitive to the kinds of work the organization values and will optimize accordingly.

With platform teams, non-coding contributions must be celebrated just as hard as new features.

A product manager is a sticking plaster if the problem is the work isn’t valued.

Maintain User-Centricity and a Product Mindset

The 2023 Accelerate State of DevOps Report confirmed that user-centric teams outperform feature-driven teams. This is a building block to take straight into your platform engineering toolset. Teams that maintain high-bandwidth feedback from their internal developer platform’s users will spend more time working on valuable features.

There are circumstances where adding a product manager is the right call, but sometimes this will disempower the team and wreck outcomes.

Product management is needed. That doesn’t always require a product manager.

Steve Fenton is an Octonaut at Octopus Deploy, a DORA community guide and a six-time Microsoft MVP with more than two decades of experience in software delivery. He has written books on TypeScript (Apress, InfoQ), Octopus Deploy, and web operations….

Read more from Steve Fenton