In this article, we share a key element of our approach to organizational evolution: how we embrace an experimentation-based approach and pick “pilot”, initiatives that help us test assumptions on how the organization we work with can evolve into a platform-org model, before enacting long-standing changes.

This article is part of a series on the concept of a Platform Organization. Check out the first installment on the evolution toward the platform org, and the third which focuses on structuring teams and units.

A bit of context

First of all, let’s set the context: what we are talking about here is the process of evolving an organization – large or small – into a so-called platform-organization model. Such a transition is something that all organizations would need to acknowledge because of deep underlying trends:

• the rapidly changing pace of the market and the need to create “radical optionality” thus multiplying value propositions and products/services;
• the reduction of transaction costs that makes it much easier to coordinate single modular capabilities into new customer-facing elements;
• the increase in the capability of leveraging technology, such as software, AI, and other enabling factors that substantially improve the capacity of smaller nodes and structures to deliver value to customers without needing large scale.

 

We’re talking about an emergent common model of organizing that is appearing more and more across the board among market leaders: independent product-centric units, shared support services, and investment capabilities that allocate capital across and between nodes. We previously explained and introduced this in previous writings on this blog.

We explained and framed this evolution as the evolution from Functional, Divisional, or Matrix organizations, into what we increasingly call the “platform organization” (more details here).

This evolution is pervasive, so you’ll likely face this situation in your company. It may be a way to keep the pace of the market, build optionality, or reduce the organizational debt and brittleness. This applies the most if you’re in a big organization or an organization that was a product of numerous M&As. However, it can also be a potent way to ensure that the growth path your organization is developing along goes through differentiation of products and services and not just through a single product-service offering. This is an extremely dangerous path in an ever-changing market.

---

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’s our approach? Start from the organizational will to evolve

The picture below is good for explaining our approach to organizational evolution towards a platform organization.

 

It consists of two initial flows of activity. One flow is dedicated to understanding the organizational challenge and normally involves decision-makers and org leadership. The objective of this first piece of activity is to produce a snapshot of the current organization setting, and its willingness and potential to evolve into a future state.

This future state is framed across three main “lines” of evolution. These are the three most important dimensions of the Platform Org as we see it at Boundaryless: being entrepreneurial (and leveraging contributions through a fully accountable and activated workforce), enabling all the parties, including internal units and external ones, and finally being ecosystemic. This means acknowledging that the nature of business in the 21C is no more something that starts and ends “inside” an organization, but rather one where the organization needs to play a role in complex value creation processes that often start, or end (or both) outside the organization itself.

 

 

Such analysis provides a way to help the leadership visualize the target state and discuss polarities in a constructive way. It helps to answer questions like: how much autonomy should remain in the peripheral units? How much control are we willing to lose over the system as it evolves? How much risk-bearing (and thus premium, in case things go well) should be passed onto the units and the employees? How transparent do we want the information flows to be? In our experience, this activity is essential to discuss, internalize, and accept the trade-offs involved in the Trilemma of organizational unbundling. The Trilemma tells us that autonomy, coherence, and adaptability cannot be all optimized at the same time in an organization.

This exercise helps companies understand what they want to prioritize, based on an understanding of their existing commercial context, workforce characteristics, and organizational culture. It is also based on the compliance requirements that the organization needs to respond to. For example, a bank would be different from a pharma company, and a manufacturing one from a software-centric one.

 

In parallel: a full stack analysis of the Value Chains

In parallel to the work we do on the organizational evolution front – along the lines of ecosystemic, entrepreneurial, and enabling developments – we normally spend the initial steps of engagements framing the market the organization is immersed in and how it connects deep inside the org.

 

 

Such analysis is rooted in achieving a deep understanding of the socio-technical domains that comprise the organization and its relationship with the market. In a recent article, we explained what it takes to look into an organization through a market-driven lens with an approach that integrates a domain-driven characterization of the organization (grouping capabilities that co-exist as part of a coherent domain), with an analysis of the state of evolution of all the capabilities and components used to produce the value proposition.

From this point of view, the key steps we perform are the following:

• First, we map all the customer needs that the organization is responding to (see more details on this particular aspect in our article on Responding to Multiple Customer Needs with Products and Services)
• Then we map how the organization is currently organizing such capabilities and how its go-to-market structures and processes are packaging them to respond to customer needs
• Subsequently, we analyze the continuity in the domains of capabilities to isolate pieces of the organization that shouldn’t be torn apart.

 

As a result of the work in the two analyses, we produce a set of evolutionary suggestions. Such suggestions are of different kinds:

• Suggestions in terms of evolving the strategic process to decide organizational evolution, what elements of the portfolio to develop, harmonize, or evolve
• Suggestions on how to create actually new elements in the offering (product/services) or how to reorganize existing ones that are partially overlapped (in line with the domain continuity analysis)
• Suggestions on extracting common support services and structures into so-called shared services platforms, that can enable market-facing units to focus on their stream-aligned, product-centric capabilities and operating models
• Suggestions for new systems that support cooperation and collaboration between units in marketing, pre-sales, and post-sales execution, and customer support to ensure consistency and coherence while avoiding sacrificing the autonomy and accountability of product units
• Other suggestions emerge from either having the organization collectively look into itself as a system abstraction (what we are) and compare it with its evolutionary vision (what we wanna be) or by applying strategic elements, such as stopping investing in reinventing the wheel, creating an innovation engine, or other doctrine and strategic gameplay actions.

 

Explaining the “sketchbook” Concept

The suggestions serve as a strong foundation for jotting down key directions, key ideas, and key observations into what we normally refer to as the “sketchbook”. More than just a notepad, the sketchbook can be described as a dynamic navigation map detailing the path the organization must tread to evolve into a platform organization.

 

At this stage, the sketchbook we build often contains information on at least three essential aspects:

• a snapshot of the current product-service portfolio and an emerging taxonomy – useful to inform both how the organization communicates its offering to customers and distributes business outcomes and objectives to teams;
• how the key artifacts of the Platform Organization – Micro-Enterprise units, Shared Services Platforms, and Collaboration Contracts – can be implemented given the existing organizational culture, market behaviors, and compliance constraints;
• how we expect the pieces to come together process-wise to guarantee that the products can be built, accountability exists over business outcomes, and – last but not least – how work can be coordinated across the organization to ensure coherent business releases and productivity gains. Often this includes scaled-agile inspired practice or similar processes to ensure OKRs distribution and aligned strategies.

 

Experiments and Pilots

Once the sketchbook suggestions emerge, it’s reasonably easy to convert them or integrate them into experiments and pilot initiatives.

Each experiment needs characterization mainly through two sets of items. One set is dedicated to understanding deeply the nature of the experiments. This set focuses on how the experiments are going to happen in the organization, the types of organizational artifacts, practices, and processes the experiment is going to impact, and the overall hypothesis that backs the experiment (“what do we want to prove”?).

Each of those experiments is subject to prioritization as a complement (the organization doesn’t have infinite resources to invest). We use evaluation matrices to help leadership teams elicit and agree regarding how to prioritize the energy and budget.

Boundaryless’ experience with multiple experimentations of Platform Org evolutions brought the following criteria as particularly important for choosing high-potential pilots:

• Financial Value: the higher the potential additional revenues and other financially relevant outcomes that can be generated by the pilot, the higher the priority list should be;
• Indirect Value: the higher the priority list should be, the more non-financial, potentially intangible outcomes generated by the pilot.
• Success Probability: the higher the probability for the pilot to generate success in the given timeframe, the higher the priority list should be (low-hanging fruits first);
• Interdependence: the higher the number of ecosystem resources, competencies, and dependencies the pilot engages (existing processes, 3rd parties, etc…), the higher the priority list should be. However, caveat: this indicator is often in conflict with the Success Probability;
• Initial Level of Investment: the lower the financial investment expected for the pilot to be executed, the higher the priority list should be;
• Time to market: the shorter the time to validate the pilot through customer/stakeholder feedback, the higher the priority list should be;
• Replicability: a higher priority should be assigned if the learnings from the pilot are more relevant for other pilots and the overall organizational evolution.
• Platform Org Pillars Alignment: The higher the pilot’s alignment with 3EO/Platform Organization pillars (increased entrepreneurship, broader autonomy through enablement, larger ecosystemic collaboration, etc…), the higher the priority list should be.
• Certainty of the commitment: the higher the probability that the team will dedicate the necessary energy to pilot success over the whole pilot timeline, the higher the priority list should be (avoiding wasted resources).
• Overlap: higher priority should be given if the pilot overlaps with other strategic initiatives (e.g., requires a restructuring of the product taxonomy, while the company is also working on improving customer legibility);
• Alignment to the Core: the higher the pilot falls in line with core business elements, the higher the priority list should be;

 

Once pilots are prioritized in this way and set in a process of being executed, it is crucial to be able to draw some conclusions after the experimental timeline.

More specifically, we can come back to the Experiment canvas from our 3EO Framework. A good pilot initiative will have to deliver clearly:

 

 

• Successes: elements of the pilot that have worked well in the execution
• Frictions: elements of the pilot experience that have created friction with the rest of the organization, or the market and what lessons we learned through those frictions
• and finally Embeddings: i.e. the key elements that we want to embed into the organization as a consequence of the execution of the pilots

Integrating Outcomes into a Coordinated Collective Strategy

After executing the pilot projects and identifying the positive “embeddings,” we convert our sketchbook of raw findings into a more impactful and comprehensive “playbook” – an evolution of the raw sketchbook and a mix of an operating manual and a set of alive maps (portfolio, strategy, customer descriptions).

This format enhances the shareability and understandability of the actionable elements while leaving enough room for autonomous judgment on the part of the organizational users: employees and unit leaders.

Presenting these elements as part of a “playbook” enables the organization to move away from top-down bureaucratic management approaches and test a more collective and co-creative set of rules rooted in a shared map and shared operational modes as a community of practice, more than a set of managed teams.

Conclusions

In this piece, we shared our motivations beyond choosing an iterative and pilot-based approach to organizational evolution towards a 3EO/Platform-Org model. This process offers a way to integrate the learnings from individual experiments and pilots into a combined playbook and encourages a culture of collaboration and a transition into seeing the organization as a community of practice.

Additionally, it allows the reader to peek into how Boundarlyess builds up a deep underpinning of the organizational context both internally and externally before picking and committing to pilot experiments. It also helps to keep a systemic overview of the organization at hand and to root any decision and resource allocation into a well-framed understanding of the organization’s evolutionary context.

If you’re part of an organization in need of transitioning from a brittle, top-down management approach into an organic ecosystem of empowered product units that can generate sustainable and future-oriented growth, please reach out to have a chat and envision how we can help perform the most important transition of the decade, towards embracing a platform-organization model.