Platform Product Management Versus Platform Engineering
Note: I have heard some concerns I’m “throwing I&O under the bus” here. That’s not the intent. I&O’s struggles stem from deliberate operating model choices by senior leaders. The individual contributors have always worked hard in difficult circumstances. I truly believe that proper product management will benefit them.
I 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 his book “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 infrastructure and operations (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 versus the product team ideal, in Cagan’s terms.
Note: Fundamental value here is the provision of technology services and resources. That doesn’t change. The value problem has been the cost of delay that traditional I&O has incurred, which is why automation and queuing are priorities.
[*See my Expertise And The Shared Services Problem: A Conversation With Don Reinertsen blog post.]
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 I&O 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. This understanding probably depends on the organization having product teams already successfully running at the customer and business facing (aka “stream-aligned”) level, to demonstrate the principles.
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:
- An enabling team
- Developing from within
Enabling teams, in Team Topologies terms, are:
[…] composed of specialists in a given technical (or product) domain, and they help bridge any capability gaps. Enabling teams can cross-cut 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 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 that they need help. They set the terms of their engagement with the enabling team, but at the end of the day, they 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 to grow from within. I’ve talked to several senior leaders who look for engineers who can be convinced 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 probably won’t find the perfect folks in the external hiring market. It may be time to invest in your staff development capabilities, including partnerships with the consultancies that are increasingly 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.
*Net Promoter, NPS, and the NPS-related emoticons are registered U.S. trademarks, and Net Promoter Score and Net Promoter System are service marks, of Bain & Company, Inc., Satmetrix Systems, Inc. and Fred Reichheld.