Six steps to reorienting your IT operating model around products

This article was co-written by Chris Davis, Partner, Metis Strategy, and Kelley Dougherty, Associate, Metis Strategy

In this time of fluid markets, fierce competition, and constant disruption, the modern enterprise must stay innovative and agile. It must be ready to evolve at any moment, and deliver quickly, consistently, and reliably through its large-scale software operations.

But it can hardly do so through traditional, monolithic ways of working, particularly those organized around projects. Many companies are therefore reorienting their operating models around end-to-end products. Done well, these transformations make a company nimble. Done poorly, they exhaust the organization and produce little value.

Leaders must transform their organizations methodically along a path that minimizes redundancies, builds momentum, and creates immediate and tangible business value. In this article, we outline the steps to start a product operating model journey, coloring the steps with stories told on the Metis Strategy Podcast by executives from companies like Ascension, Condé Nast, and Hyatt.

1. Productize your capabilities

First, leaders must identify the products around which their operating model will be designed. We define a “product” in this context as:

“a capability or portion of a capability, brought to life through technology, business process, and customer experience, with a continuous value stream, and an ability to measure success independently.”

Therefore, leaders should draw the capability map of their business, showing how value streams and assets are positioned, how they relate to each other, and which of them are immature or missing. These capabilities can then be translated into end-to-end products calibrating for the organization’s size, offerings, and business model.

If an organization has uniform customer offerings and go-to-market motions, then its products should be aligned to the company’s value chain. Such is the case at Ascension, as explained by its Chief Marketing and Digital Experience Officer, Raj Mohan: “We’ve organized our teams particularly broken up by the consumer journey into product teams down that path, and then staff those teams along those journeys itself.”

In practice, products aligned to a customer-facing value-chain might include: Development → Marketing → Sales/Order Management → Fulfillment → Customer Success

Aligned to internal value streams, they might include Financial management, HR management, Legal Management, IT Management, Facilities Management, and Data and Analytics.

In contrast, if an organization has multiple business units, offerings, or go-to-market processes, its products must be defined so they account for each BU’s customers, geographies, and so on. This way, products can still be aligned to value chains but also arranged into broader groups, lines, and teams, each constituting a “deeper” aspect of the value chain.

This is how products have been defined at Condé Nast.

Sanjay Bhakta, Chief Product and Technology Officer at Condé Nast explains that his organization’s product offerings result in them having “some capability within the brands, especially the big brands, that focus on things that may be bespoke or have specific requirements.”

2. Standup and staff your product teams

Next, leaders must define the capabilities around which they’ll organize resources and configure the product teams such that they can deliver value autonomously. Mohan suggests that a product team can stand on its own “if, over at least a three-year horizon, you can see clearly that a durable team can bring value that you can sign up for.”

How many product teams should you have? As a rule of thumb: about one tenth as many employees as there are in the organization. Ideally, each product team should comprise seven to nine people, and they should include a product manager, scrum lead, technical lead, and engineers. These might be supplemented by user experience leads for consumer products, other engineers, shared services, or specialists.

3. Manage your portfolio with a capability-driven mindset

A project-to-product transformation requires that an enterprise think first in terms of products, and this shift hangs on the structures and processes by which the company manages its portfolio. A company should organize its portfolio around the outcomes it seeks, and those should in turn dictate the capabilities initially staffed to mature at a higher rate. When resources are limited, start by productizing 2-5 key areas, do it well, and scale from there.

Hyatt, for example, has organized its portfolio around customer-focused capabilities, and so has caused the enterprise at large to think in terms of customer outcomes. As Hyatt’s Global CIO, Eben Hewitt, has explained: “Moving to a product mindset, to me, means, number one, it’s for a customer… You’re thinking about the outcomes that people want.”

Further, an organization will do well to manage its portfolio according to Agile principles and to align its product teams to business outcomes. Not only will product teams then naturally align to each other and their shared objectives; the organization itself will think in terms of products and outcomes.

To manage portfolio by capabilities, use annual planning sessions to craft roadmaps aligned to outcomes and segmented by capability. Such roadmaps can then inform the teams who support those capabilities, and ensure their own roadmaps align to enterprise objectives. These planning sessions also give leaders a chance to decide how to allocate funds. As a rule, the product teams should receive roughly 80% of the organization’s budget, and that allocation should cover their needs end to end to build and manage the lifecycle of the product. The remaining 20% should go toward broader initiatives.

4. Define common ways of working

Adopting an Agile mindset and common ways of working early in the journey will help reorient a company reliant on waterfall, project-based operating models towards continuously delivering value. However, frameworks such as Scrum and Kanban are a means to an end. Some organizations conflate a “product” transformation with an “Agile transformation,” and lose themselves in the minutia of adhering to specific ‘rules’ and ceremonies.  The key is to create a baseline for teams to form, storm, and norm by reducing confusion of how to transition from a rigid waterfall process to a mindset in which an entire agile product team establishes a shared identity founded in the problem the product solves; not their title or role on a waterfall assembly line.

Bhakta emphasizes that Agile should extend to the relationship between product and engineering. He explains: “[It] helps us do faster decision-making, helps us to get products out into the market faster.”

If organizations are already practicing Agile when they start transforming, then they should focus on infusing into their processes the product mindset. If an organization isn’t so mature, however, then it should train teams on core Agile practices to which they can align their processes.

5. Empower and deploy effective product management resources

Ultimately, this transformation largely depends on whether people can successfully serve the role as a Product Manager, and balance the business value, viability, usability, and feasibility to focus teams on shipping products and experiences that users love, adopt, and help improve with feedback.

Therefore, each team needs a Product Manager, who can:

• Drive product strategies end to end
• Lead discovery of end user pain points
• Plan and help design how the product evolves
• Actively shape priorities and solutioning in development and delivery (this is often the scope of a Product Owner in Scrum)
• Chart a go-to-market strategy (internal or external)
• Ensure organizational readiness, including pricing and Revenue Operations (for external products) and financial management (especially for internal products)
• Analyze data and trends to define how the product grows, changes, or sunsets as necessary

Identifying, training, and upskilling Product Managers, especially for internal products, is often the hardest part of the journey. But to be successful, Product Managers must also have clear scopes of responsibility, the power to execute on them, and feedback loops by which they can measure performance and course-correct.

6. Establish and maintain mechanisms of continuous improvement

Each of the steps we’ve covered critically enable teams to scale, and once they’ve been carried out the first time, they tend to act as a flywheel, sustaining themselves with their own momentum and creating excitement within the organization to productize more capabilities.

To gauge success of your product operating model journey, start by:

• Defining the business outcomes and KPIs for each product team
• Measure team engagement and happiness (over a one-month period)
• Measure delivery velocity and quality (over a three-month period)
• Watch the business outcomes improve with iteration (over a three-to-six-month period)

The journey of maturing a product team is never really complete. Once the teams are launched with the steps outlined in this article, leaders should then do the following at scale, working team by team:

• Infuse design-thinking into product-management
• Drive technical agility, especially by automating testing and DevSecOps capabilities
• Evolve the organization to a product-based funding model

It is our firm belief that adopting a product operating model is the only way to successfully support a scaling organization. But don’t take it lightly; this is a commitment that requires leaders to dedicate at least a year of their time to successfully transform an organization’s mindset.