Discover Your Operating System

Most companies have what we call an “Intent Graph.” This is usually presented as a tidy hierarchy, but in reality it is closer to a living network. It includes many layers of intention. A ten year mission conveys intent. A quarterly objective conveys intent. A task conveys intent. Strategy and work sit on a continuum rather than in separate buckets.

In slides, the intent graph is often shown as a simple pyramid. In practice, it is much more fractal. The company has a strategy. Teams have a strategy. The company has goals. Teams have goals. Leaders have intents. Individuals have intents. It is a mistake to assume that strategy only exists at the top and work only exists at the bottom. Every level of the organization expresses some form of intention.

When you ask a company how they work, they will often point to this intent graph. They will show you their OKRs, strategic priorities, themes, pillars, bets, initiatives, or workstreams. This is natural. The intent tree is visible and familiar. It is also the place where most companies try to impose structure.

But it only tells part of the story. It tells you what people intend to do. It does not tell you how those intentions are coordinated, communicated, or translated into action.

This part of discovery is about clarifying the real intent hierarchy or network, so we can make it legible in Dotwork. Do not expect it to match the neat pyramid you see in planning decks. Most intent graphs are inconsistent, overlapping, duplicated, and occasionally contradictory. That is exactly why we surface them. The goal is not to judge the structure. The goal is to understand how intent is expressed today so the rest of the operating system can be instrumented around it.

Examples

Every company already has an intent graph, whether it's written down or not. It spans multiple horizons, uses different naming conventions, and connects strategy to day-to-day work in ways that are rarely as tidy as the slideware suggests.

The diagram below is simply one illustration of how those layers often coexist in practice. It's not a prescription or a template. It's a way to make the intent that's already in the system more visible so we can model it clearly in Dotwork.

The next diagram shows what an intent structure actually looks like inside most companies.

Instead of a clean pyramid, intent lives across spreadsheets, decks, recurring reviews, custom fields, and meetings. Things loop, duplicate, drift, and get manually combined. Some artifacts are active, some abandoned, and some exist only because a meeting needs them. The purpose of the diagram is simply to show the reality: intent flows are rarely linear, tidy, or centralized—they're messy, multi-directional, and shaped by habits, tools, and history.

Exercise 1 — Walk Up the Intent Graph

Even though intent is often displayed as a pyramid, the real structure is a chain of nested “why” layers. One of the simplest ways to understand your company's intent graph is to start at a concrete piece of work—something someone is doing this week—and walk upward.

Pick a real task that takes a couple of days. Then, for each hop upward, identify:

1. Name — What is this layer called in your company's language?
2. Typical timeframe — How long this level tends to represent.
3. What it describes — The intent or purpose at this level.

Keep going until you can't go any higher—or until the language becomes abstract enough that it stops being meaningful.

Note: For this exercise it is perfectly fine if the structure feels oversimplified. The goal is not to capture every nuance, but to strengthen the muscle of “walking up” the intent chain from concrete work to higher-level intention.

Exercise 2 — Trace the Flow (Even If You Didn't Start It)

The “Insight → Outcomes” flow rarely unfolds cleanly. Teams often inherit intent that was shaped elsewhere—sometimes far upstream, sometimes long ago, sometimes by people who have moved on.

This exercise helps you trace how something you're working on right now fits into the broader flow from insights to lagging outcomes.

Step 1 — Pick a Real Piece of Work

Choose something currently in flight: a feature, improvement, experiment, fix, or workstream. Write it in the middle of the page.

Step 2 — Walk Backward (Where Did It Come From?)

For each hop upstream, identify the “source”:

• What insight triggered this?
• What opportunity was defined?
• What options were considered?
• Who shaped it into a bet?
• What earlier decisions or discussions set this in motion?

Keep going until you can't find anything earlier—or until you hit the point where it “just appeared.”

Tip: It often goes like this: Slack thread → Rough idea → Prior research → Exec comment → Customer complaint → Metric dip → Market change

Step 3 — Walk Forward (Where Is It Supposed to Lead?)

From that same piece of work, trace downstream:

• What release does this contribute to?
• What impact is expected?
• What lever is this supposed to influence?
• Which driver or North Star does this support?
• What business outcome is it trying to move?

Keep going until you reach the highest-level intent anyone can reasonably articulate.

Step 4 — Sketch the Flow

Use this structure (or draw it visually):

Example

Starting from the work being done today

Current Work: “Improve search relevance for logged-in users.”

What it is: A concrete project the team is actively shaping and delivering.

Trace backward to where this came from

Initial Trigger: A senior support agent repeatedly escalated customer complaints about “not finding saved items.”

Early Signal: A UX researcher reviewed heatmaps and session replays and noticed clusters of failed searches and repeated queries.

Emergent Insight: Researcher drafts an informal note: “Returning users struggle to re-find items. High friction in rediscovery.”

Opportunity Framing: PM turns that note into a loose opportunity statement during planning prep: “Reduce friction in rediscovery for logged-in users.”

Shaping Moment: During quarterly planning, this becomes one of several candidate options on a slide.

Selection: Leadership chooses it because it aligns with a broader push toward increasing weekly active usage.

Move forward from that decision

Initiative Shaping: Product and engineering group the underlying work into a shaped bet with clear boundaries.

Project Definition: Team scopes concrete steps: ranking tweaks, index enrichment, better fallback matching.

Expected Release Pattern: Several iteration cycles producing small, targeted improvements.

Trace forward to intended impacts

Direct Impacts:

• Fewer zero-result searches
• Higher success rates for repeated searches
• Higher re-find completion rates

Outcome Driver: “Increase daily/weekly habit strength by making rediscovery easier.”

Product North Star Connection: Supports the broader aim of “efficient rediscovery” as part of the logged-in experience.

Business Outcome: Improved retention for logged-in users, especially those engaging with saved or historical content.

Note #1: In the Four Graphs model, not every step in this backward–forward trace counts as intent. Some steps are context: signals, observations, constraints, market forces, operational realities, or enabling conditions. Only some of the hops represent deliberate intent (bets, objectives, strategy). When you run this exercise, don't worry about perfectly separating intent from context. The goal is simply to map the flow: what shaped the work, what it is meant to achieve, and how it connects to the broader system. Over time, Dotwork helps make the distinction between intent and context more visible and easier to reason about.

Note #2: When you map flows like this across 1 to 3 months, 1 to 3 quarters, and 1 to 3 years, you often discover that the organization does not operate as a single, top-down chain. Instead, the same patterns repeat at multiple resolutions. You will see:

1. Opportunities at different scales feeding into similar shapes of Options, Bets, and Impacts
2. Drivers that exist at the team level, the org level, and the company level
3. Outcomes that move in both directions, informing long-term strategy while being shaped by short-term learning

The result is a fractal operating pattern, where the same logic of insight to option to bet to impact to outcome appears across many timescales and team scopes. This is not a problem. It is usually how healthy organizations actually function. The diagram simply makes that fractal structure visible so you can reason about it more clearly.

Exercise 3 — Understanding How Your Organization Categorizes Work

Every company has multiple, overlapping ways of categorizing work. These schemes show up in planning decks, hallway conversations, dashboards, budgeting discussions, and prioritization debates. They reveal how leaders think about investment, how teams explain their bets, and how the organization makes sense of where time and energy is going.

The challenge is that most companies do not use just one model. They use several at the same time. A team might talk about “strategic bets” in one meeting, “risk profile” in another, “number of teams involved” in a dependency review, and “near-term vs. mid-term outcomes” when shaping a roadmap. None of these are wrong. They simply reflect different mental models for understanding the work.

This exercise helps you surface the actual categorization schemes your organization uses today. The goal is not to standardize them. The goal is to make them visible so Dotwork can support how you already think, talk, and decide.

Below is a list of common categorization models. Use it as inspiration to map which ones appear in your company's language, debates, cycles, and artifacts.

You're Done When

• You've walked a real task upward through layers of intent.
• You've traced a real piece of work backward to its source insights.
• You've traced that same work forward to impacts and outcomes.
• You've captured the categorization schemes your org uses.
• You've surfaced inconsistencies or patterns in how intent flows.