Thinking modes
Linear · wave · node · matrix — and how AI helps people bridge across them
Do you keep feeling like none of your teams can communicate effectively? Do you see people factionalising along lines that look like personality clashes but never quite resolve when you reshuffle the team? Do strategy days produce documents nobody acts on, standups feel like interrogations, briefs arrive at the dev team unbuildable, and roadmap meetings tune out the customer signal that turns out to matter six months later? Have you tried personality frameworks, communication training, restructuring, hiring, and found that the same arguments keep coming back in a slightly different shape?
If any of that is recognisable, the diagnosis you have probably been given is wrong. It is not that your people cannot communicate. It is that they are operating in different modes of thinking, and nobody has given them a vocabulary for the mode they are in or a way to translate between them. Mode mismatches read as personality clashes, competence gaps, or cultural misfits — and as long as they are read that way, every fix you try will land slightly off the actual problem.
Every team has a mode it does well and a mode it pretends to do. The mode it does well is the one that produced its early wins, that its best people lean into, that gets rewarded in performance reviews and shows up in the way meetings are run. The mode it pretends to do is the one the work also requires but nobody really owns — the strategy phase that gets skipped, the structuring middle that gets hand-waved, the activation arc that nobody watches once the launch is done. Most of what feels like dysfunction in a team is the gap between those two modes catching up with them.
This document is a vocabulary for noticing the gap. It names ten ways of holding information — four pure modes at the corners (red linear, yellow wave, deep green node, deep blue matrix), four transitions that describe how one mode hands off to the next (purple, orange, mint, light blue), and two orchestration arcs that describe how the modes chain together over time (white for creation, black for activation). Each one names a kind of work, not a kind of person. The same person moves between several of them in a single day; the same team is asked to do all of them across a project.
The framework is descriptive before it is prescriptive. It does not tell you which mode is best, or which mode you should be in, or how to “fix” someone who is in the wrong one. It tells you what each mode is good for, what it needs to do its best work, how it tends to be misread by other modes, and where AI can act as a bridge so two people in different modes can collaborate without having to leave their home mode entirely. Most prompt failures, most meeting failures, and most cross-functional failures are mode-mismatch failures. Once you can name the mismatch, you can usually fix it.
A note on how to read this. The taxonomy is built bottom-up — each mode in turn, then the orchestration arcs, then worked examples for the most common bridge problems. If you are reading it as a piece of thinking, take it in order. If you are reading it because something is broken and you need a fix, jump to the friction index in the next section, find the problem closest to yours, and follow the pointers from there. The modes will still make more sense once you have read them, but the index will get you to the relevant ones first.
What problems this framework solves
Most teams have the same four arguments on a loop. Strategy days that produce nothing anyone builds. Standups where the engineer feels interrogated and the lead feels stonewalled. Briefs that arrive at the dev team unbuildable and bounce back to the PM as “more detail please”. Marketing bringing customer signal into a roadmap meeting and watching it get tuned out as anecdote. None of these are competence problems. All of them are mode-mismatch problems being read as competence problems, which is what makes them hard to fix — both sides walk away convinced the other side is the issue.
This framework gives you a vocabulary for what actually broke. Instead of “the PM is fluffy” or “the engineer is rigid,” you get “a deep blue artefact was handed to a red thinker without a purple pass through the middle.” That sentence sounds technical but it is doing useful work: it names the missing step, points at who is best placed to do it, and makes the fix a process change rather than a personality clash.
The framework solves four specific problems.
It names handoff failures so you can fix the handoff rather than blame the people. Most cross-functional friction is not about the people in the room. It is about a missing translation step between two modes that do not naturally speak to each other. Once you can see the handoff, you can build a ritual around it — a kick-off, a scoping doc, a translation prompt — instead of relabelling the same fight every quarter.
It tells you which AI tool fits which problem. “Use AI more” is useless advice. “Use a long-context model to freeze a six-month log into a node map for the next person” is actionable. The framework gives you a diagnostic for matching the model to the mode and the prompt pattern to the handoff, so AI stops being a vague productivity claim and starts being a specific bridge between specific people.
It explains why high-performing people sometimes look like underperformers. A node thinker measured on output volume looks lazy. A wave thinker asked for a point estimate looks evasive. A matrix thinker pushed for a fast answer looks paralysed. In each case the value the person brings is real but invisible to the metric being applied. The framework makes the gift legible so it can be measured on its own terms instead of someone else’s.
It separates “we need a different person” from “we need a different process”. This is the move that distinguishes it from trait frameworks. When a team is struggling, the trait-framework reflex is to hire for the missing colour. The task-framework reflex is to ask which mode the current work is skipping and whether the people you already have can cover it with the right handoff. Sometimes the answer is still hiring. Often it is not.
What this is and is not
If you have spent time with Myers-Briggs, Insights Discovery, DISC, or similar frameworks, the colours below will look familiar in a way that is going to mislead you. Those frameworks are about people and output behaviours. This one is about the tasks people do and their default thinking modes.
In a trait framework, the colour is who you are — the result of a test that measures consistent behaviours and sorts you accordingly. The claim is that the result is reasonably stable, and the framework helps a team by sorting members and noticing that, say, the blue and the yellow will need a translator.
In this framework, the colour is what the work is asking for right now, and your default thinking mode is the one you reach for when the work has not told you which mode it needs. The same person can be in deep blue at ten in the morning (mapping a strategic field), in red by eleven (writing the spec that came out of it), in orange by two (clearing the queue of comments), and in yellow by four (watching how the change is landing). Their default may be deep blue — that is where they go when the work is ambiguous — but the work itself can pull them through every other mode in a single day. The default has not changed. The work has.
This matters because the diagnostic moves you make are different. A trait framework says: this team is unbalanced, hire a green. A task framework says: this team has skipped the deep-green phase of its current project, and the symptoms you are seeing are what skipping that phase always produces. The first is a hiring conversation. The second is a process conversation. Both can be right; they are not the same conversation.
People do still have defaults. Most people are more comfortable in some modes than others — a home base — and a team’s centre of gravity shifts the modes it tends to skip. But the default is a tendency, not an identity, and the diagnostic value here lives in the verbs, not the nouns.
The aim is to make a single team able to be self-sufficient and move through all phases by themselves, otherwise they have dependencies. A team that can only do red and orange will always be waiting on someone else to hand them the matrix; a team that can only do deep blue and light blue will always be waiting on someone else to turn the matrix into action. Both teams look productive in their own mode and stuck at the handoff, and both end up blaming the other side for the gap. The fix is not to merge the teams. The fix is to give each team enough fluency in the adjacent modes — with AI doing the heavy lifting at the bridges — that they can finish the arc themselves and only escalate when the work genuinely needs another team’s gift.
Self-sufficiency does not mean every team member is good at every mode. It means the team as a unit can recognise which mode the work is asking for, has at least one person who can hold that mode credibly, and has the tools and vocabulary to translate between modes without losing what matters. A team that hits this bar stops generating the kind of dependency that shows up as “blocked on strategy” or “blocked on engineering” in every standup — because the team itself can do the structuring middle, and only reaches outside when the work has genuinely exceeded what they can hold.
1. Purple — Matrix → linear
Axis: Breadth → depth
A grid of nodes on the left compresses into a single sequential row. The transformation collapses many simultaneous relationships into one focused, ordered path. This mode commits to a course of action after holding the whole field in mind.
Who tends to lean this way
People who lean into this transition are often the ones who feel comfortable in messy strategy sessions but get restless until something becomes a plan. They tend to gravitate toward roles like product management, founders moving from vision to roadmap, programme leads, editors-in-chief, and chiefs-of-staff — places where the job is to take a wide problem space and turn it into a sequence other people can act on.
What they need to do their best work
What helps: time to sit with the full picture before being asked to commit, and a collaborator who will not push for the linear plan too early. What drains: being forced to commit before the matrix feels complete. What kills flow: being interrupted while collapsing the matrix — the synthesis is fragile until it is written down.
How other modes can misread them
If misunderstood, this person can look indecisive to linear thinkers (”why are they still rewriting the plan?”) and reductive to matrix thinkers (”they flattened all the nuance into a list”). In a role that demands pure execution, they look slow; in a role that demands pure exploration, they look like they are closing things off too early. The thing being missed is that the value lives in the moment of compression itself — the move from many possibilities to one ordered path. Pushed into pure linear work, they become frustrated mediators of a plan they would have written differently. Pushed into pure matrix work, they get visibly restless because nothing is becoming.
AI as a bridge
AI is most useful here as a translator. Hand it the matrix — the messy notes, the comparison table, the half-formed thoughts — and ask for a sequenced plan. Claude (Opus or Sonnet) is well-suited: it holds long context and produces structured prose, so it can take a wide brief and return a coherent ordered draft. Useful prompt pattern: “Here is everything I am holding. Give me the three orderings that make most sense, with the trade-offs of each.” The point is not to let AI choose for you but to externalise the matrix so the linear path becomes easier to see.
2. Red — Linear thinking
Axis: Depth
One step at a time, in order. This mode is at its best when there is a single right path and the cost of skipping ahead is high. Focus narrows as the sequence advances.
Who tends to lean this way
People who lean linear often gravitate toward roles where order genuinely matters: legal drafting, compliance, accounting and audit, engineering with strict dependencies, surgery, aviation, project execution against a Gantt chart. Many of them are excellent at these jobs because they hold the discipline that other modes find tedious.
What they need to do their best work
What helps: a clear specification, one task at a time, and protection from new requirements mid-stream. What drains: being asked to ideate across many possibilities without a north star. What kills flow: someone re-opening step three when they are already on step seven.
How other modes can misread them
If misunderstood, this person can look rigid or unimaginative to matrix and node thinkers (”why won’t they just brainstorm with us?”) and slow to wave thinkers (”they’re still on item one while the situation has changed three times”). In a brainstorm or open strategy session, they look unresponsive — but they are usually waiting for the field to settle into something they can sequence. The thing being missed is that their precision is the asset; the discipline they bring is what stops the plan unravelling in delivery. Pushed into a role that demands constant re-prioritisation or open-ended ideation, they burn out fast and start looking like a poor cultural fit, when in fact they have been put in the wrong mode for their gift.
AI as a bridge
AI can absorb the chaos that interrupts linear flow. Use a fast model (Claude Haiku, Gemini Flash, GPT mini) as a buffer — let it handle the inbound questions, the half-formed pings, the “can you also...” requests — and only surface the ones that genuinely change the path. Useful prompt pattern: “Here is my current step. Tell me only if any of this new information actually invalidates it.” For the deep work itself, Claude is good at staying inside a single specification without drifting.
3. Orange — Linear → wave (queues)
Axis: Depth
Sequential steps gain rhythm and timing. Items are still ordered but now move with pressure and pacing — the line bends into a wave. This is where queues, throughput and back-pressure first appear.
Who tends to lean this way
People who lean into this transition often work in operations, logistics, customer support team-leads, manufacturing, restaurant kitchens, ER triage, and live service incident response. The job is rarely about one perfect step — it is about keeping the line moving when items arrive faster than they can be processed.
What they need to do their best work
What helps: visibility into the queue and permission to drop or defer items. What drains: pretending every item gets the same depth of attention. What kills flow: a stakeholder who watches one item rather than the throughput.
How other modes can misread them
If misunderstood, this person can look careless to linear thinkers (”they didn’t finish item three properly”) and chaotic to matrix thinkers (”they don’t have a strategy, they’re just reacting”). In a culture that prizes craft per item, they look like they cut corners; in a culture that prizes long planning, they look reactive. The thing being missed is that the craft is in the throughput, not the individual item — keeping the queue moving with acceptable quality is a different skill from making any single item perfect. Pushed into a role that requires deep sequential focus or long-horizon planning, they feel trapped and start dropping balls; the rhythm they are good at evaporates.
AI as a bridge
AI is useful here as a triage layer. A fast model (Haiku, Flash, or GPT mini) can sort and tag inbound work, surface the items that need a human, and draft holding responses to the rest. Useful prompt pattern: “For each item in this queue, tag it as: act now, act later, drop, or escalate — and explain why in one line.” The goal is to keep the human in the rhythm rather than letting one slow item collapse the whole queue.
4. Yellow — Wave thinking
Axis: Depth
Cycles, frequencies and amplitudes. Patterns repeat — pressure builds and releases over time. This mode notices rhythm in a system: which signals oscillate, where they peak, and how their timing interacts.
Who tends to lean this way
People who lean wave often gravitate toward trading and markets, performance and live music, professional sport coaching, weather and climate work, monetary policy, public health surveillance, and any domain where the same shape recurs at different frequencies and the skill is in reading the cycle.
What they need to do their best work
What helps: long enough time-series to feel the pattern, and patience from collaborators who want a one-shot answer. What drains: being asked for a point estimate when the truth is a distribution. What kills flow: zooming in on one trough and treating it as the whole picture.
How other modes can misread them
If misunderstood, this person can look evasive to linear thinkers (”why won’t they just tell me yes or no?”) and superstitious to matrix thinkers (”they’re seeing patterns that aren’t there”). When asked for a forecast they will hedge, which reads as weakness in cultures that reward confident answers — but the hedge is honest, because their truth is a distribution rather than a point. The thing being missed is that they are tracking a signal across time, and time has not yet given the answer. Pushed into a role that demands single-shot decisions with no follow-up, they get judged on each call in isolation rather than across the cycle they were actually reading; pushed into a static analytical role, they lose the live signal that is their real instrument.
AI as a bridge
AI is most useful here for pattern surfacing across long history. Models with very large context windows shine — Gemini, or Claude’s long-context modes — because the whole signal can sit in one prompt. Useful prompt pattern: “Here is X months of data. Tell me which cycles I am riding, how they interact, and what is anomalous versus what is just the next peak.” Pair this with a fast model that watches live data for the moment a cycle turns.
5. Mint green — Wave → graph (nodes)
Axis: Depth → breadth
Continuous rhythms freeze into discrete points. Wave peaks crystallise into nodes and connect into a network. The mode opens up: instead of one rhythm in time, you can see many things related to each other at once.
Who tends to lean this way
People who lean into this transition often sit in roles that turn live signals into structured maps: data analysts moving from time-series to dashboards, journalists turning a story arc into a stakeholder map, ethnographers, UX researchers synthesising interviews, public health epidemiologists building contact graphs. They are often quietly bilingual — comfortable in the wave and in the network.
What they need to do their best work
What helps: time and tools to do the freeze well, and stakeholders who accept that the map is provisional. What drains: being asked for the network before the wave has shown its shape. What kills flow: a final-looking artefact too early.
How other modes can misread them
If misunderstood, this person can look slow to wave thinkers (”why are they stopping to draw a diagram, the situation is still moving”) and overly tentative to node thinkers (”why won’t they commit to the map?”). They sit in an awkward middle space where neither mode quite trusts them: too analytical for the live operators, too provisional for the network strategists. The thing being missed is that the freeze is the whole job — the moment of converting a moving signal into a structure other people can use is what they bring. Pushed too far toward pure live work, they lose the synthesis time they need; pushed too far toward pure structural work, they lose the live signal that gives the map its truth.
AI as a bridge
AI is useful here as the freezing tool itself. A long-context model can read a transcript, a six-month log, or a stack of interview notes and return a node-edge structure. Claude is good at the synthesis-into-structure step; Gemini’s context size lets you feed the raw material whole. Useful prompt pattern: “Read this and give me the nodes (the recurring entities), the edges (the relationships between them), and the three patterns that surprised you.” Treat the output as a draft map, not a verdict.
6. Deep green — Node thinking
Axis: Breadth
Relationships between things. Meaning lives in the connections — many threads held in parallel. The shape of the network matters more than any single item; clusters, hubs and bridges become visible.
Who tends to lean this way
People who lean node often work in community building, network organising, partnerships and BD, recruiting, journalism that depends on sources, anthropology, and any role where the asset is a living web of relationships. Some engineers and architects also lean here — the ones who care about systems and dependencies more than features.
What they need to do their best work
What helps: visibility into the whole network and tolerance for non-linear answers (”it depends on who you talk to first”). What drains: being treated as a list-of-contacts rather than a navigator. What kills flow: a request that flattens the network into a table.
How other modes can misread them
If misunderstood, this person can look unfocused to linear thinkers (”they spent the whole day on calls, what did they actually deliver?”) and unrigorous to matrix thinkers (”their answer changes depending on who they spoke to last”). In a metrics-driven environment they can look like they are not producing — because their work is the network itself, which does not show up in a dashboard until much later. The thing being missed is that the relationships they are tending are infrastructure; their value is realised when someone else needs an introduction, a warm thread, or a sense of who actually holds the decision. Pushed into a role measured purely on output volume or analytical rigour, they look like underperformers — and the network they were tending atrophies the moment they are reassigned.
AI as a bridge
AI as a memory and surfacing layer. Tools with persistent memory (Claude Projects, ChatGPT Memory, Gemini Gems) let you keep the network warm — who is connected to whom, who you owe a reply, who matters for which question. Useful prompt pattern: “Given everything you know about my network, who should I introduce to whom this month, and what is the warm thread between them?” The model is not the network; it is the index that helps you walk it.
7. Light blue — Graph → matrix
Axis: Breadth
Connections become coordinates. The graph projects onto a grid where every pair of nodes has a cell. This mode reveals coverage — what is connected, what is not, and the shape of the whole space at once.
Who tends to lean this way
People who lean into this transition often sit in roles that need to make a network legible: portfolio managers, investors mapping a market, sales ops building account matrices, organisational designers, urban planners, and researchers running comparative studies. They want the whole picture in one frame.
What they need to do their best work
What helps: enough nodes to make the matrix meaningful, and stakeholders who can read a grid. What drains: being asked for a single-line summary of a multi-axis truth. What kills flow: someone insisting on a ranking when the answer is a Pareto front.
How other modes can misread them
If misunderstood, this person can look cold or reductive to node thinkers (”they turned my network of relationships into a spreadsheet”) and over-engineered to linear thinkers (”why do we need a four-axis matrix to choose, just pick one”). Their instinct to systematise can read as bureaucratic in fast cultures and impersonal in relational ones. The thing being missed is that the matrix is how they hold complexity honestly — refusing to collapse a multi-dimensional question into a single number. Pushed into a role that demands fast intuitive calls, they become the person who slows decisions down with another spreadsheet; pushed into a role that demands relational warmth, they look detached.
AI as a bridge
AI is useful here as a coverage checker. A reasoning model can take a graph and tell you which cells are empty, which are dense, and which combinations are unexplored. Useful prompt pattern: “Given this list of customers and these axes (segment, stage, ARR), which cells of the matrix are empty and which are crowded? Suggest one move per empty cell.” Gemini’s reasoning modes and Claude’s extended thinking are both well-suited; the work is more about systematic coverage than creativity.
8. Deep blue — Matrix thinking
Axis: Breadth
Every dimension considered at once. Patterns emerge from the whole field, not any single cell. This is the widest mode — total parallel awareness of the system before any single path is chosen.
Who tends to lean this way
People who lean matrix often gravitate toward strategy, venture and PE investing, foreign policy, antitrust and economics, scenario planning, and very senior product or design roles. The job is to hold the whole field — every option, every dependency, every second-order effect — long enough to find a move that the linear thinkers have not seen.
What they need to do their best work
What helps: dense, well-organised information and time to sit with it before being asked to decide. What drains: being asked “what should we do?” before the field is mapped. What kills flow: pressure to oversimplify.
How other modes can misread them
If misunderstood, this person can look paralysed to linear thinkers (”they have been thinking about this for three weeks”), aloof to node thinkers (”they never ask anyone what they think”), and abstract to wave thinkers (”the situation has moved twice since they started this analysis”). In an action-biased culture they get labelled as overthinkers; in a fast-moving operational role they look detached from reality. The thing being missed is that the value of this mode is precisely the moves it finds that nobody else can see — the second-order effects, the unrelated dependencies, the option that becomes obvious only when the whole field is mapped. Pushed into a role with no time to map, they produce shallow versions of their gift; pushed into pure execution, they disengage and look like they are coasting.
AI as a bridge
AI is most useful here as a co-explorer. Use the largest, slowest, most thoughtful model available — Claude Opus with extended thinking, GPT with deep reasoning, Gemini Pro — and run scenarios against it. Useful prompt pattern: “Here are six dimensions of this decision. Walk through the matrix and tell me where the dominant strategies cluster and where the trade-offs are real.” Pair the matrix model with a faster one that summarises for stakeholders who are not in this mode.
9. White — Orchestration — creation
Axis: Breadth → depth
The creation arc. Deep blue scans the whole field, light blue maps the relationships, deep green finds the structure, and purple commits to a single linear path. Each mode informs the next; the structure is built before it acts.
Who tends to lean this way
Whole teams orchestrate this arc, rarely one person. Strategy and design teams live in the breadth end; delivery and execution teams live in the depth end. The friction is almost always at the handoffs — the matrix thinker hands a half-finished map to the linear thinker, who needs an ordered list. Mature teams build explicit rituals for each handoff (kick-offs, design reviews, scoping docs) rather than expecting the modes to translate themselves.
What they need to do their best work
What helps: explicit recognition that the arc has phases and that each phase has its own pace. What drains: a culture that rewards only one mode. What kills flow: jumping from breadth straight to delivery without the middle two modes.
How other modes can misread them
When this arc breaks, each mode misreads the next. The matrix team thinks the linear team is unimaginative; the linear team thinks the matrix team is precious and slow. The node team thinks both are missing the human reality; the matrix team thinks the node team is anecdotal. Without a shared vocabulary, every handoff becomes a complaint about the other side’s competence rather than a recognition that the next mode is doing different work. The thing being missed at the team level is that the arc itself is the deliverable — no single mode owns the outcome, and rewarding only one mode (usually whichever produces the most legible artefact) starves the others. Teams put under pressure to skip phases produce strategies with no plans, plans with no maps, and maps with no people.
AI as a bridge
This is where AI does its most useful work — not inside any single mode, but at the handoffs between them. Use a long-context model (Claude, Gemini) to take a matrix-thinker’s notes and return a node map for the connector to refine. Then ask the same or another model to turn the node map into a sequenced plan the linear thinker can execute. Useful prompt pattern at each handoff: “Take this artefact and translate it into the mode the next person works in — keep what matters, drop what does not.” The bridge is not a single magic prompt; it is a habit of using AI to make the next person’s job possible without forcing them into your mode.
10. Black — Orchestration — activation
Axis: Depth → breadth
The activation arc. Red triggers the action, orange queues the work, yellow drives it through repeating cycles, and mint spreads the result into a network. Activation cascades from one focused trigger out to a wide system.
Who tends to lean this way
This arc is the natural home of operations, growth, customer success, live service teams, marketing campaigns, and incident response. The skill is taking one decision and rippling it out through a system without losing the thread. The friction here is the opposite of the creation arc: depth thinkers want to keep the trigger clean and simple; breadth thinkers want to know what it means for everything else.
What they need to do their best work
What helps: a clear trigger, a queue people trust, and a feedback loop from the spread back to the source. What drains: launches with no monitoring. What kills flow: changing the trigger after the wave has started.
How other modes can misread them
When this arc breaks, the failure mode is a launch that nobody owns end-to-end. The trigger people (red, orange) think the spread people (mint) are over-thinking the second-order effects; the spread people think the trigger people are firing without watching where the ripples land. Yellow’s rhythm gets read as either complacency (”they’re not doing anything new”) or panic (”they’re constantly adjusting”) depending on whose mode you sit in. The thing being missed at the team level is that activation is not the same as creation — the work is sustaining a cascade, not making a decision — and judging it on the criteria of the creation arc (clarity, novelty, completeness) starves the cycle of the rhythm and feedback it needs. A team forced to relaunch every quarter never builds the wave; a team that never reads the spread never learns whether the trigger landed.
AI as a bridge
AI sits across this whole arc. A small fast model triggers and queues (Haiku, Flash, GPT mini). A mid-tier model runs the cycles and watches the rhythm (Sonnet, GPT, Gemini Pro). A large reasoning model reads the spread back and tells you what the network now looks like (Opus, GPT extended thinking, Gemini Pro reasoning). Useful prompt pattern at each phase: at trigger, “is this the right moment?”; at queue, “what is being delayed and is that okay?”; at cycle, “is the rhythm holding?”; at spread, “what shifted in the network because of this?”. The job is not to automate any one phase but to make the whole cascade visible to a human.
Worked examples
The taxonomy is most useful at the handoffs. Below are three common bridge problems, each shown as a short vignette plus prompt patterns at three levels of scale. Each persona names the modes in play, the handoff that is failing, and prompts that bridge it. The prompts are written for Claude given the audience for this document, but the patterns work with any frontier model — the framework gives you the diagnostic.
Persona 1: the developer giving a daily update
Modes in play: the developer is operating in red (one task, sequenced, depth) and possibly orange (managing a queue of tickets). The scrum master or product owner is operating in purple at best (matrix-to-linear; trying to reconstruct a plan from updates) and at worst in deep blue (matrix; scanning for risks across the whole programme). The friction is that the developer’s natural output — what I did, what I am doing, what is blocking me — is a depth artefact, and the listener is trying to extract a breadth artefact from it.
What the developer needs from AI: a translator from depth to breadth without leaving red. The developer should not have to think in matrix. AI should do the projection.
Easy: the daily standup update
Setting: you have a few rough notes from yesterday — commits, a Slack thread, a ticket you closed, one you opened. You need three sentences for the standup that the PM can actually use.
Prompt
Here are my notes from yesterday: [paste]. Give me a three-line standup update in this shape: yesterday I (one line, outcome not activity), today I am (one line, outcome not activity), blocked on (one line, or “nothing”). Keep it boring. Do not editorialise.
The “outcome not activity” framing is the matrix-to-linear move: instead of “I worked on the auth refactor” (a depth statement that tells the listener nothing about the plan), you get “I finished the auth refactor pending review” (a position on the plan, which is what purple actually wants).
Medium: a written async update for a non-technical lead
Setting: your team has gone async and you owe a weekly written update to a product owner who does not know the codebase. They do not want a changelog; they want to know whether the thing is on track and what they should worry about.
Prompt
Here are my commits, PRs, and rough notes from this week: [paste]. Write a weekly update for a non-technical product owner. Three sections: where we are versus the plan (one paragraph, plain language, no jargon), what changed in the plan and why (only if it changed), what to watch next week (specific and actionable). If you are tempted to use the words “leveraged,” “delivered,” or “stakeholder,” try again.
Two things this prompt does. The plain-language constraint forces the AI to project from depth into the listener’s frame. The constraint on what the third section must look like (specific and actionable) prevents the model from defaulting to “continue monitoring,” which is the standard AI failure mode for status updates.
Hard: a programme-level update across multiple developers and a critical incident
Setting: you are tech lead. There are six engineers, two workstreams, an incident from Tuesday that is mostly resolved but has a long tail, and a senior product owner who needs to brief their own director by end of day. The PO does not want detail; they want to know what to say in their own meeting and what risks to flag.
Prompt
Context: [paste rough notes from each engineer, the incident postmortem-in-progress, and the original quarterly plan]. The audience is a senior PO who is briefing their director in two hours. They are not technical. Produce two artefacts. First, a four-bullet summary the PO can paraphrase in their meeting: where the programme is against plan, what changed materially, what the incident actually means for the roadmap (be honest), and the one thing the director should know. Second, a separate “risk register delta” — only the risks whose status changed this week, not the full register. For each: what changed, why, and the decision the director might be asked to make. If a risk did not change, do not mention it. Tone: dry, specific, no hedging adjectives. If you are not sure about something, say “unclear” rather than smoothing over it.
This prompt is doing the full purple compression for a hostile context — many depth inputs, a single breadth output, an audience that will punish hedging more than it will punish bad news. The split between the summary and the risk delta is the framework’s matrix-to-linear move done explicitly: the summary is the linear path the director will repeat, the risk delta is the matrix view the director may need to act on.
Persona 2: the product manager with vague ideas
Modes in play: the PM is operating somewhere between deep blue (matrix; holding the whole problem field) and deep green (node; tracking who needs what and which threads are warm). The developer they are handing off to is operating in red and needs a sequenced spec they can build from. The classic friction is that the PM hands over a deep blue artefact (a vision, a strategy doc, a Miro board) and expects red to translate it themselves.
What the PM needs from AI: a structured intermediate artefact — a light blue matrix, a deep green map, or a purple sequence — depending on how mature the idea is. The mistake is reaching for the sequenced plan too early. The role of AI here is to do the structuring middle that the PM does not want to do and that the developer cannot do without it.
Easy: a small feature idea you cannot quite articulate
Setting: you have a feeling that users are dropping out of onboarding, but you cannot say exactly where or why. You want to give your developer something to look at, not a full spec.
Prompt
Rough thought: I think users are dropping out of onboarding somewhere and I do not know where. Help me get from this to something a developer can act on. Ask me five questions, one at a time, that will sharpen this enough to write a one-paragraph problem statement and a list of three things we could measure first. Do not write the spec yet. Just sharpen the question.
Note the prompt is not asking for the spec. It is asking the AI to act as the deep blue partner the PM does not have access to. The five questions force the matrix to fill in before any handoff happens. Once the answers exist, the next prompt can be a purple compression.
Medium: a feature with a clear goal but unclear scope
Setting: leadership wants “better notifications.” You know the goal (re-engage users in week two), but the scope could be anything from a single email change to a full notification platform. You need to give the dev team something they can scope without committing prematurely.
Prompt
Goal: re-engage users in week two via notifications. The scope is currently undefined and could be anywhere from a single email change to a multi-channel notification platform. Help me produce a scoping document with three options at different levels of investment: a one-week version, a one-sprint version, and a one-quarter version. For each, give me: what we would actually build, what we would learn from it, what we would not be able to learn, and what would have to be true for this to be the right level of investment. Do not pick. The point is to give my engineering lead something to react to. Frame each option in the same shape so they are comparable.
This is a light blue prompt — coverage across a multi-axis space, structured so the next person can read it. The PM is not asking the AI to choose. They are asking the AI to make the choice space legible. That is the move that lets a developer engage without feeling like they are being asked to do the PM’s job.
Hard: a multi-quarter strategic bet that does not yet exist
Setting: the CEO has said “we should be doing more with AI in our product.” Nothing more specific than that. You have to come back in two weeks with something the engineering team can start building toward and the leadership team can defend to the board. There is no precedent inside the company. You have your own intuitions but no map.
Prompt
I am building a multi-quarter plan from a single sentence: “we should be doing more with AI in our product.” I have no map yet and I do not want to commit to a direction prematurely. Walk this with me in three passes. Pass one (matrix): Given what you know about [our product, our users, our team size, our constraints], lay out the dimensions of the choice space. What are the axes I should be deciding along — not the answers, the axes. Be exhaustive even if some axes seem obvious. Pass two (structure): For each axis, what are the realistic positions we could take, and what does taking each position commit us to elsewhere? Where are the hard trade-offs and where are the false ones? Pass three (sequence): Given the axes and positions, what are the two or three coherent strategies — meaning a position on every axis that hangs together — that I could actually take to leadership? For each, what would the first quarter look like, and what would have to be true at the end of it for us to keep going? Throughout, push back if I have over-constrained or skipped an axis. I would rather argue with you now than ship the wrong direction in two months.
This is the explicit deep-blue-to-purple cascade run as a structured prompt sequence. The three passes map to matrix, light blue, and purple. The instruction to push back is critical: at this scale, the failure mode is a model that helpfully completes a poorly-framed brief. The PM needs the model to refuse to do the structuring middle without first doing the matrix mapping. Worth saying out loud: this prompt is at the edge of what a single chat can do well. For a two-week strategy piece, you will probably want to run this across multiple sessions, save the matrix as an artefact, and come back to it. The framework helps you notice when you are asking too much of one prompt.
Persona 3: the marketing or sales person bridging to engineering
Modes in play: the marketing or sales person is most often operating in deep green (relationships, accounts, narratives) or yellow (campaign cycles, market rhythm). The engineering team they need to talk to is operating in red and deep blue. The intimidation is real but it is usually not a competence gap — it is a mode gap, read by both sides as a competence gap, which makes it worse.
Why the intimidation reads as competence: engineering culture often rewards red-and-deep-blue presentation — confident, sequenced, technically grounded. A node-thinker walking into that room with a relational, narrative, what-the-customer-said-yesterday update is presenting in their home mode and getting read as fuzzy. They start adjusting their delivery to sound more linear, lose the actual signal they were carrying, and the room confirms its prior that the marketing person did not know what they were talking about. The signal was real. The translation was missing.
What they need from AI: translation in both directions — incoming engineering material rendered in node or wave terms, outgoing customer signal rendered in matrix or linear terms — without flattening either.
Easy: understanding what the engineering team is actually saying
Setting: you have been forwarded a technical update on a feature you sold to a customer. You need to know whether you can keep the promise you made and what to say if not. You do not need to understand every word.
Prompt
Here is a technical update from our engineering team: [paste]. I sold a customer on [feature] with a delivery date of [date]. Translate this update for me without dumbing it down. Three things only: is the promise I made still good? If not, what is the actual situation in plain language? And what is the question I should be asking the engineering team next, in their language, to get the answer I actually need? Do not give me a glossary. Do not summarise the whole update. Just answer those three questions.
The “without dumbing it down” instruction matters. The standard AI failure mode for this prompt is a watered-down summary that loses the technical signal. The instruction “in their language” for the follow-up question is the bridge — it gives the marketer a way to walk into the next conversation in a register the engineers will recognise without having to fake fluency.
Medium: bringing customer signal into a roadmap conversation
Setting: you are sitting in on a roadmap meeting for the first time. You have heard the same complaint from four different customers in the last fortnight. You want to flag it without being the marketing person who derails the technical conversation.
Prompt
Four customers said variants of [the complaint] in the last two weeks. Notes on each conversation: [paste]. I want to bring this into a roadmap meeting in a way an engineering audience will engage with rather than tune out. Help me write three things. First, the pattern in one sentence — the actual underlying signal, not the surface complaint. Second, the smallest specific question the engineering team can answer about it (not “what should we do,” that is too big). Third, what I am not claiming — to head off the assumption that I am asking for a roadmap change. Tone: short, specific, more like a bug report than a customer story. If the underlying signal is unclear from the notes, say so rather than reaching.
This is a deep-green-to-light-blue translation — taking a node-shaped artefact (four conversations, related but not identical) and projecting it onto a frame the engineering team can engage with (a specific question, a bounded claim). The “more like a bug report than a customer story” is the register shift. The “not claiming” line is what protects the marketer from being read as territorial.
Hard: making the case for a strategic shift to a sceptical engineering leadership
Setting: you have built up a clear picture across many customer conversations that the company’s positioning is wrong. You need to take this to the CTO and the head of engineering, both of whom are deep blue thinkers who are sceptical of marketing. You have one shot, and the standard playbook (a deck, a customer-quote montage, a recommendation) will land badly.
Prompt
I have a strategic case to make based on a pattern across roughly thirty customer conversations and twelve sales calls in the last quarter. The pattern, in my words: [paste]. Supporting notes: [paste]. The audience is a CTO and head of engineering who are sceptical of marketing-led strategy and respond to rigorous, falsifiable arguments. A customer-quote montage will fail. I need to present this as if I were presenting to a research panel, not a marketing review. Help me build the argument in this shape: The claim, in one sentence, falsifiable. The evidence, organised by what kind of evidence it is (frequency, severity, specificity, source quality). Be honest about the weaknesses of the evidence — they will find them anyway. The two strongest counter-explanations for the pattern, and what evidence would distinguish between them. What I am asking for at the end of the meeting, which is not a strategy change but a specific next investigation. Throughout, write as if I were a senior peer making a technical argument, not a marketing person making a case. If my evidence is too thin to support the claim, say so — I would rather know now than in the meeting.
This is the deep-green-to-deep-blue translation done explicitly. The marketer is not abandoning their home mode — the underlying knowledge is still relational, accumulated across conversations. They are asking the AI to project it into a deep blue register so the audience can engage with the signal rather than the form. The instruction to push back on thin evidence is what stops the prompt becoming a confidence-booster; at this stakes-level, the marketer needs an honest mirror, not a hype man.
Artefacts
