Thoughts on the Product Parts of "State of Platform Engineering Report Volume 2"
I recently read the "State of Platform Engineering Report Volume 2" by Humanitec. You can download it here. It's short, only 20 or so pages, and worth a free download. However, I want to cover relevant sections to Platform PMs and my takeaways.
Product Management is Young
Applying product management to internal developer platforms and engineering effectiveness started only in 2018:
"Then in 2018 Evan Bottcher defined a digital platform...This is also when the concept that platforms are and should be treated as a product started out, as a foundational pillar of platform engineering."
The history lesson cements what I've seen across the industry: thinking of platforms as products has varied results. But, product thinking applied to IDPs is only five years old. How quickly can the industry learn across a multitude of different company cultures? I don't know the curve of when this gets figured out, but the next five to ten years will see significant changes in this responsibility.
Delineation of Responsibility
"According to the survey, only 38.1% of respondents have a funded platform team with a clear delineation of responsibility between themselves, and development organizations."
This one interests me since Platforms often provide what they consider "best practices" yet are at odds with a specific product team's designs. Who decides what is right? What if the product team's practices are best for the business, but the platform isn't built to suit -- do they lose platform support? Is the Platform responsible for measuring a product team's engineering effectiveness? There is a constant push and pull between fostering independence within a product team and establishing points of leverage and standards that other stakeholders in the company value.
Viewing the Platform as a Product
Overall, roughly a third of the survey's respondents said they drive the platform like a product:
"The survey explored three aspects of the platform as a product approach: identifying features, strategy for driving platform adoption, and organizational buy-in.
When it comes to identifying new platform features, just under a third (32.3%) of respondents follow a platform as a product approach. 28.1% take an evolutionary approach, collaborating with users to define the scope of work before optimizing for wider use. 26.1% of respondents take a reactive approach, and only 11.6% identify new features by following an infrequently updated set list of requirements."
What's danced around is that you can view the Platform as a product without PMs. I have seen companies tell their Engineering Management or Architects to think like it's a product. I'd like to see trends in using PMs to drive the product and how outcomes like adoption, buy-in, and feature delivery change.
Adoption
The section on adoption is focused more on the "how":
"Just over a quarter (25.1%) of respondents recognize this, and report establishing platform advocacy to help drive adoption. 20.9% say they rely on internal champions, 17.1% mandated platform usage, while the majority (36.9%) still take a "build it and they will come" approach."
Like the above, I'd like to see how adoption is measured and trends in time to complete. Do most companies view adoption on a feature-to-feature basis? Do they deliver it as a single, versioned platform? Are some considered done when specific teams adopt but not the rest? What about an option for automated delivery of updates?
Related, an earlier section in the report titled "Change Management":
"When it comes to fostering a culture that embraces change, the survey found the majority (64%) of respondents have no change management processes in place. Over a third (36%) report having strong internal change management processes in place, and 26.9% say they actively want change — however are lacking in any policies or plans. 26.6% also actively want change but are running into difficulties because of a weak change management mindset."
The survey doesn't directly link the two areas, but a straightforward change management process could include how new internal capabilities are versioned, released, and adopted.