I've often struggled with distinctions like "strategy vs. execution" and "problem vs. solution." Here's a basic framework I use with Dotwork customers to tease out the different entities and signifiers they use as part of their operating system. The basic distinction is: Context, Intent, Collaboration, and Investment. Here's how it works:
Context
Context describes perspectives on what is. Examples include jobs-to-be-done maps, customer insights, capability trees, KPI trees, service directories, and customers. Context can change rapidly, but it typically is not associated with a particular block of time (outside of, for example, forecasts for investors, time-related events like the timing of competitor launches, etc.).
Intent
Intent describes what our "intents" are for the future. Intent can be broad, visionary, subjective, directional, or highly specific and prescriptive. Those pillars on the "Parthenon slide" may not seem highly actionable but are a form of Intent. Goals describe a certain direction and our expectations about what could, might, or should change. Intent tends to have a time component, but that time component could be a decade. Realized Intent changes our context, but often in ways we can't predict or understand. "Intent" as a term may seem highly academic, but common distinctions like "strategy vs. planning" or "opportunities and solutions" often vastly oversimplify what we are doing. These ideas tend to blend and overlap.
Collaboration and Investment
The two other categories are more self-explanatory. Collaboration describes structures related to humans and how they interact. Investment covers the collection of models the company uses to think about how time, capital, capacity, and focus are "invested" to achieve the outcomes it cares about.
Quick Example
Context. The customer journey map shows that claims are one step in a long relationship. Some customers have held policies for 10+ years. The KPI tree highlights low mobile usage and long resolution times as key drivers of satisfaction and retention.
Intent. Goal: Improve satisfaction and retention for long-time policyholders. Specific Intent: reduce mobile claim resolution time by 30% within a year for policies >5 years old.
Collaboration. The existing claims team partners with mobile, data science (to flag long-tenure customers), contact center, and compliance—coordination across teams to improve flow and communication.
Investment. Backed by a financial model tied to the customer funnel—from purchase to renewal. Long-time customers = high lifetime value. The approved budget covers mobile workflow updates, triage improvements, and follow-up support.
Layering In Rate-of-Change
You can layer a time/rate-of-change component on these categories like this:
Why is this (potentially) helpful?
Your average organization spends an incredible amount of time worried about a narrow slice of Intent. What are this quarter's goals? What are we planning to build? When will we deliver it? They spend much less time sharing context and focusing on things that change less frequently, as well as core facets of the investment and collaboration approach. Teams feel like they are chasing their tails, working in a hamster wheel without the grounding of core models and frameworks.
When I was more active in doing North Star Framework workshops, I was always amazed by how long a good set of inputs and a North Star Metric could "stick" in a company. Quarterly and annual planning would come and go, but the NSF would remain. The same goes for models like capability trees, customer journeys, jobs-to-be-done, and mental models. Even at the scale of my current role at Dotwork, we've found that certain models can have great staying power despite a startup's rapid rate of change.
There are other lessons as well.
Take something like an "Epic." An epic is a form of Intent, ideally with some context mixed in. But companies operationalize epics as if they mean something—as if the delivery of an epic itself was somehow valuable. Most companies would be OK if they summarized recent releases and impacts as their own "object" and threw away the "to-do" artifact. What matters is what changed in production, the downstream impacts, and other contextual elements.
When companies fail at "connecting the dots," you get things like this:
I spoke with a company recently that discovered that 20 teams had built business cases around moving the same metric. If ALL of those teams realized their "case," the metric would have increased by 500% (which was impossible, governed by physics). This was a failure in context, capturing Intent, a theory around investment, and likely a mismatch between reality and how the company perceived collaboration.
Questions
Where might it be helpful to invest more time in establishing foundational models for your team and company?
Does your company have a common set of approaches to funding? Does it have a language around funding? What does that language focus on?
Does your team feel like it is chasing its tail each quarter? What remains the same? What are artifacts/ideas that you return to month after month, and quarter after quarter?
How is strategic intent communicated in your company? Does it “stick?” Is it too prescriptive or too open-ended?
Where does it make sense to be more stringent with how you invest money and time?
Which models do you find most “sticky” in your company—the ideas, constructs, mental models, etc., that you return to again and again?
When someone leaves your company, what context leaves with them?
How do you reinforce certain areas of context in your day-to-day rituals?
Do you have a helpful balance of near-term intent and longer-term intent?
I resonated with this, especially the distinction between context and intent — feels foundational but often overlooked. Teams do struggle to pause and align on context before diving into planning. Everyone’s focused on “what’s next” without realizing they’re drawing from a fragmented or stale map.
I also appreciated the bit on how certain models stick. I have noticed that once a shared language forms — even just a few strong anchors like capability trees or JTBD maps — it creates way more stability than constant re-planning.
That story about 20 teams chasing the same metric .. Painfully familiar. Really shows the cost of weak context sharing.