We and selected third parties use cookies or similar technologies for technical purposes and, with your consent, for experience, measurement and “marketing (personalized ads)” as specified in the cookie policy.
With respect to advertising, we and 1181 selected third parties, may use precise geolocation data, and identification through device scanning in order to store and/or access information on a device and process personal data like your usage data for the following advertising purposes: personalised advertising and content, advertising and content measurement, audience research and services development.
You can freely give, deny, or withdraw your consent at any time by accessing the preferences panel. If you give consent, it will be valid only in this domain. Denying consent may make related features unavailable.
Use the “Accept” button to consent. Use the “Reject” button to continue without accepting.
The Platform Portfolio Deep Dive is a 1-Day Experience designed for executives and builders who want to learn how to manage an ecosystem of several products and services. Join us in Barcelona for the first Live Edition.
The Key Challenges Faced by Organizations: What are the problems we are trying to address with this approach?
The techniques presented here focus on helping companies that run a portfolio of products targeting different customers. Note that with “product” we more generally mean products, and services of all kinds.
This situation (portfolios) often comes up in business-to-business contexts, where portfolios are typically a mix of professional services, software solutions, SaaS, and other packaged services. Despite this, most of the insights will also apply to a B2C context, especially in the presence of multiple products in a portfolio and not with single product companies.
This is often the context after mergers and acquisitions, or joint ventures – where several companies or competence centers coexist as part of a group.
A similar situation can also recur in monolithic companies that maintain a portfolio of products and services and want to optimize team or business unit structures, for more entrepreneurship and autonomy. This is exactly what we do with the 3EO framework and portfolio techniques, used to construct so-called platform organizations.
The typical challenges that arise in a multi-product / portfolio setting are:
identifying gaps, overlaps, or uncovered needs in the offering and actively defining a product strategy to exploit these opportunities;
distributing ownership of products and services in a portfolio, to multiple teams and leaders;
designing the right product taxonomies (product areas, product types…) to ensure products can talk to each other and be easily composed;
rearranging capabilities that exist inside the organization to deliver the value proposition better, and generate more options;
favoring product and service innovation.
Mapping Customer Needs with the Wardley Map
Below we present a typical outcome of a preliminary activity we’ve been doing with one of our customers. The map content is anonymized and presented just for visual understanding.
As often happens, we start with a Wardley map. A Wardley map is a map where components are positioned within a value chain and anchored by the user’s need, with movement described by an evolution axis. Check out this tutorial on how to do Wardley Mapping by Ben Mosior to learn more.
For example, Let’s assume that XYZ is a large service provider, a holding group with several controlled entities.
In the map below, you can recognize three major parts:
the upper layer – where the colored boxes are – is the space where we map the users the organization serves and their respective user needs (for example they could be, CMOs, CIOs, CFOs, etc…typical customers in a B2B setting);
an intermediate part in which aquamarine post-its represent XYZ’s Go To Market (GTM) motion, including sales, marketing, CRM, and more;
the lower part is where we have mapped most of the capabilities of XYZ, and the most used resources to produce the value propositions.
Focusing on needs
If you look at the higher side of the picture above – which should be considered just an example – you can see how XYZ’s customers’ needs are mapped. The needs on the left are the most peculiar, those that require a different solution for each customer of XYZ – that’s why they’re mapped in the genesis/custom-built side. Gradually, as you move to the right XYZ’s customer needs become more standardized (in the sense that different XYZ customers have similar needs).
For the sake of understanding, let’s assume XYZ is a technology-based service provider and integrator, that does development, BPO, and IT infrastructure… and that its typical customer is a large corporation. For example large retailers, manufacturers, etc… let’s call this typical XYZ customer ACME in the following. We choose to use such an example because the breadth of the offering of XYZ in this case is very wide. It will be easy to make parallels to such a situation if your company provides services in a subset of such a market (for example if you’re specialized in information technology, or engineering, or maybe if your services cater to a specific vertical industry, say FMCG or Retail).
So the context of the analysis is this: XYZ is a service provider, that wants to optimize its portfolio and services to serve ACME and similar customers better.
Top Left Quadrant
The needs that sit more on the left (in the Genesis, and Custom Built evolutionary stage) are uniquely related to ACME’s context. Typically we’d talk about needs such as strategic advisory, product design, building better customer experiences, and more.
The products that ACME builds (and the related needs for evolution) along with other elements of its internal processes are likely typical and specific to ACME’s geography, maturity, industry, or existing products. For example, a strategic advisory on adopting LLM technology would need to be specifically tailored.
The needs mapped in this area are heavily strategic for the ACME because they map directly with its capability to deliver value and experiences to its end consumers. Here ACME expects XYZ to be able to provide bespoke services and to be coherent, guiding the customer in line with the specific and diverse nature of their needs.
Top Right Quadrant
The needs that sit more on the right (Product, and Commodity in the evolutionary stage, x-axis), are those that are more evolved (mature) and more frequently recurring in ACME’s (or generally in XYZ’s customers) reference industry or even beyond industries. Needs mapped in this quadrant are typically related to ensuring that a customer can compete effectively (scaling, basic digital enablement needs, collaboration, sustainability…)
Top right needs are more standard, and customers are less inclined to pay a premium price concerning top left strategic needs. Customers here expect the capability to deliver at scale, readiness, or efficiency over high customization. They would accept to do some work on their own to get lower prices – for example, through configurators, or DIY product customization, with partial use of SaaS or COTS (Commercial Off The Shelf) elements.
Lower Quadrants
In the lower quadrants, we usually end up mapping needs related to processual, and infrastructure-related elements. This is where ACME and similar customers seek solutions to power automation, networking, computing, compliance, security, etc…
The more you move on the right the more you move into compliance and efficiency needs that are common across customers and industries while on the left once can find things such as industrial or process automation, modernization, refactoring, and data intelligence: needs that are lower level but still very specific of ACME’s business process to improve organizational adaptivity, and responsiveness.
The difference between the top and bottom left quadrants is that:
the former relates to ACME’s need to create and evolve customer-facing value propositions to drive better sales and market outcomes
the latter instead focuses on ACME’s enabling infrastructure and organization and caters to ACME becoming more adaptable in the longer term.
In essence, responding to needs that sit more at the bottom of the left side (less strategically linked to the customer’s direct market performance, and more to the improvement of its enabling adaptability) will still need bespokeness, but with a longer timeframe, and less market pressure in the short. ACME’s value perception is still high due to the peculiarity of needs and due to the long-term value of the investments done here but lower than the top left quadrant, as it’s not directly connected to immediate market performances.
As you move from bottom left to bottom right customers’ needs become more standardized and customers would often issue RFQs and tenders for needs in this area because services and products are heavily comparable and componentized. The customer drivers here are speed, short-term returns in efficiency, standardization, and compliance with market requirements. Procurement is often awarded to the lowest price or best cost/quality ratio.
Utilizing This Information to Shape Organizational Approaches
How do we use such info? Considerations and maps like these can be successfully adopted to evaluate how to:
design a taxonomy of products and portfolio;
what type of customer interfaces to build;
how to shape the GTM, sales, and pre-sales processes;
how to distribute areas of influence on the product (eg, product areas, Micro-Enterprises…), and reduce overlaps and friction between customer-facing units.
Left side
Given the unique shape of each of XYZ’s customer needs on the left (see the strangely shaped customer need representation above the graph), XYZ will likely need to respond to customers’ needs by composing a diverse set of products, services, and capabilities.
Typically such capabilities will also be worthy of existing on their own as peculiar offers in the market: as an example, let’s say one of XYZ’s units provides software development solutions. Such a unit will need to have at least minimal embedded UX Research capabilities. In a complex project, by the way, it may want to collaborate with a more structured UX research specialized unit to build a stronger proposition.
On the other hand, ACME would benefit from a coherent way to deal with XYZ’s offering because the challenges is dealing with are strategic and diverse and often need integration of different capabilities to deliver end-to-end results. That’s why ACME here will demand highly customized, bespoke support services and why XYZ’s portfolio here should also cover ultra-bespoke patterns such as advisory, architecture, adoption of best practices, and so on.
Since in composing such a set of responses to the customer’s need, overlaps can be reduced but not eliminated, in a lack of offering coherence, XYZ will likely maximize quick wins and lose more end-to-end opportunities to serve the customer fully: the risk is to only sell one piece of the puzzle.
As a consequence, XYZ should probably consider using approaches and artifacts to ensure more collaborative coherence. In our practice with customers, we’re applying several patterns for this sake such as:
common offer layers such as Product Areas, OSes, or Hubs and more generally clear product and service taxonomies that facilitate bundling – we wrote about it here and here;
collaborative and centralized pre-sales and post-sales processes that can ensure coherence of offering and upsell – by monitoring the evolution of the customer need and the potential to promote other elements of XYZ’s offering.
While ensuring coherence independence is also key to maintain. For example, product areas should be kept independent to create new offerings and bring them to the market. Given the strategic nature of customer needs in this area: customers would still seek and accept premium and innovative unbundled service even if it would cost more because it solves a pressing and strategic need for them. Matt Brown wrote a fantastic article on the topic that we strongly suggest.
In a few words: separation of leadership and responsibility of a certain area of offering in this high-value space through a stream-aligned team or single-threaded leadership is a worthy choice while – at the same time – it should not come at the expense of completely isolating such units from a common Go To Market perspective. XYZ needs to work for pieces to get together easily for both the customer’s benefit and the maximization of XYZ’s opportunity to upsell and cross-sell.
Right side
If we now move to the right, XYZ will have to respond to later-stage, more consolidated needs that are often related to ensuring ACMEs can compete in its market.
More specifically, needs on the top will be more about ACME’s capability to scale, and differentiate, creating solutions to reach more customer segments. Such services won’t need to be fully bespoke but will still need some tailoring but since the need is more mature, there will be more competition and more price sensitivity.
XYZ should consider that its products and services in this area will likely have to cohabitate with other providers and that customers are more sensitive to bundling (buying more services together), and open interfaces to allow existing data and processes to interoperate with newly adopted solutions. Standardization is key on this side of the spectrum and openness and standardization of interfaces and practices start to be essential for XYZ’s capabilities to compete. Embracing fixed price listings, pre-made bundles, and DIY configuration – generally leveraging on the customer’s capability to self-configure, and self-bundle – will be a winning strategy, reducing the buyer’s cognitive load and improving the reach through clarity.
Eventually as one moves below, XYZ will find itself responding to ACME’s needs related to compliance, and efficiency and the competition on price will be more fierce.
On this side of the customer needs spectrum it will be increasingly harder to attain high margins (essentially you compete on the basic cost of doing business) and one ends up repackaging a lot of external resources through APIs, modules, and on-demand infrastructures.
This can still be an important part of XYZ’s offering though, especially if delivered through cost-scalable distribution channels, as with SaaS, API, Modules, Packaged and Managed Services, and other modular ecosystems of partners.
A successful strategy in this space should involve:
a modular and self-configurable set of products and services;
a self-sustaining GTM motion where you don’t spend much money to get your product to the customer (partners do).
Such an approach would allow XYZ to capture consumption patterns and use them as an inspiration to explore new bundles of offerings to respond to emergent higher-level needs and start the innovation process over and over again. In this sense, having mechanisms that allow XYZ to quickly fund and build new product units will be key to a healthy and dynamic process of product innovation. If you use your ecosystem as a “future sensing engine” as Simon Wardley once said, you’d better have an organization capable of quickly funding and developing new ideas.
Conclusion: The Importance of Mapping Customer Needs to Shape Your Organizational Capabilities
As a recap, what we learned today is that mapping customer needs is essential to approach a restructuring of an organization’s portfolio offering, GTM motion, and capability distribution and autonomy inside teams and units.
We learned that customer needs vary from complex, bespoke, and specific, to more common, standardized, and componentized.
We learned that to respond to the most valuable customer needs one organization has to develop independent specialized offerings and expertise that can be quick to discover new consumed on its own by its customers but also that in the most valuable domain, a coherent GTM (sales & presales) motion would ensure the maximization of the systemic outcomes and avoid the risk of suboptimal siloing of the specific product areas around the client’s needs.
We also learned that it will be important for an organization to respond to the most common customer needs through platformized product bundles, and self-configurable packages and even gradually evolve them into APIs, modules, and other componentized services that can be adopted by an ecosystem of third parties,
In a piece coming soon, we will discuss more in detail how to develop and organize the underlying layer, including a portfolio of products and capabilities, from a perspective of organizational structures such as P&L, Micro-Enterprises, and how to be strategic around Go-To-Market elements and sales motions also from the perspective of resource allocation.
Key Concepts & Acronyms: A Glossary of the Platform Organization, 3EO and Portfolio Strategies
