A logic model should do more than make your program look organized.
It should make the reasoning behind your program easy to follow, easy to measure, and difficult to challenge.
When a funder reviews your logic model, they should be able to see how your resources lead to activities, how those activities produce outputs, and how those outputs contribute to measurable outcomes.
That connection is the point.
A logic model is commonly structured around inputs, activities, outputs, and outcomes, with some frameworks also including long-term impact, assumptions, or external factors.
The problem is that many organizations build logic models as a list of everything they do.
That creates a document.
It does not necessarily create a defensible program logic.
Start With the Change You Are Trying to Create
Before adding another activity to your logic model, ask:
What should be different because this program exists?
That question forces the model to begin with the intended change rather than the organization’s current workload.
For example, “provide 12 training sessions” describes an activity.
“Participants demonstrate increased knowledge of financial management” describes an intended outcome.
The difference matters because outputs tell you what the program delivered, while outcomes describe the change resulting from that work.
If your logic model contains dozens of activities but very few clearly defined changes, you may have built an operational plan instead of a logic model.
The Four Questions Every Logic Model Should Answer
A funder should be able to move through your model and understand four things:
1. What are you investing?
2. What are you doing with those resources?
3. What are you producing?
4. What changes because of that work?
Those questions correspond to the core logic model structure:
Inputs → Activities → Outputs → Outcomes
Some models extend the chain to long-term impact.
The exact format can vary, but the underlying logic should remain clear.
1. Inputs: What Are You Putting Into the Program?
Inputs are the resources required to operate the program.
They can include:
- Funding
- Staff
- Volunteers
- Equipment
- Facilities
- Technology
- Partnerships
- Curriculum or other materials
The important question is whether the inputs are realistic for the activities you have promised to deliver.
If your program plans to serve 500 participants but your model only accounts for one part-time staff member, the problem isn’t formatting.
There is a logic gap.
Your inputs should make the activities possible.
2. Activities: What Does the Program Actually Do?
Activities describe the work your organization performs using its available resources.
Examples include:
- Delivering training
- Conducting outreach
- Providing coaching
- Running workshops
- Conducting assessments
- Making referrals
- Providing technical assistance
Activities should be specific enough that someone outside your organization can understand what actually happens.
“Community engagement” is vague.
“Conduct six community outreach sessions with partner organizations each quarter” gives the reviewer something concrete to evaluate.
3. Outputs: What Did the Activities Produce?
Outputs are the direct, countable products of your activities.
Examples include:
- Number of participants trained
- Number of workshops delivered
- Number of referrals completed
- Number of organizations engaged
- Number of assessments conducted
Outputs are important because they demonstrate delivery.
But they are not automatically evidence of impact.
A program can deliver 100 training sessions without demonstrating that participants changed as a result.
That is why the next column matters.
4. Outcomes: What Changed?
Outcomes describe the change experienced by participants, organizations, communities, or systems.
This can involve:
- Knowledge
- Skills
- Behavior
- Conditions
- Access
- Capacity
For example:
Output:
200 participants completed financial literacy training.
Outcome:
Participants demonstrate improved ability to create and manage a personal budget.
The first statement tells you what the program delivered.
The second tells you what changed.
That distinction is fundamental to evaluation and grant reporting.
The Most Common Logic Model Mistake
One of the easiest ways to weaken a logic model is to label an activity or output as an outcome.
Consider this statement:
“Hire and deploy two full-time bilingual case managers.”
That is an organizational action.
It tells us what the program is putting into operation.
It does not tell us what changed for the people the program serves.
A stronger logic model would connect the staffing decision to the service delivered, the resulting output, and ultimately the intended participant-level change.
That is the chain a funder needs to see.
Build the Connections, Not Just the Boxes
A logic model becomes useful when the relationships between the boxes make sense.
Ask:
If we have these inputs, can we realistically deliver these activities?
If we deliver these activities, will they produce these outputs?
If we achieve these outputs, is there a credible pathway to the stated outcomes?
If the answer is unclear at any point, stop there.
That is where the model needs work.
The U.S. CDC describes logic models as a series of “if…then” relationships: if the necessary resources are available, then activities can occur; if those activities are delivered, then the intended outputs and outcomes can follow.
That is a useful test for any program logic.
Make Your Outcomes Measurable
A funder should not have to guess how you will know whether an outcome occurred.
Take:
“Participants will become more confident.”
What does “more confident” mean?
How will you measure it?
When will you measure it?
Compared with what?
A stronger outcome might specify the population, the change, the measurement approach, and the timeframe.
The more clearly the intended change is defined, the easier it becomes to connect the logic model to your indicator framework and evaluation plan.
Work Backward From the Outcome
One practical way to strengthen a weak logic model is to work backward.
Start with the outcome.
Then ask:
What output needs to happen for this outcome to become plausible?
Then:
What activity produces that output?
Then:
What resources make that activity possible?
For example:
Outcome: Participants demonstrate improved job-readiness skills.
↓
Output: 150 participants complete the job-readiness curriculum.
↓
Activity: Deliver weekly job-readiness workshops and practical assessments.
↓
Inputs: Trained facilitators, curriculum, assessment tools, funding, and training space.
This backward approach helps expose missing links before a funder does.
Don’t Confuse a Complete Logic Model With a Defensible One
A logic model can contain every required section and still have weak logic.
You can have:
- Inputs
- Activities
- Outputs
- Outcomes
- Indicators
And still leave the most important question unanswered:
Why should we believe one leads to the other?
That is where assumptions matter.
Some logic model frameworks explicitly document assumptions and external factors because the pathway from activities to outcomes is rarely controlled entirely by the program.
If an external factor could significantly influence your outcome, acknowledge it.
That is stronger than pretending the program controls everything.
The Funder Stress Test
Before submitting your next proposal, pick one outcome from your logic model.
Now ask:
What activity feeds this outcome?
What output demonstrates that the activity occurred?
What indicator measures the outcome?
What data source will support that indicator?
What could prevent the outcome from occurring even if the activity is delivered?
If your team cannot answer those questions without improvising, the logic model is not finished.
It needs another audit.
A Funder-Ready Logic Model Does Not Promise Perfection
A strong logic model does not guarantee that every outcome will be achieved.
It does something more useful.
It makes your assumptions visible.
It defines what you intend to do.
It clarifies what you expect to change.
And it creates a structure for testing whether that change actually occurred.
That gives funders something they can evaluate.
More importantly, it gives your own team something it can manage.
The Final Test
Before you submit your next logic model, ask:
Can someone who knows nothing about our program follow the chain from resources to activities to outputs to outcomes?
If yes, your logic is doing its job.
If they have to ask what connects the boxes, keep working.
Because a funder-ready logic model isn’t the one with the most boxes.
It’s the one where every important box has a defensible reason for being there.
Download the Logic Model Template Library: https://olpadrlogicmodeltemplate.claritytoimpact.com/?utm_source=linkedin&utm_medium=social&utm_campaign=logic_model_template
Building or rebuilding your program logic?
Use the Logic Model Template Library to structure your inputs, activities, outputs, and outcomes before your next funding conversation.
Evidence-led. Impact-driven. The OLPADR way.