Chris Boyd co-wrote this article.

Leading digital transformations is the CEO’s top priority for CIOs, according to the 2020 IDG State of the CIO study. Doing so effectively requires an IT operating model that allows business and IT to work together to navigate a dynamic competitive landscape, a seemingly infinite set of digital tools and shifting stakeholder demands.

In our work with Fortune 500 companies, we have found IT organizations that use the traditional “plan, build, run” operating model struggle to conceptualize, launch and maintain momentum on digital transformations. To bolster their transformation capability, IT organizations across industries and geographies are shifting toward product-oriented operating models, or “product-based IT”. When done right, organizations experience increased agility, happier customers and more successful transformations.

Defining product-based IT

A product is a capability brought to life through technology, business process and customer experience that creates a continuous value stream. Examples of products are eCommerce, supply chain, or HR. An operating model defines how an organization positions its people, process and technology to deliver value to both internal and external customers.

A product-oriented operating model, then, is one in which IT resources are organized around business capabilities or “products” instead of specific IT systems (e.g. SAP, CRM) or functions (QA, Engineering, Infrastructure). In this model, each product team works as if they are managing a market-facing product such as a consumer electronics device. They develop a product strategy and roadmap in lockstep with the business that clearly articulates how they will mature the product to better meet customer needs and optimize competitive positioning. Every feature on the roadmap is aligned with a measurable business outcome and goes through a rapid discovery phase to validate value, usability and feasibility before it is slotted in a sprint to achieve a minimum viable product.

Drivers for the shift to product-based IT

Most organizations have honed their ability to deliver when the scope and desired outcome are static, but struggle when next steps aren’t defined or are painted with a broad brush. Several leading IT organizations have turned to product-based IT to cut through this ambiguity and elevate their role from service provider to business partner.

Art Hu, the global CIO of Lenovo, is one of the pioneers in the shift from project-to-product. He noted in a recent conversation that his organization grappled with the question of what to work on next after completing a series of legacy ERP integrations resulting from acquisitions. “The fundamental paradigm shift for us was that the level of uncertainty had changed when there was no longer one single imperative,” he said, referring to the ERP project. “When we took that away, it was a totally different world and traditional waterfall didn’t make sense anymore. Until we as an organization realized that, the business teams and my teams struggled.” Product-based organizations rely on continuous customer engagement to remove guesswork from the prioritization process, which often leads to better business outcomes and increased agility.  

Product-based IT targets key behavioral changes

CIOs have targeted key behavioral changes to jumpstart the shift to a product-based operating model:

Work is value driven, not plan driven

Project plans developed with fixed deliverables and timelines encourage predictability but rarely equate to business outcomes. This plan-driven work is increasingly yielding to continuous discovery and delivery, which seeks to answer two questions on a recurring basis: what should we build, and how should we build it? A discovery track intakes opportunities, ideas and problems to solve. Teams then engage with customers to validate that those ideas create value (desirability), will be used once released (usability) and are feasible in the current business model (feasibility/viability).

“Great companies that have built a product orientation start with desirability and leverage design thinking to have empathy-based conversations to get to the core of problems,” Srini Koushik, the CIO/CTO of Magellan Health, said during a recent product management panel. Ideas that make it through discovery are added to a product backlog and are slotted into sprints for delivery based on relative business priority. Discovery and delivery tracks operate concurrently to ensure that a steady stream of validated ideas and a working product that drives business outcomes is delivered at the end of each sprint.

Teams are dedicated and longstanding, not temporary or part time

In a recent strategic planning session, one CIO stated that “transformation is not a part time job,” noting that dedicated teams are critical for both digital transformation and building a product orientation in IT. Teams that are formed on a project-by-project basis spend valuable time ramping up subject matter expertise and building chemistry, but then are disbanded just when they start to hit their stride. Product-based IT organizations, on the other hand, favor dedicated teams that own a product from introduction until sunset, including the execution of discovery, delivery, testing and maintenance/support. In this model, the dedicated teams become true experts on the domain and avoid pitfalls resulting from intraorganizational handoffs and revolving resources.

Customer feedback is gathered at every sprint, not just at the end of a project

The increased frequency and quality of customer interactions is a hallmark of product-based IT. Ideally, customers are engaged during the discovery phase to validate ideas and prototypes, and then provide feedback at regular intervals after the product is released. If your end customer is a business unit, you should strive to have even more interactions. Some organizations have business stakeholders participate in daily stand ups, and some may even have their product owners sourced directly from the business instead of IT.

Atticus Tysen, the Chief Information Security, Anti-Fraud and Information Officer at Intuit, is another pioneer in the shift from project to product. At the 2019 Metis Strategy Summit, he emphasized that true product organizations reflect on key questions that demonstrate their strong relationships with customers. For example, do you really know who your customers are, and are you organized around serving them? Do you have metrics to measure customer happiness and show you are working with them in the correct way? “You have to have customers if you’re going to have a product organization,” Tysen said. “Product managers in a lot of ways are relationship managers.”

Teams are perpetually funded, not on a project-by-project basis

To achieve the benefits of a product-centric operating model, the funding model must shift as well. Rather than funding a project for a specific amount of time based on estimated requirements, teams instead are funded on an annual basis. Also known as perpetual funding, this setup provides IT product teams with stable funding that can be reallocated as the needs of the business change. It also allows teams to spend time reducing technical debt or improving internal processes as they see fit, which can improve productivity and quality in the long run.

Smart first steps to begin the shift to product-based IT

Here are a few key steps to begin the journey…

Identify targeted metrics and establish a baseline

Organizations should first and foremost target business impact when shifting to product-based IT. For example, one Fortune 500 client chose to measure Net Promotor Score to assess business satisfaction, product team velocity to assess speed to market and the number of critical defects per product to assess quality. It is also prudent to create metrics that track the adoption of key aspects of the working model. For example, you may track the percentage of product teams that have developed strategic roadmaps, or survey product teams on a regular basis to see how many feel like they have the skills needed to succeed in the product-based operating model.

Define your products using a value chain approach

Start by identifying the highest-level customer-facing and internal capabilities in the organization, such as Product Development, Sales, Marketing, Supply Chain, HR and Finance. At the highest level, these are your Product Groups, or “Level 1.” If your organization is smaller and has a relatively simple technical estate, you may not need to break this down any further.

However, we have found most enterprises with multiple business units and geographies need to do so. Inside the Sales group at a SaaS company, business processes would likely include steps such as Discovery, Lead to Cash and Customer Success (which includes activation, adoption, expansion and renewals). These may become your product groups since each of these steps involves different business stakeholders, targeted KPIs and technology components. However, the way you design your product teams will ultimately depend on the intricacies of your organization.

Absent a one-size-fits-all approach, we suggest the following guiding principles:

  • Establish clear ownership: The top priority should be to carve out product teams in a way that allows them to truly own and feel empowered to make the changes necessary to mature their product
  • Align with architecture: As much as possible, product teams should be able to own their architectural roadmaps and not have significant dependencies on other teams
  • Build teams around similar process and technology: If work is unique and utilizes different data, processes and technology, create another team
  • Keep it small: A product team should aim have no more than 10 people
  • Be strategic: Ensure your product teams cover the various business stakeholders and strategic goals
  • Continuously evolve: Strategic goals and business priorities shift often, leading to shifts in the product team landscape. Assign someone in your organization to review product team composition on a regular basis to assess the need to develop new products, modify existing products or sunset products that no longer align with strategic goals.

Define the roles/responsibilities for each product team

A key to product-based IT is building cross-functional teams that have the business and technical skills needed to accomplish most tasks inside their teams. The most important role in your product team will be the Product Owner (or Product Manager). Referred to as unicorns by some, these individuals possess the unique blend of business (strategy, competitive analysis), technical (architectural vision, technical project management) and leadership (decision-making, stakeholder management) skills and are responsible for driving the product vision and strategy and leading execution.

To fill this role, many organizations will conduct a skill assessment with their organizations to determine the skills needed to be successful, gather an inventory of available skill sets and shape a training program to fill gaps. As you structure the rest of the product team, think about how the skills of other team members can complement the product owner skill set so you are creating a strong blend of business, technical and leadership skills in the team. Beyond the Product Owner, you may have a Business Analyst that serves as a Junior Product Owner and supports detailed data and process analysis. A Scrum Master would drive Agile ceremonies, a Technical Lead would create a solution architecture and orchestrate technical activities, and an Engineering/QA team would ensure delivery of a high-quality product.

Define shared services to create scale

Think about IT services that are BU agnostic, needed across all product teams and in demand only on a part-time basis by the product group. These are your Shared Services. Shared Services cut horizontally across the product groups and teams. Just like products, these specialized groups endeavor to mature and develop new capabilities and empower their customers (in this case the product teams themselves).

Typical Shared Service groups include Enterprise Architecture, Infrastructure & Cloud, Security, DevOps, Customer/User Experience, Data & Analytics, Integration, Program/Vendor Management and IT Operations/Support. The Office of the CIO is an increasingly prevalent Shared Service that is responsible for defining the enterprise IT strategy, setting metrics and measuring success. Each Shared Service should publish a service catalog detailing their offerings and processes for engagement with a bias towards self-service (where possible). Shared service resources can be “loaned” to product teams if there is demand for an extended period.

Common false starts

  • Assuming everything must be product-based. When shifting to a product-based operating model, there will still be some cases where traditional, project-based teams and waterfall delivery are appropriate. Large-scale ERP migrations, for example, may continue in a waterfall fashion, or your CFO may not be comfortable with a product team making changes to the general ledger platform every two weeks. Each application of product-based IT is a unique situation and should be assessed before force-fitting a new operating model.
  • Confusing product-based IT with Agile. Many organizations will be quick to claim victory or assume they are “already product-based” because they are executing in two-week sprints. In reality, a team could be sprinting every two weeks and producing outputs that do not drive targeted business outcomes. The spirit of product-based IT lies in the continuous engagement with the customer, using agile as a mechanism to pivot quickly to meet the ever-changing customer needs.
  • Lacking product management muscles in IT. Challenges often emerge when IT starts increasing its role in setting product strategy and defining product roadmaps. Effective product managers have a pulse on external market forces and the competitive landscape. These are not skills that have traditionally lived in the IT organization. Cultivating new skills through a rigorous training program for product managers is often necessary to build brand permission with the business.

Not changing the lens on business conversations

IT often starts with feasibility and viability, approaching desirability only if the former two boxes are checked. Product managers need to start with desirability and build the ability to adapt their storyline based on the audience. Avoiding technical speak and endless strings of three letter acronyms will also go far in building this rapport.

Shifting to product-based IT is a major cultural and operational change. When done well, it can result in better relationships with customers and business partners, increased agility and improved business outcomes.

This article originally appeared on CIO.comChris Boyd co-authored the piece.

As technology departments shift from traditional project management frameworks to treating IT as a product, it is triggering a broader re-think about how technology initiatives are funded.

Under the existing “plan, build, run” model, a business unit starts by sending project requirements to IT. The IT team then estimates the project costs, works with the business to agree on a budget, and gets to work.

This setup has several flaws that hamper agility and cause headaches for all involved. Cost estimates often occur before the scope of the project is truly evaluated and understood, and any variations in the plan are subject to an arduous change control process. What’s more, funding for these projects usually is locked in for the fiscal year, regardless of shifting enterprise priorities or changing market dynamics.  

To achieve the benefits of a product-centric operating model, the funding model must shift as well. Rather than funding a project for a specific amount of time based on estimated requirements, teams instead are funded on an annual basis (also known as “perpetual funding”). This provides IT product teams with stable funding that can be reallocated as the needs of the business change. It also allows teams to spend time reducing technical debt or improving internal processes as they see fit, improving productivity and quality in the long run. 

“We have to adapt with governance, with spending models, with prioritization,” Intuit CIO Atticus Tysen said during a 2019 panel discussion. “The days of fixing the budget at the beginning of the year and then diligently forging ahead and delivering it with business cases are over. That’s very out of date.”

Business unit leaders may be skeptical at first glance: why pay upfront for more services than we know we need right now? A closer look reveals that this model often delivers more value to the business per dollar spent. For example:

  • Perpetual funding allows dedicated teams to have end-to-end accountability for the full product lifecycle, from introduction to sunset. This structure encourages teams to develop greater domain knowledge and to prioritize reusability and technical debt reduction, which can improve the technical estate and pay dividends on future iterations.
  • Rather than the business unit throwing business requirements “over the wall” to IT, business teams work directly with the product teams to co-author the product roadmap and validate the value, usability, feasibility and operational fit of an idea before it is prioritized in the backlog.
  • Perpetual funding promotes greater autonomy and empowerment since cross-functional teams are responsible for determining the best ways to invest on behalf of the business.
  • Progress is measured in terms of business outcomes achieved, and perpetual funding can be discontinued or reallocated by the business without a change control process.

Smart first steps

Shifting away from old ways and adapting a new funding model can seem like a daunting task, but you can get started by taking the following first steps:

Establish the baseline

First, establish the baseline to which you will measure the funding shift’s effectiveness. A technology leader must consider all the dimensions of service that will improve when making the shift. Two areas of improvement that have high business impact are service quality and price. To establish the baseline for service quality, it is important to measure things like cycle time, defects, net promotor score, and critical business metrics that are heavily influenced by IT solutions.

The price baseline is a little more difficult to establish. The most straightforward way we have found to do this is to look at the projects completed in the last fiscal year and tally the resources it took to complete them. Start with a breakdown of team members’ total compensation (salary plus benefits), add overhead (cost of hardware/software per employee, licenses, etc.) and then communicate that in terms of business value delivered. For example, “project A cost $1.2M using 6 FTE and improved sales associates productivity by 10%”. When phrased this way, your audience will have a clear picture of what was delivered and how much it cost. This clear baseline of cost per business outcome delivered will serve as a helpful comparison when you shift to perpetual funding and need to demonstrate the impact.   

Pilot the shift with mature teams

The shift to a new funding model will be highly visible to all business leaders. To create the greatest chance of success, focus on selecting the right teams to trial the shift. The best candidates for early adoption are high-performing teams that know their roles in the product operating model, have strong credibility with business unit stakeholders, and experience continuous demand.

In our work with large organizations piloting this shift, e-commerce teams often fit the mold because they have a clear business stakeholder and have developed the skills and relationships needed to succeed in a product-based model. Customer success teams with direct influence on the growth and longevity of recurring revenue streams are also strong candidates as their solutions (such as customer portals and knowledge bases) directly influence the degree to which a customer adopts, expands, and renews a subscription product.

Teach your leaders the basics of team-based estimation

Estimation in the product-based funding model is different than in the project model. Under the new model, teams are funded annually (or another agreed-upon funding cycle) by business units. As funding shifts to an annual basis, so should cost estimation. Rather than scoping the price of a project and then building a temporary team to execute it (and then disbanding after execution), leaders should determine the size and price of the team that will be needed to support anticipated demand for the year, and then direct that team to initiate an ongoing dialogue with the business to continuously prioritize targeted business outcomes. 

When completing a team-based cost estimation, it is important to include the same cost elements ( salary, benefits, hardware, licenses, etc.) that were used to establish your baseline so that you are comparing apples to apples when demonstrating the ROI of product-based funding. Where you will see a difference in the team-based model is resource capacity needed to deliver demand. In a product model, a cross-functional team is perpetually dedicated to a business domain, and there is often zero ramp-up time to acquire needed business and technical knowledge.

Since the teams have been perpetually dedicated to the domain, they are encouraged to take a longitudinal view of the technology estate and are able to quickly identify and make use of reusable components such as APIs and microservices, significantly improving time to market. For these reasons, among others, teams in the product-based operating model with perpetual funding can achieve more business value for less cost.

Pilot teams should work closely with the BU leadership providing the funding.  Stakeholders should work together to generate a list of quantitative and qualitative business outcomes for the year (or other funding cycle) that also satisfy any requirements for existing funding processes operating on “project by project” basis.

Talk with finance early and often

If you don’t already have a great relationship with finance, start working on it now. Your partnership with finance at the corporate and BU level will be critical to executing your pilot and paving the way to wider enterprise adoption of team-based funding models. Ideally. Leaders should engage with finance before, during, and after the team-based funding model so that everyone is in lockstep with you throughout the pilot. This alignment can help bolster adoption with other areas of the enterprise.

Each finance department has unique processes, cultures, and relationships with IT, so while you will need to tailor your approach, you should broach the following topics:

  • Team-based funding basics. Explain the drivers for team-based funding, the timeline for a pilot, the mechanics of cost/benefits estimation, and how you plan to demonstrate ROI.
  • Business sponsorship. Let finance know that you have support from your corresponding business unit. In our experience, this goes a long way in the early phases of the discussion.
  • Baseline estimation. Discuss how you plan to develop your cost/benefit baselines to make sure you are thinking about your cost estimates accurately and holistically. At the end of the day, you will need finance to nod their heads when you demonstrate the ROI of the pilot and make the case for further adoption.
  • Funding process. Define how you marry your team-based pilot with existing funding processes. This helps ensure finance has everything they need in terms of qualitative and quantitative data to support the pilot in the interim.
  • Spend allocation. Discuss any changes to team structures that may impact finance’s attribution of spend to specific cost centers.
  • Capitalization. If you are currently a waterfall shop, communicate that your pilot teams will be working in agile to maximize the benefits of the funding pilot. Emphasize the need to agree on criteria for identifying capitalization candidates in the agile framework.

Evaluating success and sustaining success

Measure success and demonstrate value

You will need to achieve success in the pilot to bolster adoption in other areas of the business. Your success needs to be communicated in terms that resonate with the business. As your pilot comes to an end, gather your baseline data and match it up with the results of your pilot. Put together a “roadshow deck” to show a side-by-side comparison of costs, resources, and business outcomes (Business KPIs, quality metrics, cycle times, NPS, etc.) before and after the shift to team-based funding.

Depending on your organization, it may be prudent to include other observations such as the number of change control meetings required under each funding model, indicators of team morale, and other qualitative benefits such as flexibility. Have conversations with other areas of the business that may benefit from team-based funding (start off with 1-on-1 meetings) and offer to bring in your partners from finance and the product teams as the discussion evolves. The most important part of your story is that the team-based funding model delivers more business impact at a lower cost than the old model.

Results governance

Establish light and flexible governance mechanisms to monitor performance of the teams operating in the teams-based model. The purpose of these mechanisms is to validate that the increased level of autonomy is leading to high-priority business outcomes, not to review progress on design specs or other paper-based milestones. A $40B global manufacturing client adopting the team-based funding model established quarterly portfolio reviews with BU leadership and the CIO to review results. BU leadership reviews results of the teams and the planned roadmap for the subsequent quarter. BU leadership is then given the opportunity to reallocate investment based on changing business needs or can recommend the team proceed as planned. 

Change management

It is important to communicate that this process requires constant buy-in from business units. While funds will be allocated annually, demand will need to be analyzed and projected on at least a quarterly basis, and funds should be reallocated accordingly. In cases where investments need to be altered in the middle of a fiscal year, it is important to note that the unit of growth in this model is a new cross-functional team focused on a targeted set of business outcomes. The idea is to create several high-performing, longstanding, cross-functional teams that have the resources needed to achieve targeted business outcomes, rather than throw additional contracted developers at teams as new scope is introduced. 

Making the shift from project-based funding to product team-based funding is a major cultural and operational change that requires patience and a willingness to iterate over time. When executed successfully, CIOs often have closer relationships with their business partners, as well as less expensive, more efficient ways to deliver higher-quality products.