The user is the anchor. That is the discipline most organizations quietly resist.
They do not resist it because they hate users. They resist it because the org chart is closer. It has names, budgets, managers, politics, rituals, and reporting lines. It feels real. The user need is often a sentence on a slide. The org chart is where consequences happen.
Wardley Mapping flips the order. Start with the user. Then the need. Then the capabilities required to meet that need. Only after that should you ask how the organization is arranged.
This is not a sentimental customer-centricity point. It is an operating point. If you start with the org chart, you map responsibilities. If you start with the user, you map dependencies.
Dependencies are where strategy usually breaks.
Take an enterprise AI assistant. The user may be a sales rep trying to prepare for a renewal conversation. The need is not “use AI.” The need is to understand account risk, recent product usage, open support issues, stakeholder history, commercial terms, and likely objections quickly enough to have a better conversation.
The value chain cuts across CRM, support systems, product analytics, contracts, call notes, permission models, retrieval, model interaction, and sales workflow. No single function owns the whole experience. If you start with the org chart, each team optimizes its piece. If you start with the user, you can see whether the chain works.
This is where systems of record and systems of context matter. The CRM may be the official record. It may not contain the context needed for good judgment. The support tool may hold customer pain. Product analytics may reveal adoption risk. Call transcripts may contain political reality. The AI interface may be only the final surface. Mapping forces the operator to ask where truth lives, where context lives, and where the user actually works.
The anti-pattern is anchoring on internal ownership. “This is a RevOps project.” “This belongs to IT.” “Product owns usage data.” “Legal owns policy.” Those statements may be administratively true and strategically useless. The customer does not experience your reporting lines. The employee trying to do the work does not care which VP owns the database. They experience the chain.
Once the user is the anchor, some awkward questions become unavoidable.
Which capabilities are visible to the user? Which failures does the user feel immediately? Which dependencies are invisible until they break? Which teams are funded even though their work no longer maps to the need? Which unfunded glue work keeps the whole thing alive?
AI exposes this sharply. Many agent projects fail because the user workflow is treated as an implementation detail. The organization buys or builds an agent, then discovers that permissions are unclear, source data is dirty, policies are contradictory, and exception handling depends on three people who were never in the project plan. The agent did not fail alone. The mapped chain was never made visible.
Starting with the user also protects against executive hobbyism. A senior leader sees a new tool and imagines a use case. The tool becomes the anchor. Then teams search for adoption. Mapping pushes back: whose need is this serving? What must be true underneath? Is the need frequent, painful, and worth changing behavior for?
If not, you do not have strategy. You have procurement with a narrative.
There is a second benefit. User anchoring helps resolve platform debates. Platform teams often want consistency. Business teams want local speed. Security wants control. Finance wants cost discipline. Those are real concerns, but the user need tells you where flexibility matters and where standardization is safe.
For a commodity capability buried deep in the chain, standardize hard. For a user-visible workflow still being discovered, allow more variation. For shared context that many workflows depend on, treat it as strategic infrastructure. For a low-value internal preference, stop dressing it up as user need.
Operator artifact: for any major initiative, write three lines before discussing solution or ownership:
- User: who is being served?
- Need: what do they need to do better?
- Chain: what capabilities must work for that need to be met?
If the room cannot agree on those three lines, the org chart is about to make the decision for you.
This is part 3 of 10 in Wardley Mapping for Operators.
