What’s the issue?
We work with lots of companies and when we ask “Do you have a product taxonomy?” the response is “…er….a what!”.
However, we find that many organizations have challenges with how they define, manage and track products. This seems particularly true in big, B2B technology companies with complex products and services. Different parts of the business use different terminology. Or worse still, the same term means something different to different people.
It’s even harder when the company delivers a mix of products and unique solutions to customers.
A product taxonomy
We believe a product taxonomy can really help.
It shows the hierarchy and relationship between the different elements and capabilities that exist in your business. It helps define what can be sold, who is responsible for managing each element and who owns functions like delivery and support.
We’ve developed a Product Taxonomy as a starting point for you but you’ll need to adapt it for your organization – one size does not fit all!
You can download a free copy of the infographic below.
In our reviews and assessments, we’ve seen many companies that do not have a product taxonomy and we’ve seen many situations where one would help. For example…
Poor clarity on what is actually sold to customers
If you take something is it clear that it’s a product, a product component, an enabler or a service? And would everyone in the organization have the same view?
We worked with a large Services company that had multiple products being sold (and delivered). Senior management had already decided some of these were not to be commercially available any more. However, this had not been clearly communicated across the business. The Sales teams kept selling them. They didn’t have a Product Catalogue with the definitive picture of what they should and shouldn’t sell. And the impact on the business was significant. It was costly and time consuming to support these products and then manage the migration of customers onto the replacement products.
Confusion on who ‘owns’ the product
Sometimes it’s just not clear who owns the product. It’s not clear who should get the requests for new features and make the priority calls. We’ve seen this compounded by confusion about who does what in the Product Management and Agile/Scrum Product Owner roles.
We’ve also seen many situations where responsibilities and accountabilities between Technical, Product Management, and Services teams were not clearly agreed – creating overlaps and confusion.
We did a review for a large instrument manufacturer. Sales took their customer requirements directly to the technical team and Product Owners – bypassing product management. These roles reported straight into the technology area and things were added to the product backlog without any review by the Product Manager. The impact was that resource was being diverted away from potentially more commercially important and viable features.
Un-balanced match of product managers to products
Now and again we see low-level capabilities or enablers being managed by commercial Product Managers – when product management resource is really scarce within the business.
We worked for a Telco with a reporting and analysis capability that was being used to support multiple other products. It had a highly skilled Product Manager supporting it, yet some commercial and revenue generating products were without any product management support. Opportunities to generate genuine incremental revenue were being missed.
Too much focus on products that customers don’t value
We’ve often seen too much focus on trying to generate revenue from products that are the foundations for other products or services but with little customer-perceived value. If customers can’t see why they should buy a product it creates problems for Sales and confusion as to why the product is being pushed by the business.
We worked with a Logistics company that had a reporting capability that they wanted to become a chargeable service. Unfortunately, it wasn’t really valued by the customer base. It turned out to be more down to the Product Manager who was pushing to have a revenue stream rather than a sound aligned commercial strategy for the market and customers.
Multiple products and platforms doing the same thing in markets
Many large multi-national companies appear really disorganized. They have multiple products and platforms doing the same thing in different markets with little view of which are the legacy products (that need to be retired) or the strategic platforms (that need to be supported).
A global technology company we worked with had acquired multiple companies in different countries so had multiple platforms and products servicing the same customer set. It was hard to see which were the strategic platforms and which were the legacy platforms.
Strong product portfolio management was missing. This (and company politics) meant that opportunities to rationalize the product set (and save costs) were missed. It also meant that product investment decisions were not optimal.
Too much bespoke/custom work
One thing we’ve seen happen again and again in large organizations that are Sales led is multiple variations of a solution being sold to different customers without full consideration of the support costs or the impact on other things in the roadmap. Managing multiple code streams and versions, re-jigging different roadmaps and supporting these complex unique solutions creates a huge strain on the organization.
In response, we’ve seen many companies push to do things in a more repeatable, reusable way by creating the different elements you see in a product taxonomy. So less unique projects and more ‘build once, sell many times’ products. This improves their economies of scale and ultimately their profitability.
A formal product taxonomy to define things
We believe a formal product taxonomy can help you solve many of these issues. It explains the hierarchy and relationship between the different capabilities that exist in your business. It helps define what can be sold. It helps define which team is responsible for managing each element and who owns activities like delivery and support.
What to do
There are a number of steps you can take to think about your product taxonomy:
• Define – clarify what products and propositions are being offered to customers. Also, which elements are not visible to customers but essential for delivering your products and services.
• Structure – logically structure the elements that you have within your organization and technology stack. For example, which elements are common for many products but not specifically visible to purchase by customers.
• Ownership – consider who owns various elements across the organization – Product Management, Technology, Operations, Support, Services, Technical Sales Support, etc.
• Publish – use the taxonomy as the basis for your Product Catalogue i.e. the definitive source of what can be sold to customers. Product Managers are typically responsible for keeping the information about their product up to date in a Product Catalogue. It means that Sales know they have only one place to go to find the answer to product questions and so hassle Product Managers less.
• Educate and train – communicate across the organization the output from your work on your Product Taxonomy and Product Catalogue. Run training sessions or webinars for Sales. This helps to create a consistent understanding across the business.
Why this is good?
The are lots of benefits to adopting this disciplined approach to your offerings including:
• A better focus on clearly defined customer offers that generate revenue based on customer value
• Improved allocation of scarce commercial product management resource
• Clarity around strategic vs legacy products and platforms
• Help in the adoption of consistent and transparent prioritization frameworks
• Clarity for Sales on whom the request for changes and features should go to
• Better ownership and proactive management of internal products, platforms, and enablers
If you think we can help you in this area, please get in touch at firstname.lastname@example.org.
Product Focus Senior Consultant