Theory of change model: the nonprofit framework your OKRs are missing

Ask a nonprofit programme officer to defend a funding application and within five minutes they'll pull up a diagram: inputs, activities, outputs, outcomes, impact, each box leading logically into the next. Ask a product manager to defend why a roadmap item is meant to move a revenue number, and you'll usually get a shrug, a slide with a hockey-stick chart on it, or 'because our competitor shipped something similar.'

That diagram the programme officer showed you has a name. It's a theory of change model, one of the most rigorous planning tools in existence, and almost no business team uses it. Not because it doesn't apply. Because almost nobody outside international development, public health and education funding has ever been introduced to it.

That's a shame. The logic underneath a theory of change model, an explicit if-then chain from what you do to what changes because of it, is exactly what's missing from most OKRs, roadmaps and strategic plans. Teams commit to initiatives all the time without ever writing down why they believe that initiative will move the metric they're chasing. A theory of change model forces that belief onto paper, in public, where someone can actually argue with it.

Here's what a theory of change model actually is, why the nonprofit version doesn't survive contact with a business, and how to run one without it turning into another slide nobody reopens.

What a theory of change model actually is

A theory of change model maps the causal chain between what an organisation does and the change it's trying to create, usually across five stages:

Inputs: the resources you put in (people, budget, time)
Activities: what you actually do with those resources
Outputs: the direct, countable result of the activity (a programme delivered, a feature shipped)
Outcomes: the behaviour or condition that changes because of the output
Impact: the longer-term goal all of this is meant to serve

The part that makes it different from a plain project plan is the arrows, not the boxes. Between each stage sits an assumption: if we run this activity, then this output will follow, because of this specific reason. A theory of change model asks you to name that reason out loud instead of assuming everyone already agrees on it.

This is also where people mix it up with a logic model. A logic model maps the same five boxes and mostly documents what's supposed to happen. A theory of change model goes a step further and documents why you believe it'll happen, including the assumptions and risks that could break the chain along the way. In practice most people use the two terms interchangeably, but if you're being precise: a logic model is the map, and a theory of change is the map plus the reasoning behind it.

Why the nonprofit version doesn't survive contact with a business

Nonprofits build theory of change models to satisfy funders, not to run the organisation week to week. It gets built once, ahead of a grant application, gets a nice diagram treatment from whoever's good with a whiteboard, and then goes into a folder until the next funding cycle forces someone to dust it off.

Business teams that borrow the framework tend to make the exact same mistake. It shows up as a slide in a strategy offsite, everyone nods along, and it's never referenced again until someone asks 'wait, why are we doing this project?' six months later and nobody quite remembers the original reasoning. The document was never wrong. It was just never built to be used more than once.

Dimension	One-off theory of change	Operating theory of change
Purpose	Justify a grant application or a pitch	Test whether an initiative is worth running
Who owns it	Whoever wrote the original document	Whoever owns the Key Result it supports
When it's revisited	Once a year, if at all	Every check-in cycle
What happens when an assumption breaks	Nothing, until the next funding round	The initiative gets revised or killed
Where it lives	A PDF in a shared drive	Attached to the OKR it supports

How this maps onto OKRs

If you already run OKRs, you've basically already got two-thirds of a theory of change model without the reasoning layer. The Objective is the impact. The Key Results are the outcomes. The initiatives underneath each Key Result are the activities and outputs.

(see also: Outputs vs outcomes)

The part almost everyone skips is the assumption connecting an initiative to a Key Result: the 'because' that explains why this specific piece of work should move that specific number. Skip it and OKRs turn into a to-do list with a scoreboard bolted on. Include it and OKRs become what they're supposed to be, a translation layer between strategy and execution, which is exactly the role we've written about in strategy execution. A theory of change model is just a more disciplined way to write that translation down before you commit real resources to it.

A four-step way to run one without it going stale

Write the chain for one initiative at a time, not the whole company. A company-wide theory of change model is too abstract for anyone to argue with. An initiative-level one, 'if we ship X, then Y, because Z', is concrete enough that someone can actually disagree with it.
Name the assumption at each arrow, not just the boxes. 'We'll build an onboarding checklist' is an activity. 'Because faster time-to-value causes lower churn, not just correlates with it' is the assumption doing all the real work.
Attach it to a cadence, not an annual planning doc. A theory of change model that only gets reopened once a year is a nonprofit grant document wearing a business suit. Pair it with the same check-ins you're already running for OKRs, so the assumption gets tested against real numbers instead of just being remembered fondly.
Revisit and prune broken links. When an outcome doesn't move the way the chain predicted, the fix usually isn't a new tactic bolted onto the same assumption. It's admitting the assumption was wrong and rewriting that link before the next quarter repeats the mistake.

A worked example

A 40-person B2B SaaS team believes their 90-day churn problem is really a time-to-value problem. Written out properly, their theory of change model looks like this:

Inputs: two engineers, one designer, three weeks
Activities: build an in-app onboarding checklist covering the five setup steps that correlate with retained accounts
Outputs: percentage of new accounts completing the checklist within week one
Outcomes: median time-to-first-value drops from 12 days to 4; 90-day churn among checklist-completers drops
Impact: net revenue retention improves for the cohort

The assumption sitting on the arrow between output and outcome is the one worth arguing about before anyone writes a line of code: does completing the checklist faster actually cause lower churn, or were the accounts most likely to finish it quickly already the most likely to stick around anyway? That's a testable question, not a rhetorical one. A weekly check-in on the leading indicator, checklist completion rate, tells the team within a month whether the theory holds, rather than finding out at the next QBR that a whole quarter of engineering time chased a correlation instead of a cause.

Common mistakes

Starting from the impact metric and working backwards into activities that sound plausible, rather than starting from what the team can actually control and working forwards.
Skipping the assumption and treating a plausible-sounding story as if it were the plan itself.
Treating it as a document instead of a hypothesis. Filed away instead of tested, revised, or occasionally killed.
Confusing it with a roadmap. A roadmap says what you're building and when. A theory of change model says why you believe it matters, which is the part a roadmap usually leaves out entirely.

Where Tability fits

None of this requires new software. It requires writing the assumption down somewhere everyone can see it, and checking it on a cadence instead of once a year. Tools like Tability are built for exactly that: a place to attach an initiative to the Key Result it's meant to move, with a running check-in history that shows whether the underlying assumption is holding up or quietly falling apart. It's the same operating layer we've described in StratOps and the OKR framework.

If you're trying to get your team arguing about assumptions before committing a quarter of engineering time to them, or you're building the StratOps function that makes that kind of thinking routine, sign up for Tability free or book 30 minutes with us and we'll help you figure out what it looks like for your team. Tability or not, writing the 'because' down is worth doing either way.