Platform-as-a-Product Meetup: The Platform as a point of failure for Product Operating Model transitions

The Platform as a point of failure for Product Operating Model transitions
We see a big number of leaders and organizations taking the journey from project to product. The success of the Product Operating Model, as Marty Cagan refers to it, relies on a holistic approach, one which goes all the way down to the various layers of platforms. Unfortunately, as with many other ideas and books, it looks like many people are missing or skipping the best half of the book. As a result, we see failures in both Platform Engineering initiatives and Project-to-Product transitions.
In this session, we will discuss the part of Team Topologies approach which many overlook and as a result they end up blocking both Platform Engineering and Product Operating Model Initiatives. We will go over the key Team Topologies principles required for successful Platform Engineering approaches and strategies and last but not least look at how Product Operating Models can be supported better by platform strategies, in turn increasing the business case for Platform Engineering.

Transcript

1. The Platform as a point of failure for Product Operating Model transitions Val Yonchev
2. Team what? https://teamtopologies.com/
3. Words of Caution Photo by Maria Freyenbacher on Unsplash
4. Challenges in transition: What is a Product? Photo by Giorgio Trovato on Unsplash Photo by Trew on Unsplash
5. Challenges in transition: Too little Products - Too many Products Photo by Giorgio Trovato on Unsplash Photo by Trew on Unsplash
6. Challenges in transition: What is really a value stream?
7. Think Mars Photo by Kabo on Unsplash
8. Think Mars Inc. Photo by Behnam Norouzi on Unsplash Photo by Kabo on Unsplash
9. Think Automotive
10. Challenges in transition: Technology is NOT part of our products Photo by Markus Spiske on Unsplash
11. Challenges in transition: Poor understanding of Value Chains Wardley Mapping starts with the Customer, her needs. Then helps define boundaries as well as what to build, what to buy
12. Challenges in transition: Value Streams & Customer Journeys Event Storming (light DDD) helps understand the Customer journey and how systems are designed to support it
13. Challenges in transition: Internal platforms are NOT products
14. Challenges in transition: Let's talk Platforms Photo by Tomas Anton Escobar on Unsplash Photo by Arif Riyanto on Unsplash Photo by Massimo Botturi on Unsplash Photo by Kevin Harris on Unsplash Photo by Nathan Cima on Unsplash Photo by Tolu Akinyemi 󰐕 on Unsplash
15. Platform Fail: We need one, right?! Platform Engineering
16. Platform Fail: No money left for platforms Photo by Towfiqu barbhuiya on Unsplash
17. Platform Fail: The Christmas Tree platform Photo by Arkadiusz Radek on Unsplash
18. Platform Fail: The forcing factor Photo by Brad Helmink on Unsplash
19. Platform Fail: What do we optimize for? Photo by Julian Hochgesang on Unsplash
20. Let's talk Platforms Photo by Tomas Anton Escobar on Unsplash Photo by Arif Riyanto on Unsplash Photo by Massimo Botturi on Unsplash Photo by Kevin Harris on Unsplash Photo by Nathan Cima on Unsplash Photo by Tolu Akinyemi 󰐕 on Unsplash
21. package Platform Engineering import "Team Topologies" type Principles interface
22. Principle: Treat the Platform as a Product Photo by Giorgio Trovato on Unsplash Photo by Trew on Unsplash
23. <Platforms> Accelerate the flow of value AND Reduce cognitive load within the whole system AND Enable substantial autonomy of teams consuming them </Platforms>
24. Principle: Platform accelerates Flow of Value (+autonomy) MBPM = Metric-Based Process Mapping
25. Principle: Platform reduces cognitive load
26. Principle: Enable a composable approach - reusable components and services Photo by FORTYTWO on Unsplash
27. Principle: Cognitive load drives decisions (team-of-teams & boundaries design) Buy these (replace own developed) Build these (replace own developed)
28. Principle: Cognitive load drives decisions (team-of-teams & boundaries design)
29. https://teamtopologies.com/ish Principle: Cognitive load drives decisions (team-of-teams & boundaries design) If DDD is scary, start with Independent Service Heuristics
30. Principle: Use fracture planes to divide complexity Business domain Regulatory Compliance Change Cadence Technology Risk Performance Isolation User Personas/Journeys Team Location Photo by Elizabeth George on Unsplash
31. For your information, there's a lot more to Ogres than people think… Ogres are like onions. Onions have layers. Ogres have layers... Platforms Platforms Platforms
32. Principle: Platform teams have cognitive load and needs too
33. Principle: Platforms serve real needs of real customers • Who is the customer? • What does she need? • What job does your product do for her? • Can one product serve several different customers OR do they have different jobs to be done?
34. Principle: Team is the smallest unit of delivery (and measurement) DevelopMENT Experience DevelopER Experience X
35. Principle: Design for Development Degrees of Freedom "Black box" Services Modifiable Services Configurable Services “I love that everything just works!” “The platform lets me experiment and innovate, and I can contribute my enhancements back to improve it.” “ I can tweak things the way I need them.”
36. • Build/serve for one group at a time • Collaboration interaction pattern precedes X-as-a-Service Principle: Start with one team, build the Thinnest Viable Platform
37. Principle: Competition drives progress • Competition drives progress • Product use is optional • Technology evolve and sometimes you need to switch from in-house to commodity Photo by Shiwa ID on Unsplash Photo by Denis Cherkashin on Unsplash
38. Principle: Platforms Products are never intuitive or easy enough X
39. Principle: Teams communicate through Team APIs Team API Service API https://github.com/TeamTopologies/Team-API-template
40. Principle: Consider the whole system (Fast Flow Of Value) People (Teams) Tech (Architecture) Process (SDLC)
41. It is a journey. Iterate! Photo by Anshu A on Unsplash Photo by Nadya Spetnitskaya on Unsplash
42. Thank you for listening! val@teamtopologies.com linkedin.com/in/valyonchev Let's talk. Book time with Val
43. https://teamtopologies.com/platform-manifesto