Product Taxonomy: The Seven Domains of Transformation

Why Is Product Taxonomy Important?

Shifting to a product operating model starts with defining the products, which includes both internally facing and externally facing products. Defining the products is essential to identifying clear lines of ownership and accountability, and redesigning the organizational structure to align with customer needs instead of settling for traditional organizations that align around IT functions.

When looking across the fourteen companies interviewed, it became clear that this domain is the most ambiguous and lacks industry guidance on how to define product taxonomy.

The other pattern observed is that this level of product definition typically occurs during the scale stage and then is continuously refined based on key learnings throughout the optimize stage. Below, we provide emerging best practices that have been successful with companies that have progressed through the scale and optimize stages of product transformation.

Benefits to Defining Product Taxonomy

A product taxonomy provides enterprises a visible, centralized method for defining, managing, and tracking products across the company’s value streams. There are multiple benefits to defining the product taxonomy:

• Helps provide product visibility across business areas, revealing redundancies, dependencies, and value flow.
• Provides a common language for products within an enterprise, minimizing confusion between technology and the business.
• Provides clarity around product types, stages, whether the product is legacy or new, and whether it is strategic.
• Sets the stage for accountability and clear ownership of products. This creates a clear path for new features and support incidents. A product owner will continuously communicate product vision, strategy, and outcomes-based goals, synchronizing with other product leaders and ultimately driving toward enterprise goals.
• Creates awareness of workforce needs when the scope of products is unbalanced with the availability of product managers/owners from the business and engineering talent.
• Enables an enterprise to organize around customer needs instead of technology, applications, or IT functions.

What Is a Product Taxonomy?

To transition to a product operating model, you should first define your product taxonomy. The product taxonomy identifies the portfolio of products that exist in a given business area. The taxonomy helps to show the hierarchy and relationships between the different products and capabilities that exist within your business.

Given their scale and complexity, enterprises often need a visible, centralized method for defining, managing, and tracking products across the company’s value streams.

What Is a Product?

To fully understand how to map a product taxonomy, we must first anchor to a few basic definitions for what a product is and how to classify different product types.

To define it simply for our context, a product is a software offering that we create to deliver value to our customer. By this definition it is implied that we know who our customers are; we understand what they value; we understand the ecosystem or value stream within which the product fits; and we design, build, and support our product as a cross-functional, long-lived team with the skills needed to own the product end to end. Meaning, if we design and build it, then we must also maintain and support it throughout the life of the product (in other words, “you build it, you run it”).

Sign up for the IT Revolution Newsletter to read more articles like this one.

Product Life Cycle

Products can serve external customers and/or internal enterprise customers. Products can be differentiated by designating a product classification and product life cycle stage. Unlike projects, products do not have a predefined end date. Instead, a product moves through life cycle stages. The life cycle stage and product classification definitions provided in this series are suggestions intended to provide guidance.

The figure below shows the product life cycle stages and we will go into each of them in more detail below.

• Incubate
• Invest
• Sustain 
• Sunset

Incubate

The product is a new idea or hypothesis that is rapidly being tested through product discovery, prototyping, and potential deployment of a minimum viable (or lovable) product (MVP or MLP). The goal of this stage is to quickly validate or disprove the value of the product idea. Exploratory product discovery may include a potential new business idea or model, a new technology set, or a customer opportunity space. Learning from failure is typical in this stage.

Invest

The value proposition of a product has been validated via a deployed MVP. A permanent persistent product team has been formed containing all the necessary skill sets to continuously design, build, and support the product based on rapid customer feedback loops. Product outcomes are measured regularly (e.g., quarterly) via clearly defined objectives and key results (OKRs).

The product team continuously builds new features, proactively solves customer problems, and supports their product in production. Team pace, product use, and value are optimized based on customer and employee satisfaction, product stability and quality, and speed and adaptability.

Sustain

The pace of necessary new features has tapered off. The majority of the required functionality for the product has been accounted for. The team is primarily maintaining product quality and stability while minimizing maintenance costs.

Sunset

The product is no longer needed or wanted and the market or customer demand for the product begins to shrink; therefore, the product begins an end-of-product life stage. This is often referred to as the decline or sunset stage. The team works to remove or transition users to an alternate solution while decommissioning the product.

The Product Taxonomy Structure

The structure of a product taxonomy considers three levels or groupings of products.

The first level is the product portfolio, which is a collection of product groups whose value deliveries share a high degree of dependency.

The second level is the product group, which is a collection of related products whose value deliveries share a high degree of dependency.

Lastly, the products are persistent groupings of applications, technology, talent, and data that enable a specific outcome, customer experience, or capability.

When defining the product, focus on the outcome or customer experience it delivers rather than the application or technology that delivers the outcome or experience. Consider why a customer turns to your product or service and what problems it solves for them and evaluate that experience as the product.

The technology or application is merely a vehicle for delivering that customer experience. The product should remain consistent year after year, whereas the supporting technologies will change over time as new solutions emerge. See the below figure for a representation of the product taxonomy structure.

Product Types

Product types should be considered to help further differentiate your products. Does your technology product serve an external customer? Does your product enable other technology products within the enterprise? Is your product a shared service consumed by an end-user, business function, or another service?

Ultimately, everything can be considered a product leveraging modern product management practices delivered by a long-lived product team.

As we assessed the various companies we interviewed, the topic of inward-facing versus outward-facing products often came up. Inward-facing products were referenced as “IT products for IT” and outward-facing products were considered business products. This table shows a few examples of product types with corresponding goals and examples.

How Are Enterprises Achieving Success?

The companies we assessed appeared to struggle most with the product taxonomy domain; this domain appears to cause the greatest gap in transformation success due to the lack of documented references on how to map an enterprise product taxonomy.

The natural starting point for most companies we interviewed was to anchor to business capability frameworks. Others leveraged their configuration management database, service catalogs, value stream maps, experience maps, or some combination of these tools. This section intends to map out how to work through this process.

Design a Product Taxonomy

The following are emerging best practices for designing a product taxonomy. This guidance is based on the experience from multiple companies in differing industries that have had successful transformations. Of the companies interviewed and researched, all companies in which we identified these practices were either in the scale or optimize stages of the product transformations.

These tactics are intended to provide guidance and to suggest approaches, tools, and techniques to help construct conversations that move the organization to a product-centric operating model. These steps are not a precise framework, nor are they linear or all-inclusive; rather, there are many ways to have these conversations. Appreciate that every company is at a different point in this transformational journey toward being more customer-obsessed, Agile-minded, and product-centric.

Below is a table of the tactics we suggest. We will go into each tactic in more detail below.

Sign up for the IT Revolution Newsletter to read more articles like this one.

Tactic 1: Define the North Star for the Portfolio

The north star is a shared purpose and vision that helps leaders and teams feel personally and emotionally connected. When we face adversity, this is our motivation to persevere. This is also a reference to validate that the activities we are executing are aligned with where we want to go.

Who Should Be Involved?

Technology and business leaders for the portfolio. It’s recommended that technology and business leaders meet and align their goals at the beginning stages of mapping a product-centric operating model. Establish alignment and shared understanding across the leaders and then with the teams. Gather feedback from the teams and adjust as needed. What resonates with them? What doesn’t? Make the north star relatable using clear, friendly language; steer away from too much corporate buzzword lingo that makes the vision unrelatable.

Leading Questions and Considerations

• What is our purpose?
• Where do we want to be?
• What does our future architecture look like?
• What outcomes do we want to achieve?
• What does success look like for our portfolio of products one year from now?
• What is painful today?

Suggested Tools and Tactics

• Portfolio/product community map (a Venn diagram map displaying product dependencies, customers, and stakeholders)
• Personas or customer descriptions (who are they; what do we know about them, their pains and joys; how can we deliver value to them; what assumptions are we making?)
• Outlook or outcome-based roadmap
• Product charter (what, why, who)
• Objectives and key results (OKRs)

Tactics 2 and 3: Map the Taxonomy of Products and Map the Technologies to Products

Value stream mapping, or experience mapping, is an ideal place to begin this conversation. Visualizing the customer experience end to end (from concept to cash, or product creation to customer delivery) will provide key insights into what products should be in a portfolio.

Engage a coach or facilitator if possible to keep the conversation moving and neutral. A neutral facilitator can help drive collaboration forward effectively, especially when ownership battles or redundant capabilities begin to surface, which can happen quite often.

Other supplemental approaches include leveraging existing service catalogs, configuration management databases, or business capability frameworks as relevant ways to kick off the product taxonomy definition. The key is to find a comfortable starting point to begin the product taxonomy definition conversation.

Who Should Be Involved?

• Technology and business leaders for the portfolio

Leading Questions and Considerations

• Why does your team/space exist?
• What capability or customer experience are you enabling or delivering?
• Who are your customers?
• Why do customers turn to your team for help? What problems do you solve?
• What are the applications or technologies that deliver or facilitate that customer experience?
• What are all the applications that your team is responsible for?
• Why do the applications exist? Do they each deliver a common experience or is there room for consolidation, sunset, or realignment of an application to a different team? What customer problems do they solve? How long have they been in existence?

Suggested Tools and Tactics

• Value stream map (on a whiteboard, collaboratively, face to face if possible)
• Value stream integration (implementation of the mapping exercise)
• Product community map (Venn diagram map displaying product dependencies, customers and stakeholders)
• Customer definition (personas)
• Product taxonomy document 

There are a couple of suggested approaches to defining your product taxonomy. Once the value stream map is constructed, additional layers can be added below the value stream to identify product groups, products, and applications.

You can begin from the top at the portfolio level and work your way down to the applications. Start at the highest level, breaking it down into smaller chunks based on the value stream or customer experience. Leverage the leading questions above to facilitate the conversation. A recommended approach is to start at the application layer and work your way up to products (customer experiences) and product groups as in the figure below.

Tips For Creating a Product Taxonomy

• Use business-friendly language when naming your products. Do not use acronyms or ambiguous names. Anyone should be able to read your product taxonomy and understand the experience the product delivers.
• Ensure that you have defined both internal and external products and that each product has a customer specified.
• Focus on the business and customer outcome, capability, or experience the product delivers, not the application used to deliver it.
• Remember that products will likely remain consistent year after year while the technologies and applications will always change as new solutions are implemented.
• Ask the “5 Whys” to ensure the root of the experience is found; this can be a helpful technique when the application becomes the primary focus.
• Get feedback from your business partners, coaches, team, and peers.
• Expect an imperfect path. Pick a starting point and implement. Learn from the first iteration of the product taxonomy and be comfortable adjusting it quarterly or annually as needed.

Product Taxonomy Artifact

The product taxonomy should be a shared artifact that provides transparency across the various product portfolios. The artifact should be maintained by a centralized team to ensure consistency and safety of the information. Publish updates to the taxonomy on a quarterly or biannual cadence. The table below shows a template of a product taxonomy.

Tactic 4: Map the People to the Products

A well-defined product taxonomy will serve as a blueprint for how to redesign the organization around the products. A fundamental shift when transforming to a product-centric operating model is structuring teams to own the products end to end. In a traditional project model, the teams are organized temporarily to achieve specific project goals and then disbanded, leaving no formal owners for what was created during the project. At the heart of the product model is ownership, accountability, and empowerment.

Teams should be small sized (approximately five to ten people) and cross-functional, containing all the skills needed to plan, design, build, and run the product. Consider the number of product teams who will be needed to support a product. Ideally, the product-to-team ratio should be one-to-one; however, it is possible to have multiple teams supporting a product. To determine the number of teams needed, the scope and scale of the product should be assessed based on historical data, overall demand, complexities, and dependencies.

Assessing multiple teams against a product is part art and part science. It’s recommended to start on the conservative side and scale to additional teams as needed over time. Additional details on product roles, product team characteristics, and other workforce considerations are provided in the Workforce and Talent post in this series.

Who Should Be Involved?

• Technology and business leaders for the portfolio
• Human Resources

Leading Questions and Considerations

• What skills and roles do you have currently? Are there gaps?
• How many teams will be needed to support a product?
• Is the product manager/owner identified? Do they come from the business or technology organization? Why?
• Do you have traditional project family or functional roles (e.g., project managers, business analysts, process or functional analysts, testers) that need to be eliminated or repurposed into product roles (product owner, scrum master, UX, engineers)?
• Is there an opportunity to automate manual tasks (e.g., testing, processes, repeatable functions)?
• How many layers of management does your organizational structure have? Are there redundancies? Do you need to reduce the management structure to enable flow and team empowerment?
• Is additional training or coaching needed to skill-up in product management and modern engineering practices? How will learning opportunities be provided?

Suggested Tools and Tactics

• Full-stack product teams
• Skills matrix or assessment (map the skills and people you have and need and assess for gaps)
• Industry definitions of product team roles (anchor to these as much as possible, and don’t try to create new roles that will over inflate the size of the product team as this practice will also make it easier to hire externally as needed)

Tactics 5 and 6: Identify any Gaps or Blockers and Establish an Action Plan

Transparency of gaps or blockers that could derail the product transformation is critical to transformation success. Decisions will need to be made regarding how to address the gaps and blockers. As each portfolio works through the process of mapping their product taxonomy and designing the teams, common themes may begin to emerge across the enterprise. These common themes should be addressed holistically to ensure consistency with the implementation of the product model.

Who should Be Involved?

• Technology and business leaders for the portfolio
• Teams
• Other key partners such as Human Resources, Finance, Learning & Development, Agile & product coaches

Leading Questions and Considerations

• What blockers, risks, or constraints do you have to work through to move your organization to a product operating model?
• Who can help with the solutions?
• Is the funding model product-driven or project-driven?
• Are there redundancies within or across the organization?
• Are there political debates about who should own what?

Suggested Tools and Tactics

• Establish an action plan to resolve the blockers and align clear ownership to each item.
• Manage the work through a transformation backlog or kanban board.
• Maintain transparency by keeping the blockers and actions visible to all involved
• Sustain momentum by forming a transformation team of leaders who will continuously work through transformation backlog.

Tactic 7: Coach and Accelerate New Product Teams

Once the teams are formed, provide them with coach support to launch and accelerate optimization. Additional guidance on how to coach and accelerate teams is provided in the Workforce and Talent section of this paper.

Who Should Be Involved?

• Technology and business leaders for the portfolio
• Teams
• Other key partners such as Human Resources, Finance, Learning & Development, Agile & product coaches

Leading Questions and Considerations

• What blockers, risks, or constraints do you have to work through to move your organization to a product-centric operating model?
• Who can help with the solutions?
• Is the funding model product-driven or project-driven?
• Are there redundancies within or across the organization?
• Are there political debates about who should own what?

Suggested Tools and Tactics

• A team of Agile technical coaches to continuously teach, mentor, and coach the leaders and teams.
• A product charter for the team to to clearly define the product, articulating a clear product description (or elevator pitch) of what the product is, the business/customer value it provides, and a clear definition of the customer the product serves.
• A product community map (stakeholders, customers, and dependencies) and personas.
• A team working agreement that defines the team’s own routines, best practices, and agreements that will optimize their productivity.

Constraints That Need to Be Overcome

The product taxonomy is the starting point for shifting mindsets from a project and functional silo organization to a customer-focused product organization with clear lines of accountability. The exercise of mapping products drives leaders to think differently about their organizational structure, accountability boundaries, customer-focused outcomes, and overall alignment to business strategies.

Through our interviews, we learned that the following constraints surfaced when the product taxonomy was missed or underutilized:

• A lack of clear product definition and product mapping: This leads to excessive overlaps or redundancies across teams. Establishing a clear product taxonomy within each portfolio enables transparency across the organization. Redundancies or overlapping accountability boundaries become more visible when all products are outlined in a centralized taxonomy. Having this transparency helps leaders see where they need to connect to resolve the redundancies.
• Fixation on Agile frameworks without a focus on products: This will delay or negate the shift away from the project operating model. Ultimately, project mindsets that focus on temporary teams executing on time, scope, and cost will persist, and the full benefits of the product model will not be realized. An alternative is to empower teams to self-organize around the processes or frameworks that work best for them, rather than mandating a specific framework. Too much bureaucracy will derail the shift to empowered product teams.
• Lack of clear product ownership and accountability: This will eventually paralyze an enterprise due to internal politics delaying value to the customer. Without a clearly defined product taxonomy, redesigning teams to become full-stack product teams will be challenging, as there will be no clear boundaries around what the teams should own. Leverage value stream mapping and product taxonomy to drive conversations across conflicting product boundaries. Engage business and technology leaders to identify product owners for each product and empower them to fully define the product, scope, and boundaries.

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

• Seven Domains of Transformation
• Transformation Implementation
• Business and Technology Synchronicity
• Product Taxonomy
• Workforce and Talent
• Funding Model
• Architecture
• Culture and Leadership

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

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

• 
• 
•