Skip to content

April 15, 2021

Project to Product Transformation Case Study: Fortune 100 Apparel/Sportswear Enterprise

By IT Revolution

This study focuses on a Fortune 100 apparel/sportswear enterprise that had success incubating their model and is currently in the scaling stage of enterprise product transformation. It follows the Seven Domains of Transformation as laid out in this previous post.

Transformation Implementation 

This enterprise started incubating their transformation in their digital and customer-facing portfolios. They had strong leadership there that had previous experience moving to a product-centric model and was willing to champion a different way of working. This leader prioritized Lean value streams for their products with a relentless focus on continuous improvement. She had built strong relationships with her business partners who believed in similar outcomes.

This allowed her to build momentum quickly. She had to be bold in the early stages. For example, there was a SAFe transformation underway across the organization, and she felt strongly that it wouldn’t have the same impact as the Lean value stream or continuous improvement model. She decided to identify candidate teams across the portfolio who could try value stream mapping as an alternative to SAFe.

As this enterprise moves into the scaling stage, they are in the process of rolling this change out by portfolio, prioritizing the ones that will benefit most from the product-oriented model. They are looking at the maturity of each portfolio as well as which have the most dependencies on the transformation agenda. Based on that, they will prioritize their inventory/order management and enterprise data and analytics portfolio.

To guide them, they built a decision framework and playbook. Their scaling strategy was to essentially treat the transformation as small consecutive experiments: Assess team progress, evaluate whether what worked for one team would work for others, and validate whether it does. If it doesn’t, modify and try again.

The communication strategy was at a corporate level, not just within the IT organization. Their overall business strategy had changed to be more direct to customer, and it was important to align their overall technology transformation strategy, including the move to the product-oriented model, accordingly. They are currently on schedule to implement this new operating model across their technology organization in summer 2019.

This initiative is championed by their COO and a cross-functional steering committee, including business leadership. Many forums have been held to promote the new strategies. The details of how they get to outcomes may change, but their overall goals do not. Having said that, one challenge they have is that some teams are behind on the current messaging. This can be confusing, as teams hear different messages across the broader organization.

Choosing what to measure at scale can be a challenge. This enterprise is currently trying to optimize for speed, but defining what that looks like can be challenging. They are focusing on the measurements defined in Accelerate to start. This includes lead time, deployment frequency, MTTR, and change failure rates.

Business and Technology Synchronicity

At the company level, these efforts were branded as “digital transformation.” Given the shift in business strategy to be more direct-to-customer, the technology arm of the enterprise needed to be acknowledged as a strategic enabler of the transformation and not just a cost center. The enterprise is currently hiring their first chief digital information officer for all of technology. This company has recognized that this isn’t just a technology transformation; it is a business transformation.

This is a highly complex transformation because there are many moving pieces. With any shift in company strategy, there will be mindsets that resist change. Sometimes this is due to a lack of clarity on what people are trying to optimize for. Their new approach requires a bias for speed, but there are a lot of people who still focus only on efficiency and cost. This creates a bit of a culture clash within the enterprise between the champions of change and those content with the old model.

The entire company is now on the same performance-based incentive plan. When the company wins; everyone wins. OKRs are leveraged to drive alignment with stakeholders. Every quarter they review the OKRs. If they aren’t trending correctly, they shift. The intention is to have shared outcomes on both the business and technology side. They are currently adjusting their primary outcome from revenue to the actual resilience of the product.

With this shift, if a product isn’t performing, the business leaders (not just the technology leaders) will be accountable for the business outcomes and technology outcomes. Further, a product leader will be just as accountable as the technology leader for prioritizing tech debt reduction, security, privacy, and observability.

The product team will still own all these responsibilities. Their head of product has also advocated for these changes as there is a belief that the product team should be just as passionate and accountable for technology requirements as they are about driving features. Organizationally, this enterprise is establishing dedicated business capability owners who have a technology counterpart. They strive to have a one-to-one relationship between business product and technology leadership.

Product Taxonomy

This enterprise recognized the need for a common taxonomy as the primary organizing construct for its operating model. Everyone talked about product differently. Within this company, the term “product” usually meant what the customer was purchasing. In building their taxonomy, they leveraged their service catalog as primary inputs for the services, applications, and technologies. At this time, the enterprise is still calibrating and reconciling their catalog with their taxonomy. For example, the company’s search feature and their mobile app are both considered products. 

However, there is discussion as to whether their system application (SAP) is a product or if it belongs in a different type of category altogether given that it is heavily packaged software. Defining product, platform, service, and capability models aren’t always straightforward.

By using capability as a method of categorizing, the enterprise has been able to identify areas of redundancy that could be consolidated. For example, they accept orders in store, on a digital platform, and through partnered platforms, and previously had distinct products for each. They now have one product with three distinct experiences. They achieved this by breaking each product down into capabilities that provided actionable guidance for the distinct experiences.

Workforce and Talent

This company has established the product manager title in IT and business. The product managers in business focus on the customer experience whereas the technical product managers work on building the product. For external customer-facing products, having the experience-focused product managers in business makes sense. However, the more back-end, platform-oriented products are highly complex technically and often are not intended for customer interaction. In this case, the technical product managers own the business logic, flow, and the business rules that need to be enabled in order to realize desired outcomes.

The enterprise leaders are growing product management as a competency and career path. Also, recognizing an anti-pattern that often happens in these transformations, they are working hard to avoid taking internal candidates and moving them to another position or department without properly investing in them. Too often companies will give project managers or business analysts new titles and responsibilities but not give them the scaffolding to operate with a product mindset. The transition to product management comes with expectations. Internal candidates interested in transitioning to a project management position participate in a boot camp and extensive training process. Even with these structures, the transition can be tough. The enterprise is also growing their external talent in this space, but it is a highly competitive market.

This company is also making it a priority to increase the visibility of their work and track the reality of their work. All product team structures are visualized and observable. This visibility drives a conversation around priority and commitment. If a team is heavily indexed by operations work, for example, and the product manager is frustrated by the team’s failure to meet goals, they can use their dashboards as a fact-based way to understand why. The product backlog reflects the different work types they track, such as features, tech debt investment, operational work, unplanned work, and discovery. To aid visibility efforts, the enterprise aims to achieve a ratio of six engineers to one product manager, but this ratio is somewhat variable, and in many cases a product is too big and needs to be broken down across multiple teams.

Funding Model

The current funding model here is similar to what most enterprises use. This enterprise has a baseline budget, a set level of funding to match overhead costs. Then there are strategic enterprise initiatives that are funded above and beyond baseline. Beyond that, the business groups also have some discretionary funding they can use to fund their individual priorities.

The enterprise leaders’ goal in the scaling phase of their transformation is to move toward funding teams and products and away from funding projects. As an early move, they will stop giving business groups their own discretionary funding in summer 2019. Funding will then be centrally managed and aligned to their priorities. This will be a huge step toward transforming their operating model.

In the new model, initial funding to cover organizational capacity will be released at the beginning of the fiscal year in alignment with identified priorities, and then funding will be released quarterly based on a team’s results and learnings. The enterprise created a strategic investment committee to govern the investment process, including the outcome validation.


Within this company, the business architecture team and enterprise architecture team drove the creation of a full capability map. This served as a base for mapping and organizing their products and product teams.

In a lot of IT organizations, enterprise architecture decides centrally on new technology decisions, such as build versus buy. However, for their transformation, they felt this was not the right model and are putting the accountability and ownership of decisions in the domains. This aligns with some of the broader information we have received through our interviews as well.

Culture and Leadership

This company is transitioning to an outcome-based culture. Enterprise leaders agree that they need to move faster and use a better, more predictable delivery engine. With this goal in mind, leaders are also in agreement on needing shared outcomes, strategic prioritization, and a capacity-based team model oriented around products.

The goal at this company is to define outcomes across the organization and adopt a capacity approach with transparent work processes. Often, business stakeholders are not privy to the inner workings of a team’s process, and making such processes transparent can build understanding and trust between stakeholders and engineers. This company is currently creating a model where key stakeholders agree on shared outcomes and strategic prioritization.


This enterprise is beginning to scale their product transformation. The enterprise has a strong transformational leader who has been a catalyst for change. As her role expands, she is driving this model across more portfolios. A business strategy to drive a customer-centric model is being implemented, and there is clear alignment across the business and technology arms of the enterprise to invest in building product competencies. Additionally, there is a clear vision and plans for the funding model, which often doesn’t occur until further into a company’s transformation.

The enterprise is entering a very difficult scaling phase with a number of organizational change decisions looming in the coming months. This will be a very risky phase for the change program as leadership roles shift within the organization. The enterprise will soon have a new chief digital information officer, which will have a major impact on the direction of this transformation. As we learned through our interviews, new C-level leaders do one of two things: they either accelerate change or destroy it.

In the continuing posts in this series, we will explore each of the Seven Domains of Transformation in more detail. 

In the full white paper, The Project to Product Transformation, you will find not only the guidance indicators to create, increase, and sustain velocity, but also the negative force learnings that should help you avoid pitfalls in your transformational journey.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

No comments found

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    Go from Unplanned Work to Planned Work with Integrated Auditing 2.0
    By Clarissa Lucas

    The Scenario Picture this... You're starting your work week off just as you do…

    Announcing the Spring 2023 DevOps Enterprise Journal
    By IT Revolution

    We are delighted to announce the publication of the Spring 2023 DevOps Enterprise Journal…

    Not Just for Auditors
    By Clarissa Lucas

    Scroll through my list of LinkedIn connections or the subscribers to my blog, and…

    From Checklist Auditors to Value-Driven Auditors
    By Clarissa Lucas

    Have you ever had your auditors show up with a checklist or a scope…