How Taxonomies help achieve Coherence and Composability in Products/Services Portfolios

Introduction

In the rapidly changing landscape of product development and organizational strategy, it is crucial for companies today to learn how to orchestrate efforts across different product areas and product teams. Creating multiple products is indeed easier, coordination and technology are at a glance, and large, horizontal markets are mostly already taken: developing portfolios is an important strategic challenge the importance of which no organization should underestimate.

Some of our recently honed focus areas include; figuring out how to build effective hierarchies and taxonomies in product portfolios, understanding strategies for scaling team structures based on specific business outcomes, grappling with balancing set taxonomies versus letting products organically emerge, and reflecting on the concepts of composability, both from the user’s perspective and internally.

Other pivotal issues of our research cover an array of influential factors; from life cycles and continuous discovery to setting up suitable strategic contexts, building resilient cultures, creating rituals, and fostering robust communities of practice.

Additionally, we are grappling with matters of product evolution and expansion in portfolios exploring how constraints and multiplier effects operate when there are third-party contributions through open interfaces and partnership ecosystems.

In today’s piece – rooted in recent conversations we had with Alex Komoroske, Teresa Torres, and Craig Strong – our exploration revolves around extending these strategic insights ‘into the trenches’; aimed at everyone trying to successfully build hierarchies and taxonomies within their product portfolios.

Specifically, we will venture further into understanding how to align business outcomes in the matrix of an entire portfolio and how this bumps up against scaling team structures.

Looking at your product system as a set of business outcomes, and user behaviors

Let’s start with a single product for simplicity: what you should have clear is your key outcome, which is most often related to a certain revenue formula. For example, for a subscription business, it could be the number of subscribers times how much money they spend each month times how long they stick around. If you have a marketplace business it could be the number of buyers times how many transactions they book over a certain period.

Connected with these business outcomes you have user behaviors: in a subscription setting, they could be for example the engagement with premium features while in a marketplace setting could be how many times they make searches to fill.

Most of the time the revenue formula is a direct consequence of a set of user behaviours that predict three essential elements of any digital product:

• customer acquisition and conversions (into paying customers, into transacting)
• retention
• and monetization generally ARPU when we think about additional services.

To influence this system you’ve teams that are able to run experiments and impact the product experience and the funnels (for example as part of a go-to-market strategy, an SEO campaign, etc..): in turn, these elements will influence how the user behaviors translate into business outcomes.

“Growth is a system between acquisition, retention and monetization”

Brian Balfour on Lenny’s Podcast

The loyal reader will have seen how this connects very well with the idea of a Growth model: the ingredients are the same, you’ve metrics you want to influence, you’ve experiments you want to run and you mainly act on the transition between customer acquisition and conversion into paying customer, with an aim to calculate the lifetime value. You’ll be able to use this information to feed into your growth engine, which costs you money to run.

Essentially the idea of a growth model is framing this relationship between acquisition, conversion, behaviors, and business outcomes but it adds a cohort-based element, where cohors are related to new experiments you run, so you can project this into the future making assumptions. Check more on building your growth model on this article, or reach out for help.

What happens when you’ve to scale this across different teams?

In a platform setting you can think of your products either as strongly separated – let’s say for example you’re building two different products, one for one vertical and one for another – but also as different elements of a shared brand.

The latter is what you’ve when – for example – you’re building a vertical SaaS for a certain market and, on top of it, you add a marketplace for demand generation (eg: Salesforce CRM platform and Salesforce Consultants marketplace on appexchange). Despite these two products having a strong cross-product synergy and effectively reinforcing the value proposition of each other, they have fundamentally different product outcomes: one is ultimately a productivity tool, and the other is often a demand generation or supply sourcing channel.

It’s thus of the utmost importance to think in terms of user behaviors and business outcomes as a way to inform your organizational setup. It makes sense for example to “subdivide” the single products, potentially encompassing them with a P&L responsibility: treating them as “micro-enterprises” – as we do with the 3EO/Rendanheyi model – is meaningful because, despite being inter-related, these products can generate an experience which is worth for the customer as a whole: I can enjoy better productivity even if I don’t receive customer leads. Indeed brands often create connecter products in a sequence, but this sequencing and expansion topic is something we’ll cover more deeply in the following piece.

Inside the single product context, you’ll have to think about distributing the business outcomes to the various teams. Let’s, for example, assume you’re building a marketplace: you may have a consumer team a producer team (each focused on a certain side of the relationship), a growth/customer acquisition team, and a service monetization team that aims at providing and monetizing additional services that can improve the ARPU beyond the take rate.

As you can easily see, the sub-product team outcomes and customer value cannot be untangled: therefore it wouldn’t make sense to give sub-teams responsibility over a business outcome such as P&L that they cannot influence completely. The value they can deliver is rather the compounding of their collaboration at a whole product scale.

If we look at the problem from a Conway’s law perspective we pretty much come back to the original illustration we made for our product-centric operating model piece. Not all teams must have P&L responsibility, but rather: first you identify the product units that can drive a consistent product and business outcome (eg: marketplace, SaaS, apps ecosystem…). Then, for each macro-product, you break down the business outcomes across teams so that the inside-product teams can drive part of the outcomes that the product needs. You’re basically using a “reverse Conway’s law” heuristic to do so: defining teams’ structure according to the outcomes they need to generate.

Ensuring coherence: what are the benefits of having a product taxonomy

Product hierarchies and product taxonomies have been used for a long as a means to keep systems of products being built by an organization.

There are two main advantages of embracing clear and objective taxonomies, and ontologies to a product portfolio and they are both customer-facing and org-facing.

From the perspective of the customer, a clear taxonomy makes it easier for the customer to understand how to map her needs with a product. It’s worth it for teams to look into an information architecture approach to building taxonomy that is thus heavily rooted in the understanding of customer needs. It’s plain wrong to start working on your taxonomy if you haven’t mapped the ecosystem of needs, potentials, and interactions and the macro-jobs to be done you’re targeting: you can see how we do it in our previous articles on mapping ecosystems, arenas and jobs to be done, or – with a more methodological perspective – on our first techniques article on the Macro-Problem of understanding ecosystems.

On the other hand, taxonomies and ontologies are a powerful way to divide work internally and nicely create organizational structures that fit the product portfolio you want to build, distributing P&L to the product divisions and favoring a further dissection of outcomes inside the single product unit.

Indeed, the topic of taxonomies and life cycles often elicits a muted response, until individuals come to grasp their inherent significance and potent influence. The concept of a product taxonomy serves as a systematic categorization and hierarchical framework delineating the relationships among various elements of your portfolio.

In this schema, one might encounter a product or platform designed for customer interaction: this customer-facing entity will not be isolated; rather, it is likely intricately connected to a myriad of other internal support platforms and internal products, each playing a pivotal role in constituting the whole. Furthermore, the taxonomy extends to encompass services and other components, all intricately woven into the tapestry.

The act of classification and hierarchy setting that a taxonomy provides gives a lens through which one can scrutinize a portfolio component as a more transparent exercise.

For instance, one gains insights into attribution and inheritance between components, and therefore makes it easier to achieve a clearer understanding of the total cost of ownership of any product and service, making one able to look at the financial flows that compound at the product-level P&L.

The taxonomy also provides valuable information that can be used in planning/or monitoring release cycles, releasing investments, computing risks, and designing operational structures as we’ve seen.

Furthermore, product taxonomies and ontologies can be great not only at organizing internally but also at communicating your value proposition to customers: they really have to be customer-centric.

Here’s a great example, that we covered already in the past if you feel like going deeper, of how Hubspot communicates its offering to customers, through “hubs”.

Finally, taxonomies and ontologies, to be really appealing to teams, need to provide value: a taxonomy is a product in itself, of which the main customers are the teams inside the organization and, potentially, external third parties that – often in a subsequent stage of product development – provide additional extensions and plug into the ecosystem of product that you’re building.

It’s therefore essential to embed the taxonomy in all the supporting processes to really create value for the teams: DevOps, IT, Legal, Marketing, and HR … all must integrate the taxonomy in the support processes and the taxonomy itself will need to be useful in terms of bringing new products to life first and to the customer later.

“if you define a taxonomy and ontologies, you should embed those into your culture, your recruiting, your training, and everything else and the mechanism should reinforce it.”

Craig Strong on the Boundaryless Conversations Podcast – subscribe on YouTube or other platforms here.

Ensuring Portfolio coherence through additional Constraints

Given the complexity of both, the market – characterized by great variability and continuously shifting needs – and the socio-technical system that builds the portfolio (your organization) it’s certainly agreeable to say that “you can’t manage a portfolio” but, at the same time, not possible to just give up on ensuring a certain level of coherence in the organization and the product it builds.

As we’ve already explained in our article on the “Trilemma of organizational unbundling” coherence comes at a cost, normally generating drawbacks at the expense of autonomy (limiting maneuver space for teams) and potentially, and dangerously, at the expense of whole-organization adaptability.

The temptation of dictating coherence top-down to which leadership teams may fall victim, effectively leads to the organization having disempowered teams that depend too much on centralized decisions, making the organizations incapable of adapting from the bottom up and neither from the top down.

According to all of our recent interviewees who inspired this reflection governing a modern product portfolio only can happen through design and product constraints coupled with a clear vision being communicated by the leadership.

We’ll be back on the topic of communicating and socializing strategic visions and strategic information in the coming weeks but it’s important today to focus on what are the types of constraints one can use to drive coherence in an otherwise incoherent portfolio ensemble.

These constraints should be considered what Alicia Juarrero calls “enabling constraints” : the most powerful way to create innovation (check the podcast episode we recorded with her). They represent a commonality of interfaces beyond which autonomy can really play out. According to Alex Komoroske, they effectively are “Schelling points”, affordances, scaffolding around which different levels of coherence can be naturally sought.

If we embrace this perspective a product portfolio leader is to be seen more as an architect who designs the factory space rather than someone who roams the factory floor shouting at everyone to go in a certain direction or perform a certain task.

A potential (nonfinal) list of constraints that one can use to ensure a certain level of coherence in a portfolio follows below along with a breakdown of customer and team benefits:

• Design Systems
  • Description: A cohesive set of design principles, components, and patterns to be used by teams
  • Customer Benefit: Ensures a consistent and intuitive user experience across all products.
  • Team Benefit: Streamlines the design and development process, reducing time and effort.
• Unified Branding & Messaging
  • Description: Consistent brand identity and voice across all products.
  • Customer Benefit: Enhances brand recognition and trust, contributing to a more engaging user experience.
  • Team Benefit: Facilitates marketing and communication efforts, providing clear guidelines for presenting products.
• Pricing Constraints
  • Description: Standardized pricing models or structures across products.
  • Customer Benefit: Provides clarity and predictability in cost, aiding in decision-making.
  • Team Benefit: Simplifies sales and marketing strategies, making planning and execution more efficient.
• Commonplace Microservices & enforced APIs (eg: identity, etc…)
  • Description: Shared microservices and APIs for common functionalities.
  • Customer Benefit: Offers a seamless and integrated experience when using different products within the portfolio.
  • Team Benefit: Promotes reusability and efficiency, accelerating development and reducing redundancy. Will make it easier for external partners to integrate as well over the long term.
• Type of Constraint: Standardized Data Models
  • Description: Common data structures and formats for shared or exchanged data.
  • Customer Benefit: Ensures consistent and accurate data presentation across products.
  • Team Benefit: Simplifies integration and data management, promoting data consistency and quality, and will make it easier for external partners to integrate as well over the long term.
• Type of Constraint: Shared Performance Metrics
  • Description: Standardized metrics for measuring product performance and reliability.
  • Customer Benefit: Provides reliable and high-performing products that meet or exceed expectations.
  • Team Benefit: Offers clear benchmarks for improvement and comparison between teams, supporting continuous enhancement efforts.

“Let’s talk about analytics. We want consistency and coherency in the way that we collect data across our product. We could define a data model that everybody has to abide by. That’s the rules we’re putting in place. But even if we have the rules, anybody who’s ever done this at any company knows that not everybody follows the rules and it quickly becomes a hot mess. So we could put into place a practice whether that’s a data team that signs off on all the data collection methods, and they’re responsible for the coherency, or we could use a tool that constrains how we collect data, and that’s responsible for the coherency.

We see the same thing with design patterns and design libraries. We could create a design library, and the design team is responsible for making sure everything is coherent with that design library. Or we could use design tools that limit designers to just those tools.

I think the key is the company has to look at what needs to be coherent and consistent. What are the rules we’re going to put in place? How do we make it easy for our teams to follow those rules day in and day out?!”

Teresa Torres on an upcoming episode of the Boundaryless Conversations Podcast – subscribe on YouTube or other platforms here.

Conclusions and further works

In this article, we have covered some of the key elements of getting a taxonomy right to ensure coherence in a portfolio of products and services. We spoke about the importance of ensuring the distinction between whole products that can be subject to clear business outcomes, and how to break outcomes down to the composing sub-teams.

We spoke about what are the benefits of taxonomies both internally and externally with a focus on getting inspiration from ecosystem maps and customer jobs when defining the taxonomy as information architectures for customers, a job that your taxonomy will inherently be subject to.

We followed up by discussing how enabling constraints – with the help of constraining tools – can be powerful drivers of coherence without harming the autonomy of the teams beyond the constraints.

In the coming weeks, we will continue to write and extract insights on the topic of building portfolios: we’ll prototype design and strategy tools, and we’ll focus even more on two more key topics: that of expanding from one initial value proposition into a system of those, looking into expansion and extension patterns, and that of how things combine across multiple products. The aim will be to give you a clear way to frame product composability in your portfolio and how to manage and onboard partners to develop additional value layers on top of yours.

Another key topic will be exploring how leaders can communicate vision and feed it to entrepreneurial communities of practice that make an organization a foundry of great products and teams.

To stay tuned on the work:

• Subscribe to our newsletter here;
• Subscribe to our podcast on YouTube or on any other platform you use;
• Join our telegram broadcast channel where we publish all our releases along with a steady flow of curated reads