In one of the latest articles we released on the blog, we approached the role that taxonomies have in ensuring that both customers and teams can interact and develop a coherent set of services and products.

There are numerous use cases of application of such techniques: multi-product is the new vogue and rightly so, the cost to build services and products in the digital space is ever smaller thanks to advances in software and – after an age of large horizontal products – markets are now expecting more variety, modularity, and composability to fill the remaining niches.

Multi-product coordination can also be a real deal in organizational ecosystems, for example, those that emerge from M&A, strategic venture-building investments, venture-studio initiatives, and more, all on the rise as a pattern in the market.

Even in the context of social development, we have seen systemic approaches emerge that even overcame the private sector for their capabilities to capture nuance and deal with complexity.

In this article, we’ll give you a framing of the work you’ve to do if you’re building a portfolio of products with a focus on how your products will bundle together. Beyond the benefits that a product taxonomy will give you (something we covered in the latest article) we’ll share with you a way to keep your product portfolio structure and taxonony as outside-in as possible and we’ll make sure to share all the points of view you have to entertain as you embark on this complex journey.

 

 

Understand the market

Developing a portfolio approach to product and service development starts from understanding the market. Portfolio approaches give the possibility to tackle a set of coordinated options in parallel, they reduce risk and introduce optionality, and require therefore not only a deep understanding of customers and their pains and gains but a more systemic understanding of all the interactions that happen in the ecosystem and of the role being played.

This is something that we tend to do at Bundaryless by using Arena Maps and Ecosystem Scans – in ways we’ve introduced already. The language of “arenas” was introduced to break down the complexity of a large ecosystem and comes in handy when approaching the market with a portfolio posture: often arena maps also provide a good starting point for defining “product areas” or similar concepts.

Deriving your product areas, macro-sectors of activity, based on a clear mapping of the ecosystem interactions is a great way to start on the right foot, that of outside-in perspective: one of the most important and the first aspects of keeping a listening mindset to portfolio development that allows for some “emergence”.

Unearthing Domain Models & visualizing (original and transformed) Workflows

The initial phase of the exploration has to give teams – and the organization – a hand in creating domain models and abstraction of workflows.

Approaches to this can vary. The method we often put in place with Platform Design Toolkit canvases can help contextually bridge this activity of abstraction with the activity of product thinking and design. An activity that we usually perform – in this context – is value chain analysis with Wardley maps aimed at identifying interesting opportunities for productization.

At Boundaryless we created a set of six platform plays (recurring value chain transformations in platformization processes) and using them, together with your common sense in spotting recurring market transformation patterns can lead to insight into both:

• the reality of the market or system at the moment of the analysis;
• the potential transformation of it, through the product you’re counting to build – likely a “platform” given the interconnectedness of the market.

In this way, a product designer can abstract the domain model, involving the entities, the common workflows, and the commonly used services, and think ok how all this can be productized.

A typical pattern is the creation of a SaaS or – more generally – a product/service bundle that has value to serve a single user – likely the professionals in the market. Another opportunity is certainly identifying recurring transactions that can be standardized into a marketplace.

By doing so the designer can work out what we call a Platform Strategy Model, based on the three archetype value propositions of platform design: a product side (a core offering for a single user) a so-called extensions platform that is a way to let third parties extend the functionalities of such product, and a marketplace (or more than one) that normally target – at least for one side – the key customer that the product is targeting.

 

[check out our clear description of these three value propositions on Value Propositions in Business Ecosystems – Products, Marketplaces, Extensions]

Let’s make an example: let’s assume we’re targeting the market around masonry services. We could end up mapping work with several arenas, but let’s assume for the sake of simplicity that we focus on the arena around doing home renovations. Other ones could be skilling and hiring a workforce, materials fabrication and transportation, or post-works maintenance.

If we focus on the arena of home renovations, our domain model would cover the definition of key concepts such as customer, construction site, project, materials, designs, work item, and compliance rule…. and we could identify a few core processes and systems such as ordering, contracting, invoicing which likely rely on existing software or practices that – in a productization effort – could all be consolidated into a digital product. Extensions of such products might be integrations with existing invoicing tools, project templates, and more. Transactions that could be standardized would be contracting, purchasing, ordering, appointment taking, etc… A marketplace could be developed to generate demand (construction company to customer) hire workers (construction company to supplier), or buy materials (construction company to customer). These are just examples to make it more clear.

Products

The first level of portfolio development will thus start with what we could call ideating point solutions that target a particular market context (arena) around a certain value chain entailing a few workflows, transactions engines, and more.

These point solutions can be single-user value products, complex marketplace platforms, and developer ecosystems – or a combination of all.

Composition: Bundles, DIY Platforms (configurators, no-code engines, LLMs)

The products existing in the portfolios can be composed in various ways. The portfolio needs to sustain and favor a continuous bundling and combining process.

Here’s where most of the emergence needs to be governed by the constraints we introduced in the last article.

Beyond other constraints, at least providing pricing constraints, and common design systems is essential.

There’s a danger though: ensuring the composability and integrability of the elements in the portfolio is a subtle challenge. The risk of rational, mechanical, and inside-out overreach is relevant and can backfire in terms of introducing too much rigidity into the system.

It’s also important to keep in mind that the same interfaces that your products will have to use to integrate with each other should be opened to the external ecosystem early enough. As a product developer, you will rather have a problem attracting third parties to build on top of your product than the other way around, so you normally don’t have to be prudent and controlled in opening up interfaces. Casey Winters wrote a notorious essay on gaining traction towards third parties in his “Sequencing Business Models: So You Want To Be A Platform?” which is a mandatory read and more current than ever.

Looking into Hubspot again as an inspiration, one can see how it is possible to integrate at many levels in their software ecosystem: integrations can happen at the data layer with data syncs and at the workflow level. For this type of integration, Hubspot had to create a workflow model that spans across the different application hubs (it is cross-product) and effectively is the strongest ontological assumption in the portfolio.

 

What should drive bundling?

Bundling between different products must be primarily driven by the organization: user research (remember the idea of “joint customer needs”) and active customer listening can be good starting points and running experiments around PLG – for example, to optimize growth and portfolio product adoption path can also create ready-made portfolio bundles for the customer. From this perspective, constraints are essential, and – for example – creating a common workflow model as Hubspot did, can be a good “selling point” around which bundling can happen.

Besides these “inside-out” approaches, bundling can also happen in at least three more outside-in ways mainly driven by the customer: DIY configurators, NoCode, and LLMs.

 

DIY Configuration Portals and platforms

One is certainly that of creating macro products (a la Hubspot Hub) that create essential affordances for user-driven self-configuration: DIY configuration portals and platforms that actively promote and help the customer discover new products and modules and complement them with professional services are a potential solution.

Building such systems is not immediate though and needs the organization and the product to grow and evolve alongside its ecosystem in continuous listening, with the aim to create a vibrant community of professionals that take agency in defining what is the product to them, and push integration forward in their own context.

 

No Code

An always more prominent option is represented by ‘NoCode’. Such solutions enable customers to perform complex and less “standardized” integrations without writing a single line of code, thus revolutionizing the way product implementations are customized.

A noteworthy example of such is represented by Zoho Creator, a prominent tool from an enterprise boasting a wide-ranging array of offerings. Enabled by its advanced yet user-friendly NoCode implementation environment, Zoho can empower users from varying technical backgrounds to custom-tailor its product suite to precisely cater to their unique requirements.

Many product portfolio companies have a no-code offering that complements configurators, another interesting example is Retool. Are we heading in a direction where providing a no-code integration environment is becoming central to any company that provides a portfolio of solutions? Likely but no-code solutions are now extremely abundant in the market: lacking your proprietary solution, customers will play with other options, likely crossing the boundary between your products and those from other brands.

 

The emerging role of LLMs

Another promising interface for bundling and composing complex product implementations is emerging through LLMs. GenAI offers a different, and more intuitive way to bundle products together: it’s promising especially as it shows the capability to understand customer needs in plain language and do the heavy lifting of composing on behalf of the customer, crossing the technical gap.

 

Keeping it emergent

It’s extremely important to understand that the process of defining ways for your products to compose in the portfolio, choosing the archetypes and the ways for products to connect is a delicate task. As we said above, the risk of armchair taxonomizing overreach is real: imagine if the first naturalists who defined the way we taxonomize animals would have done that sitting in their rooms instead of visiting the natural environment.

Your product taxonomies thus need to be generally light and adaptive, and you should be open to exceptions: in a recent conversation with Teresa Torres she also pointed out that – when exploring new opportunities – you normally have to refrain from applying taxonomies at the very start of the process and rather evaluate, in the presence of a promising idea, what would be the drawbacks of making it “fit into the portfolio”:

“If I’m an empowered product team, I’m doing continuous discovery and continuous delivery to find an opportunity – an unmet customer need, pain point, or desire.

When I’m first exploring solutions, I don’t care about constraints: my primary goal is how to fully satisfy this solution or this opportunity.

Once I’ve started to find an idea that could work that I think has a lot of value, I’m getting feedback from customers that it’s desirable, that it’s usable, and it looks like it’s feasible….then I wanna get into whether will this work in my organizational context. So now I need to account for the constraints of my vision and I need to ask how do I modify it to play nice within the taxonomy?”

Paraphrasing Teresa Torres from an upcoming episode of the Boundaryless Conversations Podcast

What should influence your choices of product taxonomy at every moment then? Two different “forces”: your customer-driven, ecosystem-driven research (how do “customers” perceive your products in relationship to their problems?) and, on the other hand, some product archetypes that you set to optimized modularity, cross-integration between products and value proposition clarity, for example by defining something a product, something a marketplace, and something else an integration. Your “design systems” at all levels.

Keep an eye on unbundling in the meantime

Another key aspect of your portfolio and taxonomy work will be that of a continued process of “unbundling”, which is supposed to happen internally, to ensure you always identify – among all the pieces in the portfolio:

• what are the ones that make you different
• what are the commodities you can source externally
• what are the various common pieces that empower different products in your portfolio – and are thus worth being “transformed” into so-called internal platforms.

We are currently researching this space and prototyping approaches – and we’re being inspired by some of the advancements coming from the Domain Driven Design (DDD) spaces such as Susanne Kaiser’s approach described in her Adaptive, Socio-Technical Systems with Architecture for Flow, which combines Wardley Maps, DDD and Team Topologies (one of the leading frameworks of architectures for flow).

Conclusions & Upcoming Works

In the coming weeks, we will write more on the topic, and we’ll add more reports on hands-on work, and prototypes of tools we’re creating to help you combine all the elements mentioned in the piece today as you move ahead with prototyping your portfolio strategy and product taxonomy.

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