Reinventing your Organization through a Market-Driven Lens

An Experimental Approach

Simone Cicero
Stories of Platform Design

--

Explore an adaptive approach to organizational transformation with our article on market context mapping and arena scanning. Discover how to use Wardley Maps for strategic rebundling, optimizing market reach, and enhancing your competitive edge. Harness the power of ecosystem scans and value chains for effective business adaptation in fluid market dynamics.

This article has been co-autored by Simone Cicero, Luca Ruggeri and Emanuele Quintarelli

Abstract

In the last few months, we’ve been wrangling with one key problem: helping organizations optimize and transform in ways that are more attuned to market dynamics and more capable of evolving and competing. We help organizations unbundle their assets and capabilities and re-bundle in new ways, continuously.

In this article, we outline a methodical process for mapping market context, unpacking arenas, and applying arena and ecosystem scans to better navigate competitive landscapes.

The piece also illuminates how to create a value chain using Wardley Maps, aimed at achieving strategic reorganization for improved market reach, differentiation, and efficacy. With links to further resources and a structured analysis of organizational assets and capabilities, this article provides a first guide to starting a transformation rooted in your business contexts and market dynamics.

It’s important to note that this approach is not yet stable and mature and neither should be considered a unique way to approach the problem. Rather, in this article we show a mix of techniques some of which we used recently with some of our customers, and we cross-fertilize them in an experimental way with inspiration from a seminal article recently written by Susanne Kaiser, where she puts together Wardley Mapping, some key concepts of Domain Driven Design (namely, Bounded Contexts) and Team Topologies archetypes. In our approach, we use 3EO Framework’s archetypes to be able to apply a similar approach in a broader organizational context, rather than to achieve flow in a specific, single product context.

NOTE THAT: 👉 This post is a re-publication of an original posted on our blog, check the original here.

Subscribe here: https://boundaryless.io/newsletter_subscription_page/

How to map the market context

The first step, we most often take, has been to help organizations start by mapping their reference market, and customers, and position themselves into the wider landscape with their packetized services, capabilities, and products.

You’d be surprised by how many companies do not maintain an accessible, clear, and coherent representation of their markets and how their internal units and functions relate to them serving a clear system of customer needs.

A system of arenas

It’s important to clarify that — most often — when organizations map their market they’ve to consider different perspectives. A recurring situation is that companies have “business units” or, in the case of groups that emerged from M&A, they could have sub-entities or divisions (which may hold a separate P&L). In other cases, functional companies may have product areas.

In the initial process of mapping and representing the market we use Arena Scans. Arenas as small ecosystem subsets where a reasonable number of entities achieves systemic outcome through interactions. The definition of arenas is rather loose but we’ve found this construct extremely valuable as a first step for teams to define their target markets.

To visualize a unit’s (or a product area’s, or division’s) market scope we use Arena Scans. The arena scan helps a team map out the arenas where they’re aiming to operate and put them in contextual relationships. We use two essential affordances to help teams map. Time relationships (before and after) signal how two market spaces are sometimes related on a consequential basis. Hierarchical relationships — based on the concept of one arena “enabling” another — are also mapped.

As an example, below you can see how two business units — one doing On-demand software development for customers and one doing Digital Transformation consulting both from a fictional consulting company would map the arenas they’re interested in.

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.

How to start mapping: product areas, business units, intentions

For each arena, we ask teams to detail the substeps and we use them to produce sometimes what we call ecosystem scans. These scans are more detailed than Arena scans. They are designed to help teams enumerate key stakeholders (consumers, producers), mediators (such as platforms, brokers, regulators, etc…. — and all the resources that are used in the process of interaction.

Adding ecosystem scans to complement the higher level enumeration and positioning of arenas (an Ecosystem Scan can be used to explore the content of each arena) is a great starting point to later produce Wardley maps (value chain maps) of one, or sets, of arenas.

Wardley maps are essential in the task of imagining how to unbundle and re-bundle an organization: they provide a way to represent a value chain from two “axes”. The first, that of visibility is a proxy of user value perception while the second is that of evolution. In Wardley’s frame, things evolve from genesis (just invented) and commodity/utility, the stage when activities and resources become universally accessible, ubiquitous, and normally available on a pay-as-you-go basis.

For more details on:

It’s important to stress how valuable is for an organization to maintain a shared and accessible representation of its reference market, as this is something that a surprisingly low number of companies do: this step is valuable per se, even without engaging in strategic unbundling and rebundling.

Laying out your system of arenas as a proto-value network (multiple value chains)

When we perform this activity from a portfolio, multi-unit perspective, we build a collective representation of our target “system” of arenas, also clarifying overlaps. The scope resulting from the collation of all the arenas (and therefore the whole reference market of the organization) can also be quite complex.

To create the arenas system, we place arenas on a proto-Wardley map, and focus on understanding:

  • how the arenas connect to the key customers;
  • how they relate to each other;
  • what overlaps exist between the different units (or points of view)

If a particular arena overlaps between two or more units (they’re both active in that market space) we ask both teams to discuss their respective representation of the ecosystem (through the ecosystem scans or other tools). Sometimes we first do the arena system and then build a representation of each overlapped arenas together.

Creating ecosystem scans is a good practice because it helps to overcome the broad nature of arenas into something much more tangible and detailed and it helps explode monolithic bubbles into much more detailed representations where it’s possible to capture all: the organization’s capability and products (that exist among other market alternatives), the resources and external components used and more.

Moving beyond this initial representation of the value networks (multiple value chains) into a more detailed picture goes through exploding the Arenas. Above, you see the original arenas positioned over the landscape, with a mention of the units that originally identified it, and a linkage to some form of “key customer” that the organization needs to start characterizing.

In the process, units should also end up specifying some form of target customers (a form of ideal customer profile) and clarifying the core user needs they serve.

In our practice, exploding the arenas through Ecosystem scans is a way to let more information surface, but the unbundling of the arena can be done intuitively. There’s no minimal amount of detail you’ve to put into a Wardley Map but — generally — the more you can explicate the better it will be. Exploding the ecosystem scan, for each arena, it’s going to be a helpful step to make the various elements visible.

Note that this detailed map should end up mentioning your assets and capabilities, along with the external resources, complements and roles you, compete with, or leverage. The idea it’s not to mention single players but rather archetypes: rather than mentioning Azure, you should consider a more general “Cloud infrastructure”. You can go as deep as you want with details: it won’t certainly be detrimental.

Sometimes you’ll have portfolio elements, for example, a capability you’ve (e.g. the capability to do UX design) that are fairly common on the market. In other cases, you may mention a particular product you built such as a piece of unique software or a hardware technology that may be more unique. You clearly want to identify if your products are also a particular item of a certain archetype.

Using Wardley Mapping and 3EO archetypes to inspire rebundling

During the extraction of details elements inside arenas can end up in different places concerning where the original arena was. You rarely end up with a component in the genesis phase extracted from a sub-arena that you previously positioned in the lower right bound (commodities). Your original perception of the arena may be biased though and the more systemic view calls for different evaluations.

As a result of the explosion of the Value Chain, you will have a systemic view of your organization’s market context, starting from your core customer types. Your objective at that stage will be to figure out how the capabilities and products you see lend themselves to be rethought more strategically than the initial setup.

More in detail, your aim should be to see three key things: better ways to drive coherence, competitive advantages and common, cross-enabling services.

A new type of coherence (sort of an emergent bounded context) between capabilities may suggest that such capabilities should be integrated into a new (or different) unit. The coherence might be even more important if groupings represent a potentially new competitive advantage — even only in terms of efficacy (or efficiency).

Many capabilities that talk to the same stakeholder can create a strongly reinforced uniqueness together (see the red groupings in the picture below). They can not only compound but also be perceived as an actionable value proposition for a customer.

Some of these groupings may instead represent more common, cross-enabling services, that can power other teams: this is common for the reminders of functional basic capabilities (such as compliance or basic HR capabilities) but also for enabling services such as software development or campaign management.

In some cases, these enabling structures can support the unique value proposition with additional, ancillary, or supporting capabilities that can help more unique value propositions to focus without having to engage with activities that may be scarcely perceived as value differentiating.

In this particular example, the map tells about the potential that the original two business units can be more effectively rearranged into two user-facing MEs: one doing product-centric organizational consulting for portfolio development and another doing single product design, validation, and experimenting. On the supporting side, we can see the potential to create a Digital Design, Engineering, and Distribution Node ME or SSPs. More work will be needed to take action on this strategic view and we — at Boundaryless — would suggest to use the result of this preliminary analysis as input in the process of crafting pilot experiments that can drive change in specific vertical slices of the system, bringing back systemic insights that can help the organization evolve its architecture for the long term. Other heuristics can be used as a complement or alternative to this approach though.

In implementing this technique we took a strong inspiration from Susanne Kaiser’s Adaptive, Socio-Technical Systems with Architecture for Flow: Wardley Maps, DDD, and Team Topologies. In Susanne’s work, she advocates for applying a similar technique to first identify bounded contexts (something we did as well above) and then evaluate which of those contexts should be transformed into stream-aligned teams (a Team Topologies’ archetype for single-threaded teams), what goes into a platform team (another archetype for a team that provides specialized capability that enable and augment delivery) and more team types — these are the key ones though, at least from an architecture perspective. For the groupings that suggest nonspecialized commoditized capabilities, Kaiser suggests market sourcing (like we do).

In our approach, we usually look at a bigger, org-wide context rather than in a single product, software-centric context (just saying, the example we bring is on consulting). As a consequence we tend to use the 3EO Framework archetypes that describe stable units: that of Micro-Enterprise, and the Shared Services Platform.

Generally, groups of activities that are in the genesis space or are in direct touch with customers are good and potentially bear the possibility of becoming “micro-enterprises” while those that are more at the lower right, can either represent shared-platforms. This is because capabilities that are mature and far from being differentiating in the eyes of the customer can either be sourced directly on the market or be encapsulated into platform services.

The choice while you should source from the market or creating a shared services platform greatly depends on compliance and efficacy. If no compliance requirements impede outside sourcing, transaction cost will become the deciding factor. In some cases, you may want to inject a certain level of “resource inefficiency” and redundancy in some supporting platforms/capabilities because this can give a time-to-market advantage to your single-threaded teams.

In the picture above you can see how I drew a yellow line: it’s rather intuitive that it separates grossly the zones of the map where the potential new micro-enterprises (top left) and shared services platforms (lower right) will sit in the picture resulting from the unbundling. So-called Node MEs, which I picture on the line, are indeed a bit of a mix between a Micro-Enterprise that is outside-oriented and internal supporting capabilities. They serve mostly internal customers but can reach the market autonomously and provide non-commoditized services.

Conclusions

Despite not yet being stable and mature, this type of analysis provides an organization with a clear process to look at the system made by its market and portfolio, unbundle it, and look into the potential for rebundling it in a way that multiplies market reach potential, differentiation and efficacy.

In more articles coming up, we’ll share more examples, and more specifically extend the action-thinking into the role of Enterprise Architecture in this process, seeding new units strategically and the role of partnering and contracting.

Stay tuned for upcoming releases!

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to click the 👏button and hold down to 20–50 claps as this will help us to get more exposure, and hopefully, work more on developing these tools.

Thanks for your support!

--

--

Building the ecosystemic society. Creator of Platform Design Toolkit. www.boundaryless.io CEO Thinkers50 Radar 2020