Ecosystem evolution

Let’s have a look into the evolution of (digital) business model. First of all there is obviously the traditional linear value creation in which every company (or line of business within a company) is creating value — from supply to market — in independent solos. The big advantage of this model is its simplicity because there is full control over the end-to-end value creation.

However the obvious disadvantage of the model is its limitation resulting from the “linearity” of the model — you can only grow if you grow both supply side and market/demand side accordingly.

This is incredibly difficult — particularly if the market is limited for example by region such as for telecommunication providers. Traditionally the incumbent telcos are operating on a regional footprint for regulatory and other reasons. This is why they started to think about two-sided business models when challengers and over-the-top providers appeared on their markets and started eating from their plate.

This is basically a platform based business model where the platform owner is running a business ecosystem with participants supplying services into the ecosystems and participants that market these services (or bundles of multiple services) to end-customers.

A platform is a platform is a platform….

However the concept of a platform business is pretty much a “walled garden” which gives full control to the platform owner, who is able to leverage network effects to create“exponential growth” — if he is able to achieve the critical mass (i.e. a growing number of platform participants on both sides of the platform).

This is primarily for the commercial benefit of the platform owner — only very few participants will benefit from “exponential growth” — see Uber, AirBnB etc. etc.

All participants of the platform are depending on the (business) strategy of the platform owner who is in full control and able to impose any restriction they like. They are harvesting all the data and are beneficiaries of the “flywheel effect”. If they fail all participants will fail as well…

(On a personal note: this is how economies work in countries with a communist regime and the success and sustainability of this model is questionable).

So if innovation is the result of autonomy, flexibility, out-of-the-box thinking, then “platform” is not the appropriate paradigm!

The Fabric

What is we are going back to square one “the silos” — to give back full control to the ecosystem participant — but we enable them to interact in a digital and fully automated way! Every participant is autonomous and offers services to other participants and (the other way round) can consume services from others, bundle them to create completely new propositions to sell them to end-customers or other participants of the ecosystem (who can then bundle them again).

This is a multi-dimensional fabric of autonomous business participant, who are forming a “real value network (fabric)”. This is a paradigm shift from “ecosystem management” to “ecosystem orchestration and facilitation”.

The enablers of this new paradigm are distributed ledgers to handle contracts (to enable governance on business interactions) and transactions and AI/ML to automate business decisions (to enable automated/autonomous business, similar to autonomous driving). Instead of the platform owner managing the ecosystem participants and their interactions, the participants are independent and interaction between them is based on event driven orchestration (similar to micro-service architectures).

So what about “platform services” (aka supporting services) such as billing, payment etc.?

Well these are “just services” provided by ecosystem participants (and these is no reason not to have multiple billing service providers in the ecosystems who compete with each other).

This brings down all the complexity of a platform to simple repeatable patterns of service consumers and service providers.

Conclusion

Most disciplines in science started with a wrong paradigm or with paradigms that were significantly revised over time (such as bloodletting in medicine before antibiotics were invented, or the waterfall paradigm in software engineering before Agility became common), so being very provocative here is the paradigm “business platform” the appropriate one for “digital ecosystem” going forward? Is it about managing participant or about providing an environment that enables and facilitate fabric based value creation based on open standards and open source components?

This is the starting point of a series of articles to outline opportunities of fabric based ecosystems underpinned by event-based orchestration architectures with more concrete examples.

• Desirability: Assumptions about why customers and users will like the product
• Feasibility: Assumptions about how the business model can be executed
• Viability: Assumptions about why the business makes commercial sense

In this article I’ll be putting the theory into practice with a real-life example by walking through a simple example — a new business venture to create an “Airbnb for meeting rooms”.

Note that for the purposes of this article, I’m presenting this process as sequential steps. However in a real-world project, the process is very interactive and iterative, involving all the stakeholders. For example, it’s quite normal to refine and amend the Business Model Canvas while creating the Service Impact Canvas.

We’ll start with a Business Model Canvas, creating a Service Impact Canvas and deriving the initial product backlog for the MVP project.

Start with the Business Model Canvas

Our team’s big idea is to create an “Airbnb for meeting rooms” — a platform for renting out meeting rooms to other companies, and for booking meeting rooms wherever you need them.

Here’s how our initial Business Model Canvas looks:

Roles and Jobs

Our first step is to identify all the key stakeholders involved in running this new business, and to identify their roles and levels of participation. The Key Partners and Customer Segments sections of the Business Model Canvas are the obvious places to look when identifying stakeholders. But don’t forget about other stakeholders who are vital to running the business. You’ll find them all over the Business Model Canvas.

Stakeholders are usually customers/users, third parties or internal stakeholders. They are all equally important!

On the Service Impact Canvas, we refer to Roles (a person has a role to play in the business), and Jobs (the tasks and responsibilities in terms of the expected outcome of doing a job, which a person has as part of their role.)

As we talk with our stakeholders about our business idea, we learn about their roles, and about the jobs they need to undertake in order to make our idea a success. If we are to get buy in from everybody involved, it’s critical that we address the concerns of all of our stakeholders’ jobs.

Let’s start with the Complaints Manager who is a very important stakeholder for the Key Activity “Business Operations” on our Business Model Canvas. His unenviable task is to handle all the incoming complaints about the service, usually coming from meeting room hosts, or the guests who booked a meeting room, so we’ll record a Job of “Handling incoming complaints” in the Jobs area of our Service Impact Canvas.

Barriers and Accelerators

Drilling deeper into the concerns of the Complaints Manager about the feasibility of complaint handling for our new business, we identify Barriers and Accelerators associated with doing this job to achieve the expected outcome.

As we discuss this job with the Complaints Manager, the first Barrier we identify is a possible lack of scalability — this job could become a critical bottleneck if our assumptions about the growth of the business hold true. On the other hand, we identify that classification of complaints — such as severity levels — and Standard Operating Procedures can be an Accelerator for handling incoming complaints that we could use.

We record the Barrier and the Accelerator on the appropriate sections of our Service Impact Canvas.

We continue our discussions with the Complaints Manager, as well as all the other stakeholders and we end up with a vast list of potential Barriers and Accelerators that need to be addressed as part of our new service. We need to prioritise them based on other business assumptions, such as our growth model, and the general level of uncertainty associated with them.

We take a look at our growth model and decided that the Barriers and Accelerators of complaint handling have a high priority. For this reason we want our MVP to show some impact in this area.

Remember that the MVP is intended to reduce uncertainty by validating the assumptions.

What are the critical Impacts we need to verify?

We brainstorm an Impact which could address both the Barriers and the Accelerators for this job — the resolution of minor complaints by meeting room hosts through direct negotiation with meeting room guests. We call this “Bilateral complaint negotiation” and our legal department helps us to define the meaning of “minor complaint” more clearly.

We classify this is an “incremental” Impact — one which we can increase or optimise over multiple versions, but we choose a measurable target for our MVP of resolving 80% of “minor complaints”. We will measure and report back on this continuously so that we can adapt the features of our service to achieve continuous improvement.

We also note that if we set the expectations of our guests’ behaviour correctly at the outset, they are less likely to cause complaints in the first place. So, another Impact we want to target is to help our guests understand the behaviours which are expected — which we call “Setting guests’ expectations correctly”.

The Service Features we need to develop

To bring about the Impacts we have identified, we define certain features needed for our service.

We think the starting point for our “Bilateral complaint negotiation” is likely to be the ability for hosts (and guests) to raise a complaint. We are assuming that most of the complaints will be raised by hosts due to a guest leaving rubbish behind, or not cleaning the whiteboard, so we prioritise the ability of hosts to raise a complaint above the ability for guests.

For the “Setting guests’ expectations correctly” Impact we come up with two Features which we think will help: the ability of hosts to upload photos (showing a nice clean room), and the ability to rate meeting rooms (emphasising the importance of a room’s reputation). The latter will also generate data allowing us to measure whether or not the Impact is actually being achieved.

We brainstorm all the Service Features needed to validate a Impacts on our prioritised Barriers, Accelerators and Jobs for the MVP and this forms the basis of our product backlog. From here we use the integration with Trello and JIRA to create an electronic task board.

Conclusion

This story was presented as a sequential process. In real-life situations there’s a continual process of revisiting previous steps to add, refine and amend the Service Impact Canvas, as well as the original Business Model Canvas which was our starting point. The process of discovering the features of our new service informs our thinking about the business model itself.

Below you can see the Service Impact Canvas from our simple example above, which is now nearing completion as a result of our simple walkthrough that went from identification of key roles, their jobs and the impact generation through barriers and accelerators.

You can find this example (including the Business Model Canvas) in an online tool here: https://serviceimpactcanvas.com.

I hope you enjoyed our journey through the Service Impact Canvas. This tool forms part of a larger “Digital Experimentation” service being launched at https://www.experimenz.com, which will be available to early adopters very soon.

• Desirability: Assumptions about why customer and users will like the product
• Feasibility: Assumptions about how the business model can be executed
• Viability: Assumptions about why the business makes commercial sense

In this article I introduce a new tool to help to bridge the gap between these assumptions, which describe a business model on a Business Model Canvas, and the initial product backlog for the MVP project.

This tool is inspired by already proven techniques such as the Value Proposition Canvas, and Impact Mapping, and is further informed by my personal experience in many projects over the years.

This tool seeks to maximize the impact of the MVP on the critical business hypotheses of a new business service, so I use the name Service Impact Canvas (SIC). The Service Impact Canvas provides a structured method for deriving the initial product backlog, beginning with a Business Model Canvas, and retaining these links over the full lifecycle of product delivery.

As pointed out in my previous article, the MVP must address the assumptions presented in the Business Model Canvas in a holistic manner which prevents undue bias toward one category of assumptions. Tools such as the Value Proposition Canvas are designed solely to address the value proposition and customer segments. In contrast, the Service Impact Canvas deliberately addresses all nine facets of the Business Model Canvas.

The first step in populating the Service Impact Canvas is to identify the relevant Roles, involved in operationalizing the business model. Roles are typically one of three types:

• customers or users
• partners or third-parties
• internal roles within the business organisation

As such, these roles can be derived from different parts of the Business Model Canvas.

The second step is to identify the various Jobs (or tasks) performed by these Roles that are critical to the success of the business model. There are two alternative approaches to “jobs-to-be-done”:

1. the activity itself (i.e. how the job is done)
2. the outcome (i.e. why the job is done)

The Service Impact Canvas focuses on the latter approach.

The third step is identifying Barriers and Accelerators associated with achieving the desired outcome of a job. Barriers exist for many reasons. Examples include lack of automation, high levels of complexity, legal or regulatory constraints, poor data quality or lack of knowledge. Accelerators have a positive influence on a job and support the stakeholders in achieving the expected outcome.

Once the expected outcomes of the relevant jobs have been identified, and the various barriers and accelerators are enumerated, the next — very important — step is to define the intended impact that the product (i.e. service) can make on the identified barriers and accelerators.

It is very important to come up with a very crisp definition of the impact, as well as how to measure success in achieving the desired impact. Discovering measurable impacts is absolutely vital because once the MVP is launched, an essential part of the validated learning process will be the continuous monitoring of these impacts (together with monitoring the assumptions about the growth engines of the business model).

Last but not least, required service features are derived from the intended impact. There are at least three ways of describing these service features:

• user stories
• “simple functional features”
• job stories

The Service Impact Canvas naturally derives the latter of these three descriptions. In my experience, a sound understanding of the jobs, and their barriers and accelerators, makes this way of describing service features these easiest of the three options. The described service features make up the initial product backlog of the MVP.

Just like the Business Model Canvas, the steps I’ve just articulated aren’t meant to be executed in a strict sequential order. Rather, an iterative process of improving and detailing the content of the canvas should be continued until the initial product backlog is understood, agreed and well defined.

In addition to the Business Model Canvas, there are two additional inputs to the Service Impact Canvas: the business hypotheses of the business vision, and the anticipated growth engines of the business model.

This concludes our whistle-stop tour of the Service Impact Canvas! In the next article I will describe how it works in more detail and I will walk through a step-by-step example of deriving an initial product backlog using the canvas. If you’re ready to explore for yourself, head on over to https://serviceimpactcanvas.com where you can register to try it out.

There are countless articles in the knowledge pools over the web inside innovation communities that define the same MVP concept with their own flavour, hence different. Throughout my life I have been a preacher of simplicity and always maintained that “simplest is the best”, so my definition of MVP is exactly how Lean Startup defines it:

The MVP is the minimum scope that is required to start the process of learning .

The intention of an MVP is to embark to a journey of feedback, adaption and continuous improvement, i.e. decision making is no longer based on pure assumptions and opinions, but on facts. Each constituent of MVP is linked to a testable hypothesis associated with the business model.

Initial scope I have experienced is as vital as go/no-go decision for a start up or any innovation hypothesis. People generally struggle with finding the right ingredients to obtain a balance between breath and width of the scope. If the scope is too broad, the time-to-market is too long and money is wasted — also if the scope is too narrow, key assumptions potentially may lead towards invalid at a later stage.

My toolkit, when it is an ideation for a new business model pretty much always starts by outlining the basic cornerstones of the business model in a Business Model Canvas. In the best case this is based on observations, so the initial canvas is full of assumptions but sits at the heart of ideation holistically.

The 9 facets of the business model canvas can be mapped to 3 key categories of assumptions that need validation to support the hypothesis:

Desirability: assumptions about why customers and users will like the product- i.e it will actually create value to it’s users (addressed risk: solving an irrelevant customer job).

Feasibility: assumptions about how the business model can actually be run (addressed risk: poor execution).

Viability: assumptions about why the business makes commercially sense (i.e. running the business makes profit) (addressed risk: flawed business model).

Typically the scope of an MVP is largely focused on desirability and there are established tools such as the Value Proposition Canvas to find the relevant scope items for this category. Particularly for greenfield like business launch this is where the level of uncertainty may be highest, but when comes to a more holistic view viability and feasibility are equally important.

Getting the balance right across these categories is also essential to get the buy in for a new endeavour from internal stakeholders and external partners. Particularly for new business models within digital ecosystems (e.g. platform based business models), the validation of assumptions regarding feasibility and viability is extremely important — which includes finding the right partners and getting the business interaction with those partners right.

As the scope definition and controls around it becomes the torch bearer for any innovation pursuit, what are the tools to find the “optimal” scope an MVP with the right balance across desirability, feasibility and viability?

How can the backlog be prioritized across stakeholders without being biased towards just one of the categories?

In my next post I will introduce the Service Impact Canvas as a tool to find the right scope for an MVP considering the desirability, feasibility and viability holistically.