This is the second part in a multi-part series on platform engineering, and platform product management.
In our first post we made the case that for many companies, the definition of platform is unclear or worse yet there exists conflicting and unresolved definitions. This lack of a consistent definition creates waste within the organization; executives and employees find themselves in conflict over the actions necessary to bring a compelling platform solution to market. We also introduced a platform analogy leveraging the automotive industry; an industry that has consistently leveraged platforms to create compelling margins and that in at least one case (Lee Iococca at Chrysler) saved a company.
This post focuses on the activities and mindsets that must exist within various stakeholder cohorts within a company. Our experience is that in many cases, companies have not yet adopted these approaches. In such cases, the approaches and mindsets must change to be consistent with the approaches below to maximize value creation, minimize time to market and keep the platform initiative from devolving into conflict thereby destroying shareholder value.
Boards of Directors and Governance
Platforms are solutions that take time to design and implement. They aren’t a quick fix to any problem, but they are often an appropriate long-term strategy. Boards must accept that designing and implementing a platform will:
1. Require new funding. Given that the company is also likely continuing to engage in day-to-day competition, the platform initiative will likely need additional funds beyond the current budget.
2. Take time. Platforms are complex and require a great deal of intellectual design time. They also require an equivalent time to implement and integrate into existing solutions.
3. Require new ways to govern. New board level questions and metrics are required to be successful. Given that we are aiming to reduce costs to develop solutions and decrease time to market the board should seek ways to evaluate platform efficacy along these dimensions.
CEO and Executive Team
Platform plays within technology product companies are company-wide initiatives, not solely the domain of engineering and product. As such, the CEO and her executive team must be the champions of the shift to platform. This team must lead by example through their behaviors and actions, help to define outcomes, sell the board on the initiative, and be accountable to the board for results. Examples of behaviors the executive team must model and actions they must take include:
1. Be intimately involved with the vision and definition (including contextual variants) of platform.
2. Police the use of the word in the company and help correct employees when using the word incorrectly. Doing so helps to keep the focus on the true vision and keep employees aligned.
3. Monitor the progress in design of a platform and help to evaluate it against the critical outcomes.
4. Disallow “Agile Chicken” type behaviors amongst the executive team and subordinate teams. There is no room for passive aggressive behavior or ongoing dissenting views that discredit the platform initiative. Everyone must agree and commit to the definition and approach.
5. Create a great product management function staffed with people that have experience in developing platforms and that can sense and respond to market needs.
6. Remove sales as a majority contributor to product backlog within the company, ensuring it is replaced with (5) above.
7. Appropriately fund the platform initiative – ideally without constraining other product development activities (there is, after all, still a war to fight while we are preparing for the next war).
Product Management
Platform initiatives are only successful within product led companies – companies where the backlog is largely informed by the needs of a market as a whole rather than discrete sales interactions. While sales channels are an appropriate source of product validation and can sometimes augment innovation, sales-led approaches of sourcing innovation from customer want lists is a guaranteed path to failure in platform initiatives.
As such, product management functions in aspiring platform companies must:
1. Have great product managers be the primary source of company product backlog – sourcing such backlog from critical analysis of the broad needs of the target market.
2. Work alongside architects as “battle buddies” to help define the customer facing products and the reusable components that create those products.
3. Include Sales as a validation point to product backlog and as an additional source (but never primary source) of innovation.
4. Create a great vision of the products necessary to be successful within various verticals and the market broadly.
Working jointly with architecture, product management must also:
• Partner to create the external views of products exposed from a platform, with product taking the lead and architecture playing a supporting role.
• Partner to create the internal component definitions of the platform, with architecture taking the lead based on the external definitions of products.
• Partner to identify the internal interactions necessary between componentry, and the external interactions vis-à-vis APIs that are exposed (again as products) to the market.
Product Marketing
Product marketing is often the organization that creates the greatest confusion within platform initiatives. The team must understand the difference between how a platform is represented to the market vis-à-vis the sales and marketing of a platform, and how the platform is constructed. Often, marketing teams confuse the “marketecture” they use for explaining capabilities with the true componentry and operations of a platform. Product Marketing teams therefore should:
1. Ensure they understand the difference between how they approach the market, and how the solution really works. Do not get caught in the trap of “marketecture” being reality and do not contribute to internal strife over the differences between the two.
2. Constrain forward-looking statements regarding capabilities to the near term. Promises of release capabilities beyond one quarter out should be limited to bullet points of areas addressed rather than specific capabilities of a system. Trying to be too precise within marketing for future releases constrains the Agile process and eliminates the ability to “pivot” or be agile in favor of hitting specific (and likely incorrect) target deliverables.
Sales
Great platform salespeople share the attributes of great SaaS salespeople; they sell what is “on the bus” along with the promise of future enhancements. As we’ve written before, it is often hard to train a non-platform or alternatively an on-premises sales team to be successful in the SaaS and platform world.
Package software and on-premises sales teams are used to selling heavy customizations to meet what customers want. Platform sales teams are great at selling components necessary to meet a customer need, and extensions of functionality that interact with APIs. Successful platform sales teams must:
1. Not commit the company product roadmap contractually unless approved by product management.
2. Sell only what is built and hint at future capabilities; do not sell what can be through heavy customization of the core software componentry.
3. Sell professional services engagements that extend functionality – but only where APIs exist to be successful.
4. Rely on “real” sales engineers who truly understand product capabilities to help with professional services sales and/or capabilities and integration activities.
5. Help to inform the product roadmap through customer experience, but not hijack or assume “ownership” of the product roadmap as such a thing forces the company away from the platform initiative back into being an on-premises “work for hire” shop.
Engineering
To run efficiently, engineering teams need:
1. A mindset consistent with the internal definition of platform.
2. An organization structure that enables ownership and reduces contention and coordination overhead for platform components.
3. Processes that reinforce both ownership and the platform approach.
Mindset changes necessary in engineering include:
• A relentless focus on reuse of libraries and services that comprise the platform (aka “the components”). Teams must be willing to explore existing internal options, and the reuse of existing open source or third-party components in order to achieve decreased time to market, increased reuse, decreased cost and increased quality.
• Nowhere is this mindset shift more necessary than in senior technology leadership. Governance is essential to achieve the goals that platform initiatives promise. In the absence of governance, costs will increase as will overall time to market. This in turn destroys the value creation of the platform initiative.
Organizations must be built to align to components. As depicted in the diagram below:
• No two teams should own the same component, which achieves reduction in coordination overhead and therefore speeds time to market.
• Teams ideally own one component to reduce context switching between repositories, but in some cases, components may need to be split for availability or scalability reasons. If the overall component to team ratio can remain below 2:1, with no team owning more than say 5 components total, most goals should be achievable.
Process changes include some notion of lightweight platform governance (shared with architecture and product) and the establishment of platform principles (a topic for another post).
• We often view governance as a four-letter word, or a synonym for nonsense overhead that slows down delivery. But governance does have a purpose in many places including its need in reinforcing platform expectations. Architecture, product management, and engineering must band together to reinforce the reuse and construction principles that engender faster time to market and lower cost. Such governance should be “real time” and accomplished through embedded product owners and architects within delivery or “Get Stuff Done” (GSD) teams.
• Engineering must partner with both product and architecture to create the principles that define the operations of the platform as well as patterns to adopt and anti-patterns to avoid. All of these will be addressed in a later post.
Architecture
Architecture is a near mirror image of the mindset and activities defined within product. Together, the “ying and yang” duo of architecture and product must:
• Partner to create the external views of products exposed from a platform, with product taking the lead and architecture playing a supporting role.
• Partner to create the internal component definitions of the platform, with architecture taking the lead based on the external definitions of products.
• Partner to identify the internal interactions necessary between componentry, and the external interactions vis-à-vis APIs that are exposed (again as products) to the market.
Additionally, Architecture is responsible for:
• Characterizing the methods of interaction between product components and defining minimum contract standards (APIs) for each interaction.
• Defining the architectural principles (with aid from engineering) that govern the administration and development of the platform.
Finally, if there is no experience with platform development within the architecture team, we suggest augmenting the team with new hires with proven experience. Such experience will aid greatly with the development of platform principles and architectural blueprints.
Embarking on a platform initiative – or a transformation of your existing product to a platform? Give us a call – we can help!