Platform Product Management Versus Platform Engineering

Just got back from the DevOps Enterprise Summit which as usual was one of the best conferences ever. Product and platform management were hot topics there, as they’ve been for the last few years.

Today I want to talk about platforms; in particular there’s been a bit of a flurry lately about “platform engineering.” To make sense of this I look to Team Topologies, which defines a “platform team” thus:

 The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned [e.g. customer and business-facing] teams to develop these underlying services…A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.

The critical point, which the Team Topologies authors agree with, is that platforms are products. Ok, what does this mean? Let’s turn to the work of the Silicon Valley Product Group’s Marty Cagan in EMPOWERED:

the product manager has a clear responsibility, which is to ensure that the solutions are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business). Together with a product designer who is responsible for ensuring the solution is usable, and a tech lead who is responsible for ensuring the solution is feasible. 

So what is the challenge with platform teams? The challenge is that currently, platform teams are emerging from old guard I&O organizations. What are they good at? Engineering, aka feasibility. What are they bad at? Everything else. Think about your typical infrastructure functional silo, vs. the product team ideal, in Cagan’s terms:

*see Expertise and the Shared Services Problem

So, this leads me to my thesis: “Platform engineering” is not the point, and not the right topic of focus. While engineering excellence will always be needed, it’s not the constraint. The real problem is managing platforms as products in the other three dimensions. (I’m not supportive of the argument that “engineering includes the other three.” It hasn’t, historically.)

But bringing a true product sensibility and discipline to platforms is not simple. Most large enterprises moving in this direction necessarily must start with their existing infrastructure & operations organization — this is not going to be a greenfield. There is little history in I&O of thinking in terms of product management, as the above table shows. At the most pragmatic level, where’s the talent? How do you make the business case that an area with no history of needing product or design skills now needs them? This requires senior level sponsorship and a flexible CFO, and in fact the platform success stories I’m hearing all have that common denominator: leadership that understands the need for product talent.

Even given the political and funding support, finding and incorporating the talent is hard. You can’t just take a random product manager and “parachute them in” to a group of functional specialists. They may be eaten alive. “I’m your new product manager, I don’t know your technical domain, but I’m here to help.” The play has to be more subtle. There are two major options:

• Enabling team
• Develop from within.

Enabling teams, in Team Topologies terms, are

composed of specialists in a given technical (or product) domain, and they help bridge this capability gap. Such teams cross-cut to the stream-aligned teams and have the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack. This allows the stream-aligned team the time to acquire and evolve capabilities without having to invest the associated effort…

An enabling “product management” team for an I&O organization would provide expertise, but on a pull not push basis. The platform leadership has new incentives such as “choose to use” market discipline and eNPS goals. To meet these goals, they are coached to recognize they need help. They set the terms of their engagement with the enabling team, but at the end of the day do incorporate the new insights and priorities for value, viability, and usability.

And of course, the enabling team must be conversant with the particular problems of managing infrastructure platforms as products, but the workforce reality is that they will have a learning journey to do so. Good luck finding and hiring the perfect folks. You’ll need to grow them.

The other (not mutually exclusive) option is grow from within. A CIO friend of mine looks for engineers who she can convince that product management is an equally challenging and rewarding problem domain. This is a well understood path in tech companies going back to IBM and HP in their heydays, where engineers often made that career decision.

But again, this will take time and long term executive commitment, and you’ll probably not find the perfect folks in the external hiring market. Time to invest in your staff development capabilities, including partnerships with the consultancies who increasingly are specializing and building some good depth here.

I’m very interested in hearing from you. How is your product and platform transformation going? Reach out to me on Twitter or LinkedIn.

Note: I am proud to have participated in the developmental reviewing of Team Topologies.