The first question to ask for an internal platform is “how does this enable our product strategy?”
The first question that should be asked for an internal platform is NOT “what are the key activities?” nor “what are the key metrics?” but rather “how does this enable our product strategy?”
Understanding how to enable product strategy requires understanding product life cycles and the different goals at each stage.
For product capabilities intended to discover or create new markets, innovation teams need to run a lot of experiments. An internal experimentation platform can reduce the effort required to run experiments, analyse them, and share results. There is no advantage for each innovation team to re-build their own experimentation infrastructure, negotiate incompatible formats, etc.
For product capabilities intended to grow an existing market, feature teams need to iterate quickly. An internal platform can reduce the effort required to build new features on top of existing core capabilities. Feature teams should be spending most of their time focused on differentiating features and minimize their time having to deal with commodity capabilities.
For product capabilities that are commodities, platform teams should be trying to reduce maintenance effort and otherwise minimize the total cost of ownership. Reducing the operating costs of commodity capabilities should not come at the expense of developing differentiating or innovating capabilities.
Internal platforms need to enable ways of working, not just provide technology.
ThoughtWorks has a digital platform capability model with 5 categories:
- “Delivery infrastructure”: make it easier to continuously deploy and monitor;
- “API and architecture remediation”: make it easier to evolve product capabilities independently;
- “Self-service data”: make it easier to access and use shared data;
- “Experimental infrastructure and telemetry”: make it easier to setup, monitor, and analyse experiments;
- “Customer touch point technology”: make it easier to maintain a consistent customer/user experience.
Associated with every category is an assumption about how people work. We’re essentially assuming people are on-board with continuous delivery, empowered product teams, holistic ownership of product capabilities (UI, API, data pipelines), experimentation-driven product development, etc.
To be most effective, Internal Platforms likely require “enabling teams” to enable changes in ways of working, not just changes in technology.
Platform teams and developers/engineers need to be partners to enable product strategy.
The purpose of an internal platform is to enable product strategy through enabling developers/engineers.
The role of developers/engineers is not to do whatever the platform teams want nor is it the role of the platform teams to do whatever the developers/engineers want. Platform teams and developers/engineers are partners trying to enable product strategy.
See also
- What I Talk About When I Talk About Platforms by Evan Bottcher
- Digital Platform Strategy from Thoughtworks
- Product for Internal Platforms by Camille Fournier
- TBM 8/52: The Problem With “Internal Customers” by John Cutler
- Hard-Won Lessons from the Trenches: Failure Modes of Platform Engineering — And How to Avoid Them by Aaron Erickson
- Don’t Call It A Platform by Sam Newman
- Mind the platform execution gap by Cristóbal García García
- Platform Engineering Teams Done Right… by adrian cockcroft
