Maps, Territory, and Other Matters: Who’s Reality Are You Serving?
A hand holding a smartphone displaying a map interface, with arrows pointing to THE MAP (the phone screen), THE TERRITORY (the background landscape), and YOU (the hand holding the device).
The one thing I value more than any other personal characteristic, knowledge, skill, experience, or vibe for any in between-type role is the ability to translate and flip between mental models. (Vibe is second). This is the central thing I’m trying to establish when I’m interviewing someone — can you juggle? Can you shift frame? How do you view the world? Are you carrying one map? Or many? Are you stuck in your map?
When you’re taking on big stuff, working with someone with a single world view and framing is difficult. You have to translate everything to their world view, take everything to them, do all the leg work.
Our roles require us to operate in the space in between. Take information from one context and understand how it applies in another. To translate.
The thing that perhaps frustrates me the most about this translator aspect of our roles, is that crap translation work can look remarkably similar to great translation work. In both situations you end up with some information being passed from A to B.
They say the journey matters more than the destination and there’s some truth in that.
As illustrated by an interaction that entirely derailed my day …
Where it started
Some time ago I was drafting some of the first features for a new backlog. A nice purpose statement that ties into wider goals and objectives, clear scope, and some acceptance criteria. You know, the usual backlog stuff.
Now, I just want to own right up front that this wasn’t my best work by any stretch. The feature in question was a known quantity with the team so I had mentally categorised the task as the paperwork and not something that should take a ton of time to craft. I was documenting, not analysing. I was writing the receipt, not making the lunch.
All in all, I spent perhaps five minutes on it before sending it to the PO for a quick review. I thought that was job done. I certainly didn’t expect to be challenged on it. But challenged I was, by the BA on the team.
They challenged my draft on everything from the outcome focus of the purpose statement, to specific use of words.
Look, if you want to immediately convince me you shouldn’t be anywhere near product work, suggest that focusing on outcomes is somehow wrong. But that’s not what really wound me up. It was the feedback about specific words. Sometimes the smallest feedback reveals the biggest problems with how we think about our work.
The feedback wound me up becuase it was was entirely selfish. It wasn’t that the wording actually generated confusion about the scope, objective, or rationale for this feature which is why, when I challenged back, the answer I received was that the wording was not super clear to me and leading to more questions.
But zero actual specific questions.
I mean I totally know that it was feedback for the sake of feedback — another thing that winds me up — but it was actually worse than that. It was feedback to make something work better for them.
Not the team. Not the product owner. Not any of the delivery folk who might need to understand what this feature involved. Just themselves. That’s what they were focused on. Does this work for me? Do I like this?
To this day I honestly don’t know if they realise that that isn’t the point.
Getting to point B
We love to talk about our organisation’s customers and users, and yet, we never talk about our own work using that framing. Our own customers. Our own users. Yes it feels weird to think of our exec/managers as customers, and our delivery team as users, but isn’t that precisely what they are?
Your customer for that feature definition is the product manager that commissioned it. Your users? The developers who need to understand what to build, the testers who need to know what to validate, maybe the support team who’ll need to explain what changed to confused customers.
Everything you produce has a customer. And it also has an end-user. Every output can be viewed through this lens. And you, my in betweener friend, are never the user.
You are not the user
This is the point my colleague entirely missed. They were putting themselves front and centre. They focused on making it clearer for them when they should have focused on the user. Instead of asking is this clear to me?
they should have been asking does the dev team have everything they need?
Of course, it’s all a tad messier than that in reality — it’s not unusual for a single artefact to have a diverse user set. That feature will be used by the team to build the right thing, but it might also be used by the product manager to explain what we’re up to, or by some delivery folk to understand progress. Some doc, multiple use cases.
But the underlying logic remains: What information am I conveying, who needs to use it, and what are they trying to accomplish with it?
These are the same things you need to understand about your organisation’s customers and users (and again for emphasis: none of whom are you!).
Once you start thinking this way, everything sort of shifts. You realise that your personal format preferences don’t matter, but the quality of the resulting understanding does. Documents, features, slide decks, that options paper, the report — they are trying to communicate something to someone. And that someone has their own views on the world. Their own perspective. Their own mental model.
The question shouldn’t be is this done the way I like it?
but will this actually help my users make progress?
And enable progress is all our documents are trying to do.
But, the document is not reality
Most of what we do is model reality in different ways. Represent it. Document it. Summarise it. That storymap is a model of a system. That options paper is representing various possible futures. That feature definition is documenting a proposed change. That slide deck summarises what the team has delivered.
They are in and of themselves, not reality. Just helpful representations thereof.
Here’s the important bit: That same reality can be represented in a infinite number of ways.
That feature I was drafting? I could have written it as a user story, turned it into a slide for the exec, created a process flow, sketched a wireframe, converted the acceptance criteria into given-when-then statements. Same feature, same reality, just different representations. Different formats. Different mental models.
None of these formats are more right. They’re different representations suitable for different jobs. And this is where good translation work is very distinct from the mediocre version. Good translators don’t get attached to formats, they choose the representation that works best for the people who need to use it to get something done. Good translations match the mental models of the receiver.
So once you’ve asked will this actually help my users make progress?
then ask what’s the best format to enable this?
The format matters. But there are limits …
If a document is just a representation of reality, then it can easily become a distraction from reality.
Perfecting a process map doesn’t actually fix the process. Arguing about user story formats doesn’t help us understand our users. Discussing the structure of an options paper does not help us understand the options. When you get caught up in the format, you’re actually prioritising the representation over the thing it’s supposed to represent. You’re focusing on the map instead of the territory.
The document is just a tool. If it’s not helping people understand reality better or make progress with reality, then it’s not doing its job.
Look, I know that most of the time we don’t even really need to think about format as our processes have expected standards and outputs. Most backlogs have a template that helps you capture the right information consistently. Most organisations have acceptance criteria standards to help you avoid vague targets. These aren’t arbitrary format choices, they’re building quality into the process.
They help. They can also be a trap.
There’s a difference between maintaining standards that serve the work, and defending formats that match your personal preferences. The latter is about making yourself more comfortable with documents you’re not even going to use.
You are not a first order concern
I think the biggest issue is that the very trait that often distinguishes a junior analyst from their peers — their endless quest for understanding — teaches you the wrong lesson.
As a junior you have to put yourself in the middle of things because you need to understand it first, before you can help someone else understand it. Just like the three year old practically has to ask but why a million time to understand and build a mental model of the world they’re in, so goes a junior analyst. Endless questions, seeking clarity are a completely necessary and appropriate part of the learning.
But because this is where they started, many people conclude that their job is to be in the middle.
They see their value as being the person who understands everything. The door that all information must pass through. It’s the let me get my head around this first, then I’ll explain it to you
approach.
Alternatively, if we look to actual language to language translators — the really good ones disappear into the background. Two people have a conversation, and the translator makes that conversation possible without becoming part of it. They’re not standing there saying hang on, let me make sure I understand what you’re saying before I translate it.
Their concern is the understanding of the two parties — not their own.
They also don’t just transactionally translate word by word. Expression nuance is conveyed as accurately as possible across the language barrier.
Elements of this are true for us. You don’t need to be in the middle to enable. You can be to the side. A facilitator. You can carry the subtlety.
A map of maps
Now, there is of course a base level of understanding that all our in between roles need in order to enable flow, but is often less than you’d think. More focused on the shape of things — the constraints, the context, the relationships, and the objective — rather than the detail.
To do any of this well, you need to quickly understand what models different people are using. The developer is probably thinking technical implementation, the product manager is (hopefully) thinking of user value, the exec is mulling business outcomes (or his next career move). Your job isn’t to translate everything into your preferred model, it’s to help them communicate between their models.
This is exactly what good translators do. They understand that everyone is carrying different maps of the same territory.
Where the junior approach tries to create one master map that everyone must use. The senior approach helps people understand how their different maps relate to each other. Draws bridges and connections.
You’re not trying to be the single source of truth. You’re helping people see how their perspectives connect. You’re building a map of maps.
The real work
So here we arrive, back where we started: why the ability to flip between mental models without getting stuck in any particular one is so key to doing good work.
This ability is what separates great translation work from the mediocre version that looks identical on the surface. Both move information from A to B. And yet, one is self-serving while the other is service.
Great translators aren’t committed to their preferred map of the world. They’re committed to helping people understand their part of the territory and how it connects to everyone else’s. They choose the right representation for the right audience. They facilitate the team’s understanding and not just their own. They focus on the users of their work and everything that being user-centric entails.
So please don’t get stuck in your own map. Don’t seek understanding for your own sake. That’s not the job.
The job is helping other people understand their part of the reality we’re all trying to wrangle together. And that kind of understanding — the kind that actually helps teams build the right thing — definitely won’t be derailed by your personal preferences about word choice in a feature description for heavens sake.
Last updated .