Understanding Three Economies

One of the most challenging moments to me is when I try to explain the concept of Wardley Mapping, and my interlocutor shouts ‘It is just like framework X!’. And they are right; the overlap is usually quite high. They see familiar things: users, needs, dependencies, sometimes a visual representation, but they miss the only thing they are unfamiliar with - Evolution, and, consequently, all the goodies that stem from it.

I am on the verge of committing a similar crime. When @Jabe Bloom wrote a blog post about the three economies, I had a hard time finding things that were not covered by mapping before. I made a few mistakes during this journey, so I found it may be worth to document them for others.

Jabe’s post touches several aspects that are rarely brought to daylight during Mapping Sessions, and therefore it is definitely worth a comment, and a discussion. I am very curious to learn what do you think about it.

Let’s start:

Jabe writes:

Many organisations mistakenly think that there’s this choice between an Economy of Difference and an Economy of Scale. You need to focus on one or the other. You can either drive costs out of it or you can create value. There’s no in-between.

It is hard to disagree with that part. Not so long ago, Gartner promoted their Bi-modal approach to IT, where they had two modes:

The image comes from this tweet, it was very hard to find an original BI-modal image, because current BI-modal has three states. I guess the two-state BI-modal with hard border did not work…

Gartner’s transition shows that there is an increasing understanding that one-size-does-not-fit-all, and that you need multiple different approaches in response to different levels of underlying components Evolution.

Pioneers, Settlers, Town Planners (PSTP) are the part of mapping that covers it:

Yes, PSTP is a model of culture. Pioneers, Settlers and Town Planners are people who have similar kinds of creativity and risk aversion to other people in their group. That cultural model stems from different characteristics of the underlying components, so it looks like the analogy to three economies (below) is obvious:

My initial, naive interpretation was:

• Differentiation is a different name for Genesis and Custom-Built, as those are competitive advantages.
• Scale is all about Commodity. Commodity is about scale. But Scale can also be a competitive advantage (it is widespread misconception that competitive advantage is only about differentiation).
• Scope, the clutch, is in between.

This thinking was all wrong. It’s not how things are, and it took me a while to understand why not. The key phrases used by Jabe are:

Scope economies (platforms) are made up of things that are found in scale economies. A platform is made up of network, compute, storage, etc., but what’s added to it is the reuse of functionality and data.

Well-formed functions, reusable data, and predefined or standardised configurations. These three things create a platform, which performs the logic of an Economy of Scope, which allows you to have a clutch between the logics of differentiation and scale.

It does not sound like a transition between Custom-built and Commodity. Not at all. Quite contrary, those phrases describe mature, standard components. A set of them. A platform.

This makes so much sense right now. What Jabe is describing is an economy of a platform, and why using standards components lowers the cost of investment for experimentation:

When a platform isolates efficiency from differentiation, the differentiation gets thinner, but also faster. As an example in a recent article, Facebook rewrote the Messenger app, and they took 1.7 million lines of code and reduced it by 84% to 360,000 lines of code, just by leveraging the preexisting framework inside of iOS. They basically leveraged the iOS platform to make the messenger app, the differentiated edge system, as small as possible. This means it goes faster, it’s easier to maintain, and it’s easier to dispose of.

So, the translation to the world of mapping should look like this:
How do I decide which components (Choice A,B,C) should be industrialised to make differentiation as effective as possible?

The answer depends on what do you think is possible to achieve in the differentiation space, and that in turn depends on plenty of things that Jabe mentioned:

Ashby’s Law, complexity theory, constraints (enabling/governing, top-down and bottom-up), reliability and emergent resilience, diffusion theory, the Commons and the enclosure movement (and recommoning), pluralistic logics

The problem is not new. LEF has been trying to address it for quite a long time, but probably never from the exact angle that Jabe described, and I anticipate to see some very new and novel thinking there.

Thank you, Jabe, for your post!

Funny you are saying this as I have experienced the same and in fact I am using it to introduce maps. Moore came out with the Zones to Win - 4 zones which defines the incubation / transformation / Performance and Productivity.
The first 3 zones are pretty much PST.

When doing value stream mapping in organisations, I am also very often mapping the standard work (which is generally in the Settler or TP zone) and then asking to map the flow of innovation and the flow of improvements. This is generally a lot trickier.

Where the 4 zones from Moore brings something interesting, is the productivity zone. It touches on the operating model and connects to the Doctrine in fact. I like the idea to have it closely connected to the map because companies are typically over-optimised for productivity in the performance zone which constrains the ability to function in the other zones. Eg. Performance zone expects margins, where incubation is generally future value and proving a concept.
I tend to discuss how the productivity zone is in relationship with the other zones and what is needed in those relationships.
It is the same as the doctrine but somehow the doctrine and operating model considerations are not as connected into the map.

One concept that Maps bring over any other frameworks that I know, is that they do not take it as one size fits all. Most frameworks see the whole and miss the nuances. Many have a Product View / Portfolio and assumes an life cycle without a play in the commodity. Platform and long-tail strategies make sense in digital.
Maps capture those nuances in the value chain and that is pretty unique I believe.

My understanding is a platform is about modularity, a host of a class of modules. In terms of design, there is a trend towards personalisation at scale. For example, the iPhone can be a telephone and camera to some users, a messaging device and jukebox to others, etc. Is the iPhone hardware, operating system and SDK, plus the Apple stores the clutch?

When I read Jabe’s article the economy of scope seemed analogous to an economy of agglomeration?

For me a platform is creating something that other people can do their business on top.

When aiming to be a platform, the business in question is essentially desintermediating self from the access to customers. Those that try and play at both ends inevitably struggle to scale.

Iphone --> Apps
AirBnB --> people renting their room
Uber --> drivers
Amazon --> marketplace

Platform has a very broad set of meanings, and I think your statement is correct when we talk about the long tail or aggregation, but it does not apply to the infrastructure type.

The screenshot comes from the platform design toolkit guide.

How is infrastructure not fitting “other people doing their business on it”?

It is still a platform, I was trying to address that statement about the struggle when you address both ends.
For a long tail type, you can’t address customers directly, because it is a long tail. You can only provide means of communication and transactions (f.e. Apps, Marketplace).
For Aggregators, you can address some customers directly, but you may not have enough of resources to do it yourself (Uber, AirBnB).
For Infrastructure, you can do both. You have to grow the technical platform that helps you win customers, and, at the same time, you can sell that technical platform or a subset of it to other corporations. There should be no struggles in this set up.