If you're here, it means you most likely have an idea of what an internal platform is, and you're probably also familiar with the concept of a product. Now, get ready to have your mind blown: Manuel Pais, who co-authored the book Team Topologies with Matthew Skelton, is here to explain how the two ideas can be one and the same.
In this PlatformCon talk, Manuel builds on ideas and patterns from Team Topologies, including thinnest viable platforms, team cognitive load, and evolutionary team interaction modes. He also shares how organizations like Adidas and Uswitch have applied platform-as-product models to accelerate and simplify the delivery of software at scale. Here's a quick overview.
Product management for internal platforms
Manuel starts by delving into a topic he knows well, considering he wrote a book on it: Understanding the way teams form and recognizing how common anti-patterns can hinder their efficacy.
According to Manuel, the structures of business and technology teams can benefit or impede their ability to achieve fast flow, which is the rapid delivery of value to customers. In this light, the platform-as-a-product concept makes complete sense if you simply regard the internal users – like your devs and SREs – as the "customers" who'll consume your services.
The issue, explains Manuel, is that platform-as-product adoption lags behind the idea. For instance, Thoughtworks, known for its quarterly technology radars, promoted applying product management to internal platforms as far back as 2017, underscoring the importance of thinking in product-oriented terms while developing and refining internal platforms.
It's not as if this concept was so far-out that it defied implementation either. Thoughtworks even offered some concrete suggestions, such as:
- Having platform engineering teams take ownership of specific parts of their platforms and letting them create internally visible brand identities they can use to sell their colleagues on the benefits of their work,
- Assigning product managers responsibilities that include continuous improvement activities, such as road mapping, usage metric data-gathering, and quality monitoring, and
- Avoiding the common phenomenon of layering platform teams that are split by technology.
As Manuel points out, there's a unifying theme here: Giving serious consideration to what your users need to consume, what's going to help them, and what products the platform offers.
Thinking about platforms as products represents a stark shift from focusing solely on the underlying technology that powers them. It often requires a broad assessment of the technological ecosystem within the context of which specific tools internal teams find helpful for doing their jobs.
Pinning down the concept of a platform
The term "platform" has many connotations, so it's important to reach a common working definition. In Team Topologies, Manuel and his coauthor took a hint from Thoughtworks' Evan Bottcher:
Of course, that's a pretty heavy description. Fortunately, Manuel further breaks down the fundamental characteristics of effective platforms:
- Self-service: To achieve fast flow and respond quickly to customer needs, platforms can't depend on users creating feature requests for other teams to handle and then having to wait for the new versions to ship. Changes must be possible on-demand, and the requester must have a firm say in their implementation.
- Accessible: Platform team support and knowledge must be easy to access. Similarly, a platform itself must be straightforward for internal teams to understand and use.
- Compelling: Platforms should promote voluntary use, which ties into the idea of creating a path of least resistance – Instead of mandating that devs use a platform, it's best to create one that proves itself as the easiest option for getting the job done productively. Aiming for compelling results incentivizes platform teams to focus on users' needs and build more relevant features.
The Team Topologies perspective
In Team Topologies, Manuel points out that exemplary platforms offer curated experiences to their internal "customers" – the engineers and other users. This objective naturally moves the focus away from the technology and what can be built to what should be built and how it might make a difference in the users' lives.
The way a team is organized has a lot to do with its efficacy and sheds light on the necessity of viewing platforms as products – Not every platform team is guaranteed to be successful, and neither is every platform. It's critical to understand how the underlying organizational structure of a team impacts the viability of the products it creates.
Building the thinnest viable platform
Team Topologies introduces the notion of the thinnest viable platform as being comparable to the widely used minimum viable product concept. In other words, enterprises can benefit from explicitly defining the smallest set of APIs, documentation, and tools required to accelerate the development of a platform's services.
By focusing on the minimum – and aiming for a just-big-enough platform instead of a bloated behemoth – organizations avoid implementing unnecessary functionality. They also increase the likelihood that they'll create something that positively impacts its users.
Exploiting evolutionary interaction modes
All good platforms evolve with the organizations that use them. Manuel stresses the importance of guiding this evolution using team interaction modes to understand when it's appropriate to interact with other teams and how such cooperation ought to occur. For instance, when developing or upgrading a service or API, it's natural to expect strong collaboration between the platform team that's responsible for the features in question and the team or teams that comprise their consumers.
Rapid discovery and awareness of interaction modes can help keep platforms from becoming stale. Developers must explore their customers' needs and the motivations for developing and refining services, such as typical use cases or consumption methods.
Investigating these questions collaboratively informs the prototyping stage and guides useful feedback initiatives. With such an informed foundation, platform teams can then focus on providing the necessary support and documentation.
These habits also enhance operational understanding. As services evolve, it becomes less difficult to predict the need for collaboration. Devs can also expect to grow increasingly proficient at determining when services are truly mature enough to be stabilized for organization-wide consumption and identifying gaps between the features that platform teams implement and user needs.
Ideally, platform teams alternate between solution-seeking, collaborative interaction modes, and stabilizing services for autonomous consumption. Manuel likens this to organizations taking hints from well-known cloud infrastructure-as-service providers: Teams that internally apply the same principles that giants Google and AWS use can move faster and with increased autonomy.
Aiming for reduced cognitive load
What's the end state of evolutionary interaction modes? Although the beginning exploratory stages are heavy on collaboration, they often give way to a sort of clarification of boundaries. They also promote the development of useful abstractions that reduce the cognitive load on the teams consuming the platforms.
Again, this makes sense: More mature platforms achieve enhanced ease of use by hiding what ought to be hidden – even if that's not necessarily everything that can feasibly be hidden.
Here, Manuel builds on the concept of product as defined by Silicon Valley Product Group's Marty Cagan: A holistic user experience. With platforms, it's not just about functionality; usability is equally important.
This hearkens back to the idea of compelling platforms that don't require mandates to drive adoption. Although teams commonly evangelize and advocate for their platforms, they shouldn't necessarily focus on the "hard sell" – Instead, they should work to build software components whose value is self-evident. This reduces cognitive load by forcing developers to engage with the users to explore what they need and build relevant features as opposed to creating platforms that ultimately make workflows more difficult.
The Platform-as-a-Product model in action
Manuel drives his points home by sharing two stories of how companies leveraged the platform-as-a-product concept to improve their internal platforms:
Uswitch
Uswitch is a UK website that lets users compare home services. In the beginning, the firm's engineering strategy primarily revolved around team autonomy. It implemented what Team Topologies refers to as stream-aligned teams, where each group focused on a different service comparison category, such as energy providers or mobile companies.
This worked well for a while, but it eventually increased cognitive load. Teams spent more time trying to manage low-level services, like AWS, than making high-value decisions!
The solution ended up being to introduce a custom platform built on Kubernetes. This allowed Uswitch to abstract away the finer details, letting its teams focus more on serving external customer needs and driving business results. It also made it possible to scale the teams while adhering to the company's foundational software engineering principles: autonomy, minimal coordination, and self-service infrastructures.
Adidas
Adidas invested heavily in its engineering and internal software teams to deliver services more effectively while utilizing a platform-as-product approach. The company chose to leverage numerous interaction modes described in Team Topologies, including having teams enable and mentor each other to close knowledge gaps.
As Manuel explains, Adidas decision-makers realized early on that they needed to alternate between interaction modes to achieve their long-term goals. Viewing the company's extensive internal platform as a product was the best way to do that.
Final takeaways
Approaching platform development from the product perspective can be a game-changer for organizations of all sizes. In addition to making service and API consumption easier, this strategy is an effective way to reduce bloat without constraining a platform's ability to grow over time.
These are just some of the points covered in this talk, so consider watching the video for deeper insights. Also, you can learn more about delivering a better platform experience that capitalizes on how your teams grow and interact by checking out Manuel's book at teamtopologies.com. It's definitely worth a read.
.webp)
.webp)
