The Team Attention Map

You open the roadmap, the discovery notes, the delivery board, the sales thread, the support digest, and the metric review. Each one is useful. Each one is also asking you to care about a different version of the product.

By 10am the problem no longer feels like prioritisation. It feels like attention debt. The team is not short of information. It is short of a shared picture of where attention should sit now, where it is stuck, and where nobody is looking.

That is cognitive overload in product work: too many live signals, too little visible agreement about which ones deserve the room.

The mistake: treating overload as a personal sorting problem

Most PMs and POs respond to overload by trying to become better filters. Triage the inbox. Reorder the backlog. Rewrite the roadmap view. Summarise the research. Clean up the metric dashboard.

Those moves can help, but they keep the work private. They imply that if product can just process enough inputs, the team will regain clarity. In practice, the fog often lives between people, not inside one person’s task list.

Engineering is watching a technical constraint harden. Design is carrying a usability concern that did not fit the last planning conversation. Sales is repeating a promise that started as an exception and now sounds like strategy. Support is seeing a pattern customers have not yet escalated loudly enough. The team is full of legitimate attention. It is just not arranged.

The Team Attention Map is a way to make that arrangement visible.

The map

Use it when the team feels busy but strangely under-informed. It is not a prioritisation matrix. It will not tell you which feature wins. It shows where attention is currently sitting around one decision, bet, or product area.

Draw four fields around the decision:

• Customer reality – what users are doing, feeling, avoiding, or working around.
• Delivery reality – what is easy, hard, risky, brittle, or already committed.
• Commercial promise – what we have implied, sold, reported, funded, or let others believe.
• Product bet – what we believe will create value next.

Then mark each field with one of four states:

• Clear – the team has a shared answer good enough to act on.
• Contested – people disagree, and the disagreement is visible.
• Noisy – there is a lot of data or opinion, but little synthesis.
• Neglected – the field matters, but nobody is actively holding it.

The point is not to make the map neat. The point is to stop pretending all attention is equal.

A product bet with clear customer reality and neglected delivery reality is not “ready”. It is a bet with hidden implementation debt. A delivery plan with clear engineering work and noisy customer reality is not “efficient”. It is a machine with weak steering. A commercial promise that is clear to sales and neglected by product is not alignment. It is drift with a deadline.

Once you see the attention pattern, the next conversation gets smaller.

A worked example

Imagine a team working on self-serve billing. The roadmap says “reduce support tickets”. The metric review says billing contacts are up. Sales says enterprise customers need custom invoice rules. Engineering says the billing service is brittle. Design has research showing that small business users cannot tell whether a payment has failed or is still processing.

Without a map, this becomes a general argument about priority. Everyone brings evidence. Everyone is right enough to make the room tired.

With the map, the pattern is easier to name:

• Customer reality: noisy. There are support tickets, research notes, and account anecdotes, but no shared synthesis of the main failure mode.
• Delivery reality: clear. Engineering knows which parts of billing are risky and why.
• Commercial promise: contested. Sales and product are not yet aligned on whether custom invoice rules are exception handling or product direction.
• Product bet: neglected. “Reduce support tickets” is an outcome, but the team has not said which customer behaviour should change.

That does not solve billing. It does something more useful first: it tells the team where to spend attention.

The next move is not another roadmap sort. It is to turn noisy customer reality into a short synthesis, resolve the commercial promise by a named date, and write the product bet in behaviour terms: “Customers can tell what happened to their payment without contacting support.” Only then does prioritisation have something solid to stand on.

How to use it this week

Pick one decision that is creating drag. Not the whole roadmap. Not the quarter. One decision the team keeps circling.

Give yourself twenty minutes.

1. Write the decision in one sentence.

Use plain words: “Should we build custom invoice rules this cycle?” or “What must be true before we commit to self-serve billing changes?” If the sentence takes a paragraph, the decision is still foggy.

2. Fill each field with evidence, not vibes.

Customer reality might include research, behaviour data, support patterns, or recent calls. Delivery reality might include architecture constraints, operational risk, dependencies, or team capacity. Commercial promise includes what has been sold, funded, announced, or strongly implied. Product bet is the value hypothesis the team is asking the product to carry.

Keep each field to three bullets. The limit matters. A map that becomes a document dump is just overload in a nicer shape.

3. Mark the state.

Clear, contested, noisy, or neglected. Do not soften the label. “Partly understood” usually means noisy. “We talked about it last month” often means neglected. “Leadership is aligned” may still mean contested if support, engineering, or design would describe the problem differently.

4. Decide the next attention move.

Each state has a different move:

• Clear: use it as a constraint and stop relitigating it.
• Contested: name the disagreement and who will resolve it by when.
• Noisy: synthesise before deciding.
• Neglected: assign someone to learn enough for the next conversation.

This is where the map earns its keep. It changes “we need alignment” into concrete work: confirm with support, resolve the pricing question, ask engineering for the narrowest safe path, summarise the research in five bullets, decide by Friday.

What to watch for

The first trap is using the map as a performance of maturity. Four boxes, tidy labels, no changed behaviour. That is theatre. If the map does not remove a live question or assign a next attention move, it is decoration.

The second trap is confusing attention with ownership. Product does not have to own every field. Engineering may hold delivery reality. Sales may hold commercial promise. Design or research may hold customer reality. Product’s job is to host the room where those partial views become one decision the organisation can act on.

The third trap is making the product bet too abstract. “Improve billing experience” sounds safe because nobody can disagree with it. It is also too vague to focus attention. “Customers can tell what happened to their payment without contacting support” gives the team something to test, design, build, and measure.

Good maps reduce the number of live questions. They do not make the work simple. They make the complexity visible enough that the team can practise with it.

A line you can reuse

When the room is drowning in inputs, try:

“I think we have an attention problem, not a prioritisation problem. Can we map what is clear, contested, noisy, and neglected before we decide?”

It is a small move. It slows the rush to rank work and asks the team to look at the conditions around the decision.

Seeing practice through attention

I’m writing this quarter about seeing practice because product work often breaks down before the artefacts look wrong. The roadmap can be tidy while attention is scattered. The metric can be visible while the customer reality is noisy. The delivery plan can be credible while the commercial promise is drifting somewhere else.

The Team Attention Map is not a new operating model. It is a habit for shared sense-making. Use it when the team feels overloaded, when every function has a valid signal, and when the next meeting is at risk of becoming another tour of everyone’s inbox.

Cognitive overload eases when attention becomes collective. Not because everyone looks at everything, but because the team can see where to look next.

What would change this week if your next overloaded product conversation started by asking where the team’s attention actually is?