Building Your Theory of Change: A Step-by-Step Framework for Program Managers
- Yaniv Corem
- 1 day ago
- 8 min read
I was on a call last week with a program manager who'd just finished a brutal stakeholder meeting.
Her funders wanted to know: "What's our program actually doing? How do we know it's working?"
She had metrics—application numbers, cohort sizes, demo day attendance. But when they pushed for the deeper story—how does your program create impact, and why should we believe it works—she realized she didn't have a clear answer.
That's when she asked me: "Do I need a Theory of Change?"
Short answer: Yes.
Longer answer: You need one that's actually useful, not just a document you create once and never look at again.
What is a Theory of Change?
Here's the thing—most people hear "Theory of Change" and immediately think it's some academic exercise that consultants love and operators ignore.
And honestly? A lot of Theory of Change documents are useless.
They're 40-page PDFs filled with logic models, jargon, and assumptions that nobody ever tests. They get filed away after the grant application and never see the light of day again.
But a good Theory of Change is different.
It's a living document that answers three critical questions:
What are we trying to achieve? (The outcomes that actually matter)
How do we believe we'll get there? (The mechanisms that drive those outcomes)
What assumptions are we making? (The things that have to be true for this to work)
If you can't answer those three questions clearly, you're running a program on vibes and hope. That might work for a cohort or two, but it won't scale, and it definitely won't survive skeptical funders or a bad quarter.
See, a Theory of Change isn't about making your program look strategic. It's about making your program actually strategic.
Why Most Theories of Change Fail
I've reviewed a lot of Theory of Change documents over the years. Most of them fail for the same reasons:
They're too abstract. "We will foster entrepreneurial ecosystems to drive innovation and economic growth."
Cool. But how? What specific activities lead to "fostering ecosystems"? What does "innovation" even mean in this context? These statements sound impressive but don't actually guide decisions.
They skip the hard questions. A real Theory of Change names the tension between what your funders want (investor pipeline, media buzz, innovation theater) and what founders need (business model validation, sustainable growth, real skill development).
Most programs pretend that tension doesn't exist. Then they wonder why their metrics don't align with founder outcomes.
They don't test assumptions. Every Theory of Change is built on assumptions. "If we provide mentorship, founders will learn faster." "If we connect founders to investors, they'll raise capital."
But what if those assumptions are wrong? What if your mentorship matching process is broken, or your investor intros are low-quality?
Most programs never test this stuff. They just assume it works and move on.
They're static, not iterative. Your Theory of Change should evolve as you learn what actually works. If you wrote yours two years ago and haven't touched it since, it's probably outdated.
Markets change. Founder needs shift. Your program should adapt. So should your Theory of Change.
The Framework
Alright, let's build one.
I'm going to walk you through a framework I use with programs that want a Theory of Change they'll actually use, not just file away.
Step 1: Define Your Ultimate Outcome
Start with the end in mind. What does success really look like?
Not "founders raised funding" or "we ran three cohorts." Those are outputs.
I'm talking about the outcome you're trying to create in the world.
Examples:
"Founders build sustainable, high-growth businesses that create jobs and drive economic impact in [region/sector]."
"Underrepresented founders overcome systemic barriers and achieve business success at the same rate as their peers."
"Corporate partners successfully validate and scale internal innovations through startup collaboration."
Your ultimate outcome should be specific, measurable, and ambitious. If it's easy to achieve, it's not a north star—it's just a milestone.
Pro tip: Get your team and stakeholders aligned on this before you go further. If your funder thinks the goal is "generate deal flow for investors" and your team thinks it's "help founders build sustainable businesses," you've got a problem that no amount of curriculum design will fix.
Step 2: Map Backward from Outcome to Activities
This is where most Theories of Change get messy, so stay with me.
You've got your ultimate outcome. Now ask: "What has to happen right before that outcome for it to be achieved?"
Let's say your outcome is: "Founders build sustainable, high-growth businesses."
What has to happen right before that?
Founders validate product-market fit
Founders build scalable acquisition channels
Founders secure the capital they need to grow
Okay, so those are your intermediate outcomes. Now go one level deeper.
What has to happen for founders to validate product-market fit?
They run structured customer discovery
They iterate on product based on real feedback
They define clear success metrics and track them
Keep going backward until you hit the activities your program actually controls—workshops, mentorship, office hours, founder check-ins, etc.
You're building a chain of logic:
Activities → Outputs → Intermediate Outcomes → Ultimate Outcome
Example:
Activity: Weekly office hours with mentors
Output: Founders receive feedback on customer discovery
Intermediate Outcome: Founders validate product-market fit
Ultimate Outcome: Founders build sustainable businesses
Make sense?
Step 3: Name Your Assumptions
Here's where it gets real.
Every link in your Theory of Change chain is built on assumptions. And if those assumptions are wrong, your whole model breaks down.
Let's use the example above:
Assumption 1: Mentors have the expertise to guide customer discovery. (What if they don't? What if they're great operators but terrible teachers?)
Assumption 2: Founders will actually implement mentor feedback. (What if they nod along in office hours but never act on it?)
Assumption 3: Customer discovery leads to product-market fit. (What if founders run bad discovery interviews? What if they ignore signals that don't fit their vision?)
Most programs never write these assumptions down. That's a huge mistake.
Because once you name your assumptions, you can test them.
You can ask: Are our mentors actually equipped for this? Are founders implementing feedback? Is our customer discovery process working?
If the answer is no, you know exactly where to intervene.
Step 4: Identify Risks and Barriers
What could go wrong?
What external factors might derail your Theory of Change, no matter how well you execute?
Examples:
Market crash reduces investor appetite (founders can't raise follow-on funding)
Industry-specific regulatory change (your ConTech or HealthTech founders face new barriers)
Mentor burnout (your engagement model isn't sustainable)
Founder dropout (they get jobs, pivot out of startups, or can't commit the time)
Write these down.
Not because you can control them all, but because you need to plan for them. If your entire Theory of Change depends on "founders will raise funding from investors," and then the market crashes, you're toast.
Better to name that risk upfront and build contingency plans.
Step 5: Define Your Metrics
Now that you've mapped out your chain of logic, you need to measure whether it's actually working.
This is where you define:
Leading indicators (things you can measure during the program that predict long-term success)
Founder engagement in office hours
Quality of customer discovery feedback
Evidence of product iteration
Mentor relationship satisfaction
Lagging indicators (things you measure after the program to assess ultimate outcomes)
Funding raised (with context: amount, stage, investor quality)
Revenue traction and path to profitability
12-month and 24-month survival rates
Founder capability retention
Most programs only measure lagging indicators. That's like driving a car by looking in the rearview mirror. You need both.
Step 6: Build Review Cycles
Your Theory of Change isn't a static document. It's a hypothesis that you test, refine, and improve over time.
Build review cycles into your program:
After every cohort: What worked? What didn't? Which assumptions held up? Which ones broke?
Quarterly: Are our leading indicators moving in the right direction? If not, what needs to change?
Annually: Has our context shifted? Do we need to update our ultimate outcome, our activities, or our assumptions?
Programs that treat their Theory of Change as a living document outperform programs that treat it as a grant requirement.
Putting It All Together
Let me show you what this looks like in practice.
Program: Early-stage accelerator focused on underrepresented founders
Ultimate Outcome: Underrepresented founders achieve business success at the same rate as their peers.
Intermediate Outcomes:
Founders validate product-market fit
Founders build financial sustainability (revenue or clear path to funding)
Founders access high-quality networks (mentors, investors, customers)
Activities:
Structured customer discovery workshops
1:1 founder coaching with experienced operators
Mentor matching focused on lived experience alignment
Investor intro program with bias training
Peer learning cohorts
Assumptions:
Quality mentorship reduces the "network gap" for underrepresented founders
Founders will engage deeply if they see relevance to their business
Investors will take meetings if founders are well-prepared and warm intros are strong
Risks:
Investor bias persists despite warm intros
Mentor network lacks diversity, creating misalignment with founder needs
Founders face external barriers (childcare, visa issues) that program can't solve
Metrics:
Leading: Mentor-founder relationship quality, founder engagement, evidence of customer discovery execution
Lagging: Funding raised (disaggregated by founder demographic), 12-month survival, revenue traction
See how specific that is? You could hand this to someone unfamiliar with the program, and they'd understand exactly what you're trying to do and how you're planning to get there.
Common Mistakes to Avoid
Before you go build your own, here are the traps I see programs fall into:
Mistake 1: Skipping stakeholder alignment If your funders think the goal is deal flow and your team thinks it's founder capability development, your Theory of Change won't save you. Align first, document second.
Mistake 2: Making it too complicated Your Theory of Change should fit on 2-3 pages. If it's longer, you're overthinking it.
Mistake 3: Ignoring founder voice Ask your founders: What actually helped? What didn't? Their answers should inform your Theory of Change, not your assumptions about what "should" work.
Mistake 4: Treating it as a grant requirement If you only pull out your Theory of Change when a funder asks for it, you're missing the point. Use it to guide program decisions, prioritize activities, and diagnose problems.
The Bottom Line
If you don't have a clear Theory of Change, you're running your program on intuition and borrowed best practices.
That might work for a while. But when stakeholders ask tough questions, when something breaks, or when you need to scale, you'll wish you'd done this work upfront.
A good Theory of Change doesn't make your program more bureaucratic. It makes it more intentional.
It forces you to answer: What are we actually trying to do? How do we believe we'll get there? And what evidence would prove we're wrong?
Those are the questions that separate programs that look busy from programs that actually create impact.
.
.
.
Ready to build your own Theory of Change? I've created a Theory of Change Builder Template that walks you through every step of this process with prompts, examples, and space to map your own logic model.
You might also find the Assumption Testing Worksheet helpful—it's a simple tool for identifying and testing the key assumptions your program depends on. Grab it here.
This post is part of a series on program design and operations for accelerators, incubators, and startup studios. If you found this useful, you might also like: "The Program Goals Trap" and "Measuring What Matters: KPIs That Actually Predict Program Success."
Comments