TECHNOLOGY is rapidly changing the world around us and, as a result, the rules of engagement. The modern tech-infused business requires organizations to radically shift their orientation to customers and value. Leaders should adjust their operating models, ways of working, and cultures to support this transformation.
Seventy-nine percent of respondents in our 2020 Global Technology Leadership Study indicated that they have recently undertaken a technology-enabled transformation, or are considering one. In order to truly benefit from these transformations, organizations should shift their current operating models and mindsets. The product shift can allow organizations to deliver value rapidly and consistently, directly targeting customer needs. They can innovate at market speed, across the entire enterprise, and deliver sustainable results at scale.
What is a product? And how can a product focus enable an enterprisewide transformation that can help an organization not only survive, but thrive in today’s customer-focused landscape? We define a product as: “A good, service, or experience that fulfills a customer’s want, need, or desire, in exchange for something of value.” There are many methods and tools available to enterprises, such as SCRUM, SAFe, and Kanban, that can help to deliver work in a lean and agile manner. However, without the right mindset, operating model, skills, and culture to support these tools, organizations will likely not be able to reach their desired business outcomes. Therefore, a product mindset is simply a way to deliver this good, service, or experience in a way that delights the customer while maximizing the value to the enterprise.
Becoming a product-centric company isn’t another effort to simply boost efficiency or replace existing processes with new ones. Instead, a product shift typically requires organizations to rewire from top to bottom and reimagine how work gets done and delivered. It’s a step-by-step journey toward a customer-focused mindset, which can enable and empower teams beyond IT to deliver iterative value, reaching every corner of the enterprise.
In our work with many clients on this enterprisewide shift toward a product-centric mindset and operating model, we have discovered that organizations commonly struggle across three dimensions:
By successfully navigating across these three dimensions, organizations can ease into a product-centric mindset (figure 1).
Piecemeal agile methods and tools may drive performance improvements or small wins, but they often stall when met with cultural and organizational resistance. The product shift often requires an enterprisewide effort to transform the company’s mindset and set in motion systemic changes that could continuously reinforce the desired actions and behaviors. Many organizations find this journey daunting because it changes the decades-old processes, systems, and ways of working. Plus, organizations often have natural “corporate antibodies” that resist change unless it is universally supported from the top and reinforced with incentives.
That said, this is a journey well-worth taking. Here are seven tips to help organizations develop the flexibility and understanding to truly move toward a product-driven, customer-focused mindset (figure 2).
Measure value, not performance. To prioritize value, it is important to focus on the right metrics. To justify their existence or assert their control over timelines, some IT leaders may still insist on measuring activities, such as project status, uptime, or on-time, on-budget delivery, but they have little inherent value. With a product mindset, metrics such as increased market share, better customer engagement, and increased business capacity align cross-functional teams to a common goal and create shared accountability. Everyone’s collective focus is on building products that deliver tangible business value, rather than “feature factories” that pump out new features and releases. Any initiative that does not deliver tangible business value should be halted and re-evaluated. Do not get distracted—keep each team focused on the most critical strategic business outcomes.
Define products based on business objectives, not existing capabilities. Product goals should be clear, simple, measurable, and business-driven. This often proves to be a challenge in agile deployments. While it may be tempting to create products based on current technologies, capabilities, and organizational structure, it can lead to “dependency gridlock.” For example, a technology organization at a geographically dispersed energy and resource company initially defined over 60 products just for its tax function. With a new focus on real business outcomes, however, the tax function narrowed its initial list to four products. While there were slight variations to reflect local tax laws, each “product” was grounded on a global “North Star”—the accurate calculation and on-time filing of tax documents.
Empower team decision-making, rather than forcing top-down constraints. Technology teams often face three major scope-related challenges. First, executive leadership may be accustomed to predetermining cost-benefit analyses, often forcing an artificial constraint by demanding teams stick to the “business case.” Second, if there is a lack of alignment across functions, the scope may be narrowly defined. Finally, budget or business cycles may impel a change in scope. In a product-based model, however, executives are clear on the objective, then fully trust and empower the product team to define and adjust the scope, often in real time. In addition, executives are responsible for eliminating roadblocks and cultivating skills across the workforce to help teams deliver value.
Ensure product owners directly engage with customers. Many products miss their mark and some never see the light of day. This is just the reality of a complex product life cycle and too often is exacerbated by an unwillingness and fear of customer engagement. With human-centered design, a key element in product-based design, we place the customer and “experience” at the center of the journey map. In a product-based operating model, ownership is not only about technology or operations but also about deep business knowledge, and most importantly, intimate understanding of and engagement with the customer. Deloitte research reveals that high-performing companies are twice as likely to engage customers in product development. In a product-centered ecosystem, the number of layers between product development and delivery are shrunk, with minimum viable products, multiple hypotheses, and quick customer feedback loops that define future product road maps.
Identify skills and define roles based on the needs of the new model. Traditional IT teams were built on competency areas, whereas product-centered teams are developed with the right mix of skills to accomplish business objectives. However, many initiatives falter when the organization shoehorns existing roles into the new paradigm, with little consideration for competencies and no real plan for reskilling. The most common casualties are project managers and business analysts. It is important to clearly define product team roles based on needs, rather than trying to fit existing teams into the new model. Start with the necessary capabilities, identify the new roles, then look for the most competent people to fill them or plan to reskill or acquire the talent to deliver these capabilities.
Steer change management toward continuous improvement. Traditional systems, structures, and processes were built for top-down, hierarchical and functionally siloed operating models. Although operating model convergence and hybrid models are rapidly evolving, a full shift to a product mindset often requires a more intentional change management effort. Many organizations underestimate or ignore this dimension, resulting in conflicting roles and decision rights, complex governance, and frustrated talent—which often leads to attrition and the inability to meet stakeholder expectations and maximize value. Leaders should plan for the resulting complexity and set appropriate expectations to help their organizations adjust. This often includes establishing a transformation office that can oversee change management, maintain transparency, ensure continuous communication, and adjust current ways of working and culture.
Bond leadership success to business outcomes. A big component of the product shift is changing leadership behaviors and incentives, which are often steeped in the traditional IT mindset. Success is no longer defined by team or budget size, or even finishing projects on time and within budget. In a product model, leaders are rewarded for achieving business outcomes. Small teams, organized around products and driving customer-driven business outcomes, replace rigid command-and-control hierarchies. Leaders are chiefly responsible for eliminating roadblocks, ensuring clarity of purpose, cultivating skills across the workforce, and empowering teams to deliver value. This often requires rethinking performance management, incentives, and rewards, as well as adjusting expectations on key leadership responsibilities.
A product shift can be a multiyear process that changes how the entire enterprise thinks and works. Deloitte research suggests that many organizations are still at the early stages of their agile journeys; almost half (47%) of organizations have deployed agile methods in less than a quarter of their environment.1 That means navigating challenges and building momentum toward the new operating model and dealing with emerging corporate antibodies, who perceive these new ways of working as foreign interference that doesn’t consider cultural norms and decades-old processes or operating methods.
Once the product shift starts to take hold and moves beyond a handful of product teams, leaders have to grapple with a hybrid environment, where parts of the company still rely on a traditional, project-centric IT mindset. Some IT work, of course, will always be more efficiently delivered through projects. A natural tension, however, may arise in a number of areas: Finance, for example, will likely have to balance budgets across mixed models of product and project life cycles. It may need to move away from an annual-budget cycle (potentially no-budget cycle at all) and determine how to handle funding across systems and technologies that constantly iterate. Human resources, meanwhile, should change how it evaluates performance, reconsider the way it defines roles, and help create organizational models where the reporting structure may not be apparent. Procurement may need to revamp its processes as well, such as enabling flexibility to pivot to more effective ways to achieve defined outcomes.
To shift to a product mindset in a hybrid world and overcome the corporate antibodies, the organization should commit to four changes.
Recharacterize technology budget as investment portfolios. Today’s rapid pace of change in business and technology makes it impossible to predict an organization’s priorities, or the proper allocation of money and resources, a year in advance. In a product-based mindset, resources are allocated to the highest-value business outcomes. This does not mean that organizations don’t have a budget or financial planning. A product-based operating model allocates budgets based on short-term incremental outcomes and on the value delivered. One CIO, for example, runs all major projects through a leadership team review every quarter, akin to “Shark Tank,” to evaluate outcomes and justify future spending. This CIO reports an unprecedented 96% success rate for additional scope and funding for his projects. This ability to shift investments and reallocate funding when business priorities rapidly change—the current pandemic is a perfect example—can offer organizations tremendous flexibility and agility.
Judge performance on team goals and shared outcomes. Traditional IT is built on pillars of competency, with clear delineation between teams, such as applications and infrastructure, networks and service desk, project managers and architects, and so on. A product-based operating model offers incentives to collaborate and share within and across teams. It breaks down traditional domain barriers and holds the collective team members accountable—not just for completing their tasks, but also for delivering integrated business outcomes. Team goals take precedence over individual goals. Feedback is ongoing and comes from multiple sources.
Strategically tackle technical debt to help ensure agility. Technical debt is a term that refers to the intentional or unintentional violation of optimal coding or architecture practices and it manifests in concessions or shortcuts in software and architecture that may need to be paid back later. Products built from the ground up on Agile principles, continuous delivery, the build-measure-learn feedback loop, and automated tests minimize technical debt. Ultimately, the product team is responsible for addressing tech debt for their product, irrespective of the source.
The core issue in a hybrid world is often dealing with legacy applications on outdated platforms, out-of-support versions of software, and old architectures. Organizations should have a clear strategy to deal with this issue, or they may be bogged down by it. Despite the best of intentions, there will never be time available for teams to address technical debt—new work will always take precedence. Establishing a cadence for making this part of their normal workflow by dedicating a percentage of development teams’ time to addressing it is the only viable option.
Use architecture to ensure consistency and collaboration. It is important to reimagine architecture—not as an ivory tower focused on policy and compliance, but as a digital blueprint and organizational asset, facilitating modularity and flexibility for current and future technology deployments. Many organizations mistakenly do away with the enterprise architecture function when implementing the product shift, leaving a vacuum that leads to a lack of consistency and collaboration. In the hybrid environment, where product and project teams are working independently, architects are needed to overcome silos as described in Conway’s law (organization’s systems mirror its communication structure). By decoupling from the organization’s silos, teams can constantly communicate and collaborate, thereby avoiding siloed enterprise systems.
Enterprise architecture also should be the bedrock of change, sharing practices among product teams and the bridge between the product and project worlds. It is ultimately responsible for ensuring the scale, agility, modularity, and infrastructure that enables independent products to operate and flourish. In the hybrid world, the key is to establish guardrails and trust product teams to execute.
No matter how many agile initiatives are implemented and processes are changed to adjust the mindset and push back against corporate antibodies, perhaps the most critical step toward a product-driven enterprise is changing the culture, organizational roles, and talent skill set. However, merely putting a new label on old roles and structures will likely not suffice to achieve the desired benefits. In a recent Deloitte study, technology leaders anticipated that only 67% of their current staff will be relevant based on their current skill set.2 The product shift requires evaluating current skills against desired ones, rethinking the underlying organizational structure, the way people and financial resources are allocated to work, and encouraging behavior change through rewards and incentives. Those companies who have intentionally made the following seven essential adjustments have achieved the most measurable results.
Become an adaptable organization. In a product-based operating model, the enterprise can respond to shifts in business priorities and unforeseen marketplace challenges. This is a fundamental change in the operating philosophy. It underscores an adaptive ecosystem that has a customer-focused purpose, a flexible organization design (underpinned by thoughtfully formed teams), prepared leaders, and individuals who can adapt, supported by talent programs. An organization is part of a larger ecosystem that includes partners, vendors, and suppliers. An adaptable organization connects them all to a common purpose—customer and market needs. The organization uses network-based teams to carry out its mission: That is, the team delivers mission-defined work through efficient, agile work processes; the leader is an enabler of people (rather than a gatekeeper); and individuals are empowered to craft their own careers and align with their individual purpose.
Focus on incentives and learning. Organizations may never get to the root causes of challenges if there is a danger of blame or retribution. Techniques such as blameless root cause analysis can encourage early problem detection and bold decisions. A rewards, recognition, and incentives program can detect failure points early, leading to reduced costs and less rework (thereby also arresting future technological debt). Many high-tech companies have used the “fail early, fail fast” approach to drive innovation and continuous improvement to achieve key business outcomes. Even when failing early and fast, the organization should view unsuccessful attempts as learning exercises and reward the desired behaviors, such as being bold, ideating, and driving both formal and informal value. It is as essential to recognize and reward these desired behaviors in communications, meetings, and leadership readouts as it is to include them in the formal performance management process. This can demonstrate visible leadership support and highlight model actions and behaviors.
Stakeholder accountability is essential for value delivery. A common reason for not achieving the desired value from a product shift is that business and technology organizations are not held accountable and lack commitment or engagement. For example, among organizations that have implemented agile methods and tools, almost a third (31%) indicate that Agile has changed tech delivery, but the business still doesn’t understand it.3 The product model should define new roles, interactions, accountabilities, and decision flow. Orienting products around the customer can drive accountability down into the organization and enable stakeholders to fund, resource, and unlock performance and value.
Emphasize soft skills, not only technical skills. The 2020 Global Technology Leadership Study reveals CIOs increasingly seek talent with soft skills, including emotional intelligence, cognitive flexibility, and creativity (figure 3).4 As business functions hire more technically savvy staff and IT cocreates with business partners, interpersonal skills and business knowledge become increasingly critical. Traditional tech skills remain essential to deliver value, but are more readily available in the talent market. Companies that truly differentiate through value-based products place a premium on understanding and defining the value.
Focus on continuous improvement more than daily work. As teams become focused on products and on customer journeys, constantly improving the way work is done becomes more important than traditional ways of doing daily work. Artificial intelligence and automation can help perform repetitive daily tasks more efficiently, so workers can spend more time on process improvements, better governance, and access to decision-making. Rewards and incentives can reinforce these behaviors. Successful teams align, collaborate, and break down internal barriers to maintain their focus on continuous improvement in order to create value. Individual performance relates to team impact and, ultimately, product value.
Support distributed decision-making. Traditional organizational models include hierarchies that structure how work flows through the entire system, from the broader enterprise through the organization, leaders, teams, and the individual. In a product model, there is a shift from command and control to trusting teams to make necessary decisions to streamline workflow. Teams should be held accountable for their decisions based on value generated and the results created. They are responsible for presenting their decisions and the value created to all stakeholders on a regular basis. The organizational model should not be a bottleneck. This adjustment speaks to the “empower teams with decision-making” tip discussed earlier.
Business leaders require technical acumen. Today, leadership teams and business decision-makers often require technical acumen and savviness. This is the new normal and the speed of technological change mandates a more sophisticated and integrated narrative, where business and technology converge to create value and differentiation. For example, there are an increasing number of new roles with responsibility for technology that may not be a part of IT, such as the chief technology officer, chief digital officer, and chief transformation officer. These roles sit closer to or within business areas and create the opportunity for technology leaders to step up and lead beyond the role of IT within the organization, increasing technology enablement in the business and out to the customers.
A technology leader in the financial sector saw a variety of marketplace changes altering the industry landscape. They knew that to unlock future success, they needed to become an agile, adaptable company. As the entire enterprise started down the path toward a customer-focused product operating model, they quickly learned five critical lessons that informed their efforts.
CIOs lead unique and complex lives—operating at the intersection of business and IT to deliver value to their organizations. To help CIOs manage these challenges and issues, Deloitte has created the CIO Program. The program provides distinctive offerings to support the CIO career life cycle through leadership development programs, immersive lab experiences, insight on provocative topics, and career transition support to complement the technology services and solutions we provide to our clients.Learn more