This publication is broken up into three sections:
TL;DR - For those wanting a quick take
Summary - For those wanting a bit more context and high level points
Article - Main body of work containing full detailed article and explanations that you might want to consume over several readings
TL;DR
Most organisations that develop repeatable and scalable offerings and business models, will at some point have moved from being a single product company to being a multi-product company
Great operators, who have moved from being a single product company to becoming a multi-product company, have defined a product taxonomy. Upon Steve Job’s return to Apple he drew a 2 x 2 to help define the Apple Product Universe which at that time had grown to unmanageable levels due to a lack of focus
There are a couple of benefits to developing a product taxonomy. A few of the main benefits are listed below:
Create a shared high-level marketecture view
Define a common shared language
Focused positioning and messaging content
Integrated messaging across marketing collateral and channels
Consistent packaging and pricing framework
Defining a product taxonomy is an important start but your organisation needs to use the taxonomy to design a marketecture which will frame how you want to present your offers to the market. A marketecture is a non-technical representation of solutions, products, systems, services and how they interact and relate to one another
A marketecture should align stakeholders on how products and/or services work together to orchestrate a solution to a problem or experience
Just as maps are incomplete and do not represent reality since they are limited mental model of the world; a marketecture also does not map reality completely
Summary
One of the worst places to be as a product development person is in an organisation where there is no shared understanding of what a product is and how features should be mapped to product outcomes or end-user or customer value and how the various items should be packaged into a coherent offer or offers
In my time developing product one of the failure modes I have seen is product developers and the rest of organisation by implication not being clear on the value they create and how they monetise value exchange with their customers. The reasons for this are broad and varied. The reason I will focus on, is there being no coherent structure on how to design the product portfolio to track value this usually happens because an organisation is unwilling to spend time or resources or is unable to develop a product taxonomy
Most organisations that develop repeatable and scalable offerings and business models will have at some point moved from being a single product company to being a multi-product company. Becoming a multi-product company is a strategic question requiring real thought and consideration from a company leadership team specifically Product Leaders
Great operators at some point on their journey to becoming a multi-product company have defined a product taxonomy. Upon Steve Job’s return to Apple he drew a 2 x 2 to help define the Apple Product Universe which at that time had grown to unmanageable levels due to a lack of strategic focus
A product taxonomy enables you to make sense of your end-user or customer landscape or eco-system in a structured way that enables you to align product visions and strategies that are meaningful and pragmatic. A good taxonomy can be used as a mechanism to get a feedback system going between product vision, strategy and execution especially in the light of a changing system
There are a couple of benefits to developing a product taxonomy. A few of the main benefits are listed below:
Create a shared high-level marketecture view
Define a common shared language
Focused positioning and messaging content
Integrated messaging across marketing collateral and channels
Consistent packaging and pricing framework
Defining a product taxonomy is an important start but your organisation needs to use the taxonomy to design a marketecture which will frame how you want to present your offers to the market. A marketecture is a non-technical representation of solutions, products, systems, services and how they interact and relate to one another. It is used to unify the various components of a Solution, Product, Service or Platform into a visual format
When used well a marketecture forms the structure for how your products are packaged, marketed, and sold, it also provides a vision for how your products could evolve. Product teams can and should use marketecture’s to inform product strategy, roadmap creation, with each major launch and release representing a new building block or incremental enhancement
A marketecture should align stakeholders on how products and/or services work together to orchestrate a solution to a problem or experience
Just as maps are incomplete and do not represent reality since they are limited mental model of the world; a marketecture also does not map reality completely
Practical steps to take to get to an insightful and actionable marketecture:
Get product management to define a product taxonomy
Use your product taxonomy as an input into figuring out the right mental model to frame a marketecture
Use your marketecture to align roadmaps and to enhance core product areas that solve significant and valuable customer problems
Reflect on your core product areas and map out which play off - or connect to - one another (i.e., products that cannot be added or removed) and which are additive (i.e., value adding upsell or cross-sell offers)
Share your marketecture with internal stakeholders across product management, sales, marketing, customer support and success etc. and with vetted external partners to ensure that it is clearly understood. Adjust and refine as needed
Make sure the product and feature names are simple, clear and memorable and aligned with your overall brand and corporate identity
Finally make sure that your pricing and packaging structure are consistent and coherent with your marketecture
Article
Defining Packaged Product
Why every organisation needs to have a product strategy with a defined map aka product taxonomy representing your product universe?
‘Don’t mistake the map for the territory’
One of the worst places to be as a product development person is in an organisation where there is no shared understanding of what a product is and how features should be mapped to product outcomes or end-user or customer value and how the various items should be packaged into a coherent offer or offers.
In my time developing product one of the failure modes I have seen is product developers and the rest of organisation by implication not being clear on the value they create and how they monetise value exchange with their customers. The reasons for this are broad and varied but I share a non-exhaustive list below:
A lack of clarity of business purpose - why are we in business and what change are we trying to create?
An ill-defined business strategy that is not connected to some key policy actions and programs - let me be clear, revenue, profit or market share goals are not strategic drivers
No real business model design - just having a product is not enough, you need to build the whole product offering that goes beyond product but includes the integrated set of actions you take to bring your offer to market in a package that the market finds compelling and attractive that is hard to copy and value creating i.e., think Whole Product Offering or Complete Product Experience
Incoherent product strategy and execution that does not link back to key product or business outcomes - relying on experimentation without having a testable product market framework linked to Value Driver Framework is the fastest path to financial ruin
No coherent structure on how to design the product portfolio to track value - usually the result of not having a product taxonomy
The last point from above is what I intend to tackle in this article.
Most organisations that develop repeatable and scalable offerings and business models, will have at some point moved from being a single product company to being a multi-product company. Becoming a multi-product company is a strategic question requiring real thought and consideration.
The impetus for this transition usually comes from founders and board members pushing business executives to grow the business. Now there are many ways to grow but I am going to focus specifically on growth achieved via product development and innovation.
Below is an infographic from Strategyn highlighting archetypical strategies for growth from innovation and product development.
Great operators at some point on their journey to becoming a multi-product company have defined a product taxonomy. Upon Steve Job’s return to Apple he drew a 2 x 2 to help define the Apple Product Universe which at that time had grown to unmanageable levels due to a lack of strategic focus. Given the current direction of Apple one could argue that Apple is once again drifting towards another set of unmanageable product derivatives.
You may ask what is a product taxonomy? I will begin by defining taxonomy first and then move towards defining what a product taxonomy is and how to use it in your organisation.
Creating a Product Taxonomy
Taxonomy is the practice and science of categorization or classification. A taxonomy is a scheme of classification, especially a hierarchical classification, in which things are organized into groups or types.
So a product taxonomy as applied to product development refers to developing a hierarchical classification aimed at helping to define the problems or jobs to be done you solve with your products for end users and your customers in a systematic way.
A product taxonomy enables you to make sense of your end-user or customer landscape or eco-system in a structured way that enables you to align to product visions and strategies that are meaningful and pragmatic. A good taxonomy can be used as a mechanism to get a feedback system going between product vision, strategy and execution especially in the light of a dynamic system.
Elements of a Product Taxonomy:
Technology elements:
Infrastructure - Underlying capabilities needed to support platform systems, products and services such as hosting, storage, networking, logging, security and other IT infrastructure
Core Platform - Underlying technology supporting a product such as a billing system or customer provisioning system or a claims and benefit management system. Items may be specific to a product or common horizontal layer supporting multiple products
Technology Enablers - Capabilities required to deliver a product. These capabilities may be specific to a product or shared but they are not sold directly to customers
Product elements:
Product Value Proposition - The primary offer at a product level
Product - Typically clients or customers will purchase and contract at this level
Product Feature - This is the lowest level element from a customer perspective. A product feature is a specific piece of functionality that has a corresponding benefit or set of benefits for the customer or end-user. Benefits are the value that users gain from using that functionality.
When detailing a feature, the following information at a minimum should be detailed:
Description - The task or action the user needs to accomplish and how the feature serves them
User Challenge - The pain point or challenge experienced by the user that the feature solves for
Benefit/Outcomes - The benefit or value provided to the user or client
Goal - The broader product goals or measurable objectives that the feature ties to
Initiative - The high-level effort or thematic area of work that the feature aligns to
Service elements:
Support - Services structured to meet specific service level agreements i.e., uptime, response times to outages depending on severity, potential dedicated human resources like a Technical Account Manager etc.
Professional Services - Specialist services such as consultancy, deployment planning, audits and accelerator or adoption services
Managed Services - Ongoing and repeatable services often running over the duration of a contract
Proposition element:
Whole Product Offering - Covers the overall value proposition of a product; this may include monetary, social, emotional or security related jobs to be done
Portfolio element:
This is the highest level product grouping e.g., Product Line, Product Portfolio, Product Suite or Product Platform
Infographic showing how the various product taxonomy elements relate to one another. The overall portfolio is essentially the collection of all your product propositions organised in a way that is most relevant for your organisation.
Benefits of a Product Taxonomy
There are a couple of benefits to developing a product taxonomy. A few of the main benefits are listed below:
Create a Shared High-level Marketecture View -
A marketecture can be used to align roadmaps to enhance core areas that solve significant and valuable customer problems where each additional product launch incrementally builds upon the marketecture and inconsistencies can be quickly addressed.
A marketecture also allows for a view to be developed that shows how the various layers of your business capabilities stack up and link or don’t link to one another. If products can be configured to address a specific need of an industry vertical or client segment or type then a solution level may be necessary.
Define a Common Shared Language -
Most technology solutions tend to be complicated to understand, particularly for non-technical audiences. Even technical teams often struggle to understand the big picture view of how individual Solutions, Products and Features fit together to form a coherent whole.
Clarity in Positioning and Messaging Content -
Clear and simple articulation of value creation and associated benefits derived from a Solution, Product/s, or Features with messaging targeted to specific buyer segments which could be Economic, Strategic, Technical & Professional Buyers.
Integrated Messaging Across Collateral and Channels -
A product taxonomy can enable a messaging library of centralized content with elements that can be interchanged like Lego blocks into all market facing collateral linked to a marketecture: Website, Sales Decks, Data Sheets etc.
Consistent Packaging and Pricing Framework -
A taxonomy enables a marketecture that can be used to package and price Solutions, Products, Features or Services.
So what are the different ways that you can package a product to define your taxonomy?
There are principally four ways to package software products.
Product Line - A group of related products all marketed under a single brand name that is sold by the same company.
Product Portfolio - A collection of all the products or services offered by a company that may or may not allow for integration.
Product Suite - A grouping of multiple integrated products from a single vendor.
Product Platform - A collection of capabilities, modules or parts that are common to a number of products. This commonality is developed to achieve specific economic effects in order to create value. Platforms allow for 3rd party development.
I will dive deeper in a future article on the four ways of packaging software products.
In the meantime here is a real world example of a product taxonomy applied to consumer related product company; Starbucks is a great example of a company that has expanded beyond its initial product offering to include items beyond beverages and food into durable goods.
For further reading on Product Lines see here.
You may be thinking, so what that I have a taxonomy, how can I practically use my product taxonomy in ways that make product sense?
Designing a Marketecture
Defining a product taxonomy is an important start but your organisation needs to use the taxonomy to design a marketecture which will frame how you want to present your offers to the market.
A marketecture is a non-technical representation of solutions, products, systems, services and how they interact and relate to one another. It is used to unify the various components of a Solution, Product, Service or Platform into a visual format. It visualises what is core functionality vs add-on (flexible, and additive).
When used well a marketecture forms the structure for how your products are packaged, marketed, and sold, it also provides a vision for how your products could evolve. Product teams can and should use marketecture’s to inform product strategy, roadmap creation, with each major launch and release representing a new building block or incremental enhancement.
A marketecture should align stakeholders on how products and/or services work together to orchestrate a solution to a problem or experience.
Below is an example of a marketecture from Salesforce for their Cloud Platforms.
Just as maps are incomplete and do not represent reality since they are limited mental model of the world; a marketecture also does not map reality completely.
Main beneficiaries from a Marketecture?
Founders: Usually organisations which still have the Founders around have this knowledge embedded within the Founders however these organisations are at greatest risk of floundering when the Founders exit for whatever reason.
Executive Committee: Anchor strategic discussions on alignment between business and product strategy and use the marketecture as a world building reference point.
Product Management: Use the marketecture to refine product vision, strategy, outcomes and execution planning.
Sales and Business Development: Have a big picture view and sense of how to understand the various Solution, Product or Feature offerings and how they fit or don’t fit together.
Product Marketing: Product Marketing is the custodian of owning the marketecture whereas Product Management would spend more time defining the product taxonomy. Product Marketing is seen to be the key conduit connecting Product Management, Sales and Marketing Teams. Product Marketing plays a dual role: “Voice of Product into Market” – inside out view and “Voice of Market into Product” - outside in view. There is definitely collaboration between Product Managers and Product Marketers in crafting differentiated positioning and messaging that is aligned to the overall product vision and strategy and ultimately business strategy.
At my previous Sequoia Capital backed scale-up the pragmatic product marketing charter that I created referenced the concept of a marketecture. A significant portion of our charter was informed by the work done structuring our marketecture.
‘A marketecture is a living document that evolves over time.’
Below is a sample of some elements of the charter I included in the charter to show how valuable a well-designed marketecture can be to a Product Marketing and wider Product Development team in general.
Research and insight generation that constrained and covered market, product and competitor research and insights
Product packaging, where product marketing managers work closely with product managers to make sure we are defining how we create value, aligning features and benefits and how our offers were differentiated relative to our competitors
Positioning and messaging of products, solutions and use cases leveraging a marketecture view that is used to inform how we present ourselves for both offline (conferences, presentations and other sales collateral) and online (website, whitepapers, infographics, webinars, video tutorials) spaces
Go-to-market, managing the go-to-market process by co-ordinating go-to-market functions across Marketing, Sales and Product
Sales enablement program, working with sales to generate sales enablement collateral with a view to developing modular collateral that can be re-used in different contexts and allows Sales teams to tailor messaging for their audiences. Generating content that can be used for awareness, discovery, evaluation and decision-making in a B2B context
In my last role we used the product taxonomy shared by product management to develop a marketecture which was used to support a variety of core product marketing operational areas, examples listed below:
Developing a shared language for positioning and messaging of our Solutions, Products, Product Features and Use Cases.
Creating packaged offers that could be understood by the value they create and how the key features concretely supported value creation.
Having the right go-to-market action planning and supporting content that we could use to enable the various functional areas like Sales, Support and broader Marketing team.
Pragmatic steps to define a marketecture
Get product management to define a product taxonomy. This will be used to inform your marketecture.
Use your product taxonomy as an input into figuring out the right mental model to frame how you want to present your offers to the market through creating a marketecture.
Use your marketecture to align roadmaps and to enhance core product areas that solve significant and valuable customer problems where each additional product launch incrementally builds upon the marketecture.
Reflect on your core product areas and map out which play off - or connect to - one another.
Highlight which products are part of your core offering (i.e., products that cannot be added or removed) and which are additive (i.e., value adding upsell or cross-sell offers)
Share your marketecture with internal stakeholders across product management, sales, marketing, customer support and success etc. and with vetted external partners to ensure that it is clearly understood. Adjust and refine as needed.
Make sure the product and feature names are simple, clear and memorable and aligned with your overall brand and corporate identity.
Finally make sure that your pricing and packaging structure are consistent and coherent with your marketecture.
PS. If you are moved please leave feedback so I can improve the publication and topic coverage.
Post Script
Main failure mode for product taxonomies and marketecture’s not working as intended or being seen to be useful concepts:
Product leadership not bought into the product taxonomy approach e.g., not willing to spend some time defining their product vision, strategy and how it all comes together in defining the product landscape
The product taxonomy effort being treated like a tick-box exercise and not being used to drive strategic and valuable conversations with other members of the product development team
Not having a shared understanding of the product landscape that goes beyond the immediate product development team that cuts across the entire organisation
Factors to consider when developing a marketecture:
Who are your target customer segments -
B2C, B2B, B2B2C, G2C
Horizontals – e.g., By Business Department or Functions
Verticals – e.g., Industry
Client Type and Size – e.g., Enterprise vs SMB
Specific use cases
Marketecture -
Needs a Taxonomy
Aligned to Brand Strategy and Architecture
Define solutions by Use Case, Client Type and Size and Industry
Develop shared understanding of Products, Features, Services and Platform
Packaging -
Consider Whole Product Definition
Read books like Lovability, Crossing the Chasm and Loved
Positioning -
Try to find a differentiated position in mind of your target client segment
Messaging -
Communicate messaging that speaks to target client segment in expected tone, language and style
#product #producttaxonomy #marketecture #productline #productsuite #productportfolio #productplatform