TL;DR at the end.

You are all probably familiar with @simonduckwardley’s Doctrine introduced in chapter 18 of the mapping book.

image.jpg1800×1012 575 KB

When I first saw the four phases, I got a small impression that I missed something. It was out there, in my subconsciousness, causing me to feel slightly uncomfortable, and, in fact, this feeling got even stronger when I did my homework around mapping (finances, marketing, etc.).

Today, I think I know what bothered me, and I am sharing my thoughts with the hope of sparking a discussion (here or on Slack). I am really curious about hearing what you think.

Let’s start with Be the owner (take responsibility) which is shown to be in the Phase III, and should be introduced long after Phase I principles such as Focus on user needs are implemented. This is at least, how I read the table, and how I suspect many of you read it, too.

The challenge here is that you cannot suddenly start doing Focus on user needs. You need to transition into it that state, and that requires mandate (or at least some support) from the rest of the company, but what is most important, it also means that you have to accept that existing state of the matter is not sufficient and that it is your fault.

Suddenly, Focus on user needs appears to be depending on Be the owner, and once you assume your responsibility, you will have to think about being transparent, using common language and challenging assumptions. The latter will not work if you are not humble.

What we are seeing are clusters of best practices. The interesting thing about the cluster is that you cannot introduce the whole cluster in one go. As in the example above, it is a spiralling process - if you take responsibility at a minimal level, you will introduce fundamental transparency and some early common language. That will allow challenges to happen, and that… will require a whole level of new ownership skills, which in turn… you get it.

I see three clusters:

Leadership

• Be the owner
• Be humble
• Think big
• Commit to direction
• Be transparent (a bias towards open)
• Common language
• Challenge assumptions
• Exploit the landscape

Customer focus

• KYC
• Focus on user needs
• Outcome
• Pragmatic
• FIST
• Small teams
• Do better with less
• Distribute power and decision making
• Provide purpose, master & autonomy
• Aptitude and attitude
• PSTP

This one is somewhat unexpected to me. Once you learn who are your customers, what are their needs and what outcomes do you need, it all gets pragmatic. But once you get to small teams, you will have to rethink not only how are you focusing on user needs (because things have changed), but also how are you going to lead your organisation. Distributing power and decision making will not work without some Leadership in general. More, those two need to be balanced - the more power you distribute, the more transparency and the better vision you need.

Learning

• Understand what is being considered (high situational awareness)
• think small (details)
• Bias towards action (learn by doing)
• Move fast
• bias towards new
• There is no core
• Listen to your ecosystems
• Systematic learning
• Strategy is iterative
• Strategy is complex

I had a hard time putting those in order. To think deeply about what is being considered you need robust common language and some transparency. To just think about what is being considered you need you to have basic common language and a bit of transparency The learning within organisation seems to depend heavily on the Leadership and Customer Focus clusters.

Operations

• manage failure
• manage inertia
• design for constant evolution
• use standards
• tools
• flow
• set exceptional standards
• effectiveness over efficiency

This one shows exactly the same pattern as the two previous. To get it started at the primary level, you need fundamental leadership, but the more efficient you want to get, the more capable you have to be in other areas.

TL;DR

My hypothesis: Introduce Doctrine slowly starting from things that are most behind, do not use phases. Being good at ten doctrine element is better than being exceptional at 5.

Interesting. Not sure if this is discussed on Slack, but as I don’t like that, I’ll use this.

I went back and read chapter 18 as you call it and there’s a couple of points. The second point I’ll put in another post.

My first point is that you cannot work on generalities first. You need to start with specifics.

For example “Be Pragmatic” should happen before “Think Big” and before “Listen to your Ecosystems”. Simon himself discovers that Liam didn’t know what a Wardley Map was. That lead to the subsequent section on Assumptions and Bias.

The phases of doctrine (figure 236) diagram is confusing. What do the four columns imply? Because they certainly are not explained.

More later. Now I want to write up my Point 2.

This is brilliant observation, thank you! Specifics (thinking in outcomes?) looks actually as one of those things that should improve your situation no matter what. I just wonder whether there is a maturity model of that point.

I’m still thinking about the sequencing - so far without much result.

But I’ve come across phase 1 explained in a somewhat clearer way (especially the terms I take for granted that I understand) in Section 1.3 of the UN Handbook (read-only Google Drive)

I’ve been getting more into Theory of Constraints, and one of the things that stood out to me was not only to change but also to evaluate whether the change brought the outcomes we wanted.

Based on that, I can now see why “Use a systemic mechanism of learning (bias towards data)” is in phase 1, which consists of:

Revisiting the previous strategy in order to understand where we have come from, what was intended, what was actually achieved, and what could’ve been done differently.

Section 1.3.7 has a few sentences that add a sequence:

There is little point in focusing on user needs, creating a common language through the use of a map and sharing it transparently if no one is willing to challenge it. Challenging others assumptions is a key approach to communicating, innovating, creating and problem solving.

When the sentences quoted are compared to the row on “Communication;” it’s as though the table is read from left to right - the category (in this case, “Communication”) being the anchor.

I doubt it holds for all rows, but was a happy coincidence

Basic Value Chain is in Mapscipt.

The link to an editable value chain in drawio was too large to fit here, so i’m linking it via a gist - Value chain of 'Communication' category of Doctrine · GitHub - and adding the image here:

WIP-Doctrine1130×729 48.3 KB

I’ve been rethinking “user needs” since reading this quote

We can’t really discuss any of these things in terms of a language of “needs.” For much of human history—and this is still true in much of the world today—when poor people end up in crippling debt to local moneylenders, it’s because they felt they had to borrow money to throw proper funerals for their parents or weddings for their children. Did they “need” to do this? Clearly, they felt strongly that they did. And since there’s no scientific definition of what a “human need” actually is, beyond the body’s minimal caloric and nutritional requirements, and a few other physical factors, such questions must always be subjective. To a large degree, needs are just other people’s expectations.

Most economists conclude therefore that there’s no point in sitting in judgment about what people should want; better to just accept that they do want, and then sit in judgment about how effectively (“rationally”) they set about pursuing their desires.

–David Graeber

User needs are such an important concept in Wardley maps. The term is both obvious and (conveniently) vague at the same time. It is also often said users don’t actually know what they need.

By focusing on “user needs” (or expectations) and the current Wardley doctrine, is there a risk Wardley mapping will result in cultures primarily motivated by OODA loop optimisation at the expense of creativity, novelty and broader societal needs?

Yep, that’s a risk. But I think the other principles counter-balance the broad term - “user needs” - such as “know your users” “use a common language”, “challenge assumptions.”

Some of the questions you’re raising are also popping up in other places (zeitgeist?). Take a look at this excellent talk from Yolanda Martin, titled "Why User-Centred Design is Going to Get Us Killed” - even the first 5 to 8 minutes are worthwhile to see the (bad) side-effects of meeting a user need.