Many incumbent organizations across industries and sectors want to become more like tech companies: fast, agile, and dominant. They’re doing so to remain competitive at a time when B2B and B2C customers have high and rapidly changing expectations and digital disruptors are upending the business landscape.
The key to making this change lies in adopting a technology operating model based on products and platforms. This model organizes technology around user-facing products, to facilitate end-user journeys or experiences (ordering, bill paying, and loyalty programs, for example), and the underlying platforms that enable them, such as customer relationship management (CRM) and marketing technology (MarTech).
The benefits of this product and platform model have been well established. The product and platform model ensures that technology delivery is aligned to the strategy and related priorities. In our experience, it can generate significant business value, spur innovation, improve customer and employee experience, decrease time to market by up to three times, reduce product defects by 50 to 70 percent, improve brand and image perception, and increase operating margins and total shareholder returns. A recent McKinsey survey revealed that at nearly three-quarters of top-performing companies, the most-senior tech leaders are highly involved in shaping company strategy.1
The issue, however, is that many companies that want to develop a product and platform model struggle to do so. We analyzed more than 50 organizations across industries and geographies undergoing product and platform operating model transformations. (See sidebar “About our Operating Model Index.”) Although a few companies have met or exceeded their objectives, the efforts of a significant number either have stalled (for various reasons) or were unable to scale following initial progress.
What do the few get right that eludes the many? Our analysis revealed five actions that are critical for transitioning successfully to a product and platform operating model: getting the design of products right, prioritizing platform redesign, partnering with the business, rethinking tech governance, and transforming software engineering practices.
1. Build product teams around the end-user experience
In a product and platform operating model, “products” are the technology-enabled offerings—tools, services, or experiences—that allow customers and employees to engage in activities that create value. These might include “search” for a retailer, for example, or “financial planning and analysis” for a finance team. These products can be grouped around a variety of organizing principles, each with a specific team to serve the needs of the end user, deliver on the goals of the business, and align with the organization’s market position or digital maturity. For example, a market leader whose main concern is providing an omnichannel experience will set up multidisciplinary teams organized around products, such as ordering, and provide these products through multiple channels. Platform teams provide and maintain services that product teams consume (such as CRM and authentication).
An effective organizational approach has often been to build product teams around stages of the customer experience surrounding a purchase, from search to payment, or adjacent capabilities, such as loyalty programs or billing functions. Teams might also be organized around the employee experience, from recruitment to onboarding. In these approaches, the emphasis is on models that can be broadly applied and reused.
Each product team will have a mission and be accountable for business outcomes. The teams must be small enough to be effective, yet contain all the cross-functional skills required for the team to function autonomously. It is critical to keep the number of teams manageable. Too many can strain resources while blurring accountability and adding bureaucracy. (See sidebar “Key considerations when creating product teams.”)
A global telco ran into several challenges when it rolled out its digital transformation prior to shifting to a product and platform design for its entire organization. In some product areas (such as promotions and trade-in), multiple business leaders claimed ownership of the same part of the design, and IT struggled to staff and resource them all. This led to a need for increased coordination, which affected the company’s ability to prioritize work and capture value from the transformation. Eventually, the telco paused the scale-up, designed a full product and platform model that addressed skill needs and talent allocations, aligned all stakeholders, and ensured the business assigned a single owner to each product. Only then did it resume scaling the transformation.
Would you like to learn more about McKinsey Technology?
2. Don’t forget the platforms
When embarking on the transformation, companies often assume that simply reorganizing around products will be sufficient. That is rarely the case; indeed, it often results in greater technical debt.
Platform teams focus on making a company’s core systems more accessible, reusable, and better able to support products. Platforms develop and manage the underlying core systems (such as identity and access management and order management) and backbone (such as storage, aggregation, analysis, and provision of data) on which products are built. Products consume the services that platforms develop through APIs and microservices.
When designing and operationalizing platforms, companies should focus on three elements:
- Organization of platform teams: Companies should organize platforms into three groups: business or journey platforms that enable a specific business domain or end-user journey, such as customer data and inventory management; shared platforms that are used by multiple journeys or business domains, such as enterprise resource planning (ERP); and enterprise platforms that power the IT organization, such as identity and access management.
- How platforms interact with product teams: Most organizations have to manage platforms with varying degrees of flexibility. Some platforms, often older ones, are static. In this case, product teams design most of the features they need, and then platform teams do most of the actual build work. Newer platforms or more important platforms (such as e-commerce and chat bots) are built with a modular architecture and accessible via APIs. It’s crucial to assess how modular the platforms are, because that will determine resource needs, scope of work, and dependencies. To do this, the platform owner typically needs to work with product owners to prioritize and sequence the platform road map.
- Platform operations: Modernized platforms will operate like a product team. They will need a single platform owner with a dedicated team (mostly engineers), a vision, a road map, and objectives and key results (OKRs) linked to business outcomes—for example, reducing wait time at the counter by reducing the API response time.
A well-defined product and platform design can function as the de facto organizational structure (Exhibit 1). Our experience suggests that, since strategic priorities shift from year to year, organizations can anticipate that the design of their products and platforms may also shift by 10 to 15 percent in order to align with strategy. (See sidebar “Invest time in equipping your people for the change.”)
The approach to developing a platform capability can vary. An Asia-based bank created large platform teams across business units and geographies with joint business and technology leadership and accountability. Their efforts included developing persistent resourcing, shared performance objectives, and dedicated business processes and technical assets. This approach sped up platform modernization and rapidly increased the autonomy of product teams. A global retailer, on the other hand, had the product and platform groups working together, because the architecture was highly coupled in a few core systems, such as e-commerce platforms. The product and platform leaders committed to working together to modernize the platforms and eventually make them consumable via APIs.
3. Reinvent tech funding to make product and platform teams autonomous
Providing product and platform teams with reasonable autonomy requires a flexible but disciplined governance model. The first step is to define accountability to manage demand across different products. For example, all product enhancements and ideas for new features should flow to the leader of the respective product category or senior product owner, who oversees multiple product teams and helps with decisions on prioritization and resource allocation. That person regularly (perhaps quarterly) updates a central portfolio team to provide transparency on progress. This approach decentralizes decision making, eliminates duplicate responsibilities in the organization, and nourishes a collaborative and outcome-based culture.
This shift begins by funding product areas so that each product and platform leader has the autonomy to make and adjust funding decisions for their teams. Product leaders should have a single prioritized backlog (building features, fixing errors, remediating technical debt) and secure capital and operating expenditures to keep consistent product teams in place. Functions such as design and agile coaching are often funded through earmarked operating budgets.
The quid pro quo of providing more autonomy to product and platform teams is that the teams commit to clear OKRs linked to outcomes and aligned with the goals of the company. Organizations using OKRs to track progress and dynamically reallocate investments based on performance increase financial accountability, improve control of end-to-end product expenses, and can ultimately capture more value. We have seen organizations using this approach reduce the time required for annual budgeting by more than 60 percent and the time spent on management reporting by 20 to 30 percent.
At most companies today, some areas—especially for large existing programs—may maintain project-oriented governance for one to two years, while other areas (such as customer journeys) can move more quickly to product-based governance. It is important to be disciplined in finding the right balance while maintaining progress.
Products and platforms: Is your technology operating model ready?
4. Establish joint accountability between tech and the business
The main goal of a product and platform transformation is to generate the biggest impact for the business. That requires the IT function to work much more closely with the business and include all functional stakeholders—sales, marketing, supply chain, and customer service.
A clear baseline of existing capabilities and a clear blueprint for progress are useful artifacts for aligning tech with the business. From there, companies can establish a mechanism to sustain business involvement in the transformation. That can come from ensuring that a business leader joins each product team, sometimes as the product owner; has a guidance role on platform teams; and shares joint accountability with corresponding tech leads for delivering on the OKRs.
Where broad business support for the product and platform transformation exists, a larger scale-up of the operating model and structural changes to it can happen relatively quickly. In other cases, however, initial business champions and early adopters should launch a few teams to start. Even a small group that quickly demonstrates business value can have a big impact on building support in the business, including for more substantial structural changes (Exhibit 2).
A regional bank and a global retailer both opted to use a two-in-a-box model, in which a business leader and a tech leader jointly led a product team. This established clear joint accountability for business and technology performance objectives. This model helped the bank and the retailer develop the confidence to push decision making down to the product team level.
Another global retailer, meanwhile, took a slightly different approach, opting for a three-in-a-box model that embedded product, design, and engineering leadership in each team. The company replicates this triad at every level (product group, product, team) to ensure that the right capabilities and effective decision making are available at every stage of the journey.
5. Commit to creating a great developer experience
Committing to engineering excellence is about more than hiring great engineers. It’s about creating an environment where engineers can thrive by doing work of the highest value, using advanced tools and relying on automation across software development to reduce toil. At its root, this commitment to creating an advanced engineering environment is about focusing on the developer experience.
Advanced tooling includes providing on-demand access to self-service environments for testing, a fully automated and secure continuous integration/continuous delivery (CI/CD) pipeline (feature flag of issues, canary release techniques, and zero downtime), and automated life cycle management that makes it easy to observe and trace issues so teams can rapidly address them. Delivering on these capabilities requires a commitment to decoupled architecture, automating security and integrating it into the development process (DevSecOps), and tracking the performance of engineering modernization initiatives.
These measures enable developers to seamlessly spin up a platform in minutes, easily consume platform services with multiple consumption models (APIs or GitOps), and rapidly make improvements to platforms through an open-source approach (aka InnerSource) to manage code contribution.
Creating this kind of work environment requires a commensurate shift in the work that engineers do. Companies should consider allocating 10 to 30 percent of developer capacity to building new engineering and automation capabilities and upgrading skills through tailored learning programs. These capabilities are essential not only to retaining top engineers but also to enabling product and platform teams to rapidly develop quality software.
A global telco invested in the developer experience by setting up an enterprise-wide DevSecOps program that ran in lockstep with the product-model transformation. The program had five key pillars: a modern decoupled architecture, CI/CD practices, operational resiliency, security integrated into development, and tech delivery linked to business outcomes. The company supplemented the program by rolling out a central measurement platform to assess both the maturity and adoption of modern engineering practices through a real-time dashboard. The DevSecOps program ran in parallel with an aggressive migration to the public cloud. The program increased innovation, speed, the reliability and quality of code, and cost savings.
Transitioning to a product and platform operating model is no small undertaking. But by taking the five actions outlined in this article, organizations can put themselves in a stronger position to capitalize on the benefits of this operating model—not only spurring innovation and developing better products faster but also improving customer experience and increasing total shareholder returns. It’s an effort worth getting right the first time.
