There are many ways to define the concept known as ‘product’. One of the simplest (and therefore one of our favourites), is that a product is an offering that delivers user value, or facilitates the delivery of value. This definition clearly establishes product as far more than just technology and positions a product as something that can act to deliver an outcome.
However, like most definitions of product, it’s a little bit fuzzy.
For example, components of things (whether classed as products, capabilities, services, etc.) will often be decomposable themselves, which can create hierarchies of components. Products are the same, in that one product could be made up of multiple smaller products.
An e-commerce app may be classified as a product but be broken down into smaller components such as catalogue, basket, payment, account. Each of these may also be classified as a product.
Additionally, not all products may be the same. A classic example of this is our thinking on products and platforms, or Omar Sallam’s thinking on ‘Data as Product’. ‘A set of capabilities’ leaves lots of room for interpretation.
So, amongst all this fuzziness, let’s look at how we can design a good product taxonomy.
Taxonomy design and validation
Ironically, product managers are normally not the best people to design a product taxonomy. The skillset is quite different, and it is not even something that product managers would often have the opportunity to do. Taxonomy design is a pretty tricky topic, and is normally the domain of the enterprise architect.
However, regardless of who designed it, we have a proven set of principles (and you know we love our principles!) that can help you test whether your current taxonomy is good, or if it's bad.
- Asset / outcome focus: products should be focused on a clear business goal / set of outcomes (to ensure that products are offerings that deliver user value, or facilitate the delivery of value).
- Encapsulation: products should have clear ownership of their constituent systems and processes (to reduce dependencies on other teams).
- MECE: mutually exclusive and comprehensively exhaustive (to avoid duplication / conflict, and ensure all scope is fully covered).
- Manageable: products should have a manageable internal complexity and number of business stakeholders (to reduce complexity for the business).
- Canonical: products should contain a coherent set of services that are stable over time (to reduce ‘internal’ complexity).
Common challenges
If your product (or entire product taxonomy) passes all of the above principles, you can assume that it is good. But if it doesn’t, you can be confident that you are not alone: the majority of the product taxonomies that we come across are not architecturally sound.
And whilst taxonomies often break different principles…it is #2 and #3 that fail most often. Especially in big companies.
Achieving encapsulation is tricky when you run big monolithic systems, or have a functional department structure where nothing can happen without input from multiple departments.
This is why building good product functions is not a tech problem, it’s a whole business problem.
