--- title: "Nonprofit program outcome planner" type: "skill" url: "https://useaiblocks.com/skills/nonprofit-program-outcome-planner" updated: "2026-10-28" first_published: "2026-10-25" job: "Plan your strategy" tested: true licence: "MIT" source: "https://github.com/sector-skills/nonprofit-skills/tree/7d8a2ca9d471fc975d0e9ccd02fcdd66520fd1c8/nonprofit-skills-library/skills/programs-impact/nonprofit-program-design" instructions: "https://useaiblocks.com/skills/nonprofit-program-outcome-planner/SKILL.md" --- # Nonprofit program outcome planner > Plan a nonprofit program logic model. Give it your activities and goal. You get a map from work to change, plus assumptions to check. Share your program, resources, community need, and intended change. It maps how each activity could lead to results and checks the links. You get a one-page program model, a plain explanation of the change, and assumptions or evidence gaps to review. Free skill for the job "Plan your strategy" · Level: intermediate · Thinking: high · Tested · Updated 2026-10-28 ## Links - Page: https://useaiblocks.com/skills/nonprofit-program-outcome-planner - Instructions (SKILL.md): https://useaiblocks.com/skills/nonprofit-program-outcome-planner/SKILL.md - All files (zip): https://useaiblocks.com/skills/nonprofit-program-outcome-planner.zip - JSON version: https://useaiblocks.com/skills/nonprofit-program-outcome-planner.json - In your AI: connect https://useaiblocks.com/mcp and ask "Use AI Blocks to get nonprofit-program-outcome-planner" ## What you give it - Your program activities and who they serve. - The community need you have confirmed. - Your resources: staff, funding, volunteers, partners. - The changes you want for participants. - Counts of work delivered so far (optional). - Past evaluation data or research that supports your approach (optional). ## What you get - A one-page logic model table. - A short explanation of how your work should lead to change. - A list of assumptions and outside factors to review. - Notes on evidence gaps, measures to set, and parts to use in a grant. ## Example: what goes in and what comes out ### What goes in - Your program name and what it does - The community need you have already confirmed - Your resources: staff, funds, volunteers, partners, space - The change you want for participants - Any past results or evaluation data (optional) ### Before you start - A chat AI. No code or file tools are needed if you paste your details in. - A confirmed community need. This skill does not prove the need. ### What comes out - **One-page logic model**: A table with inputs, activities, outputs, short-term, mid-term and long-term outcomes, with counts kept apart from changes. - **Theory of change narrative**: A one to two page if-then-because explanation of how the program leads to change, with the evidence behind each link. - **Assumptions and risk list**: Conditions that must hold for the model to work, plus outside factors that could help or hurt. - **Handoff notes**: Which outcomes need measures, and which parts a grant writer will need to turn into text. ## Use it when - You are designing a new program and need to show how it should work. - A funder or board asks how your activities lead to results. - A program has run for years and no one can say why it should work. - You are redesigning a program and want to check its hidden assumptions. ## Skip it when - You still need to show the need exists: do a needs assessment first, using community data or a local survey. - You want to write the model into a grant application: use a grant writing step or a grant writer after this. - You want to measure whether results happened: use an outcomes measurement plan or an evaluator instead. ## How to use it 1. Open Claude, ChatGPT or Gemini. Paste in this skill's instructions. No code or paid tool is needed. 2. Paste your program details: activities, resources, the need, and the change you want. 3. Add counts and evaluation data if you have them. Say so if you have none. 4. Read the table. Check that counts sit under outputs and changes in people sit under outcomes. 5. Ask your AI to explain any link that does not make sense. Fix or cut it. 6. Show the draft to the staff who run the program. Ask what assumptions are false. ## What to do next - [Product outcome roadmap planner](https://useaiblocks.com/skills/outcome-based-roadmap): Plan your strategy - [Program keep-or-cut reviewer](https://useaiblocks.com/skills/program-keep-or-cut-reviewer): Plan your strategy - [Nonprofit strategy planner](https://useaiblocks.com/skills/nonprofit-strategy-cycle-planner): Plan your strategy - [Nonprofit change rollout planner](https://useaiblocks.com/skills/nonprofit-change-rollout-planner): Lead the team - [Nonprofit executive board report writer](https://useaiblocks.com/skills/nonprofit-executive-board-report-writer): Lead the team ## Sources and credits - From Nonprofit Skills: https://github.com/sector-skills/nonprofit-skills/tree/7d8a2ca9d471fc975d0e9ccd02fcdd66520fd1c8/nonprofit-skills-library/skills/programs-impact/nonprofit-program-design, shared under the MIT licence (original name: nonprofit-program-design). - [nonprofit-program-design skill](https://github.com/sector-skills/nonprofit-skills/tree/7d8a2ca9d471fc975d0e9ccd02fcdd66520fd1c8/nonprofit-skills-library/skills/programs-impact/nonprofit-program-design), Nonprofit Skills: Copied under the MIT licence. We gave it a plain name. We added Before you start and After this sections that link to other AI Blocks steps. We refreshed those generated sections from the catalogue inputs and next-step links. - [Original author](https://brendonconnelly.com), Brendon Connelly: Wrote the skill; Nonprofit Skills shared it in their collection. ## Instructions (SKILL.md) ## Nonprofit Program Design ### Before you start Use the material below to do this job. If facts or tool access are missing, explain what you can finish and what must wait. **What you need** (use your own material or the linked skill): - **Your question** (yours): the decision or problem, and what a good outcome looks like. **Makes it better (optional):** - **A document** (yours): a finished document, such as a Word file, a PDF or a page of notes. How to start: 1. **Look first.** Use what they've already attached, pasted or put in their about-me note. In a coding assistant with file access, look in the project too for these by name. 2. **Check what's missing.** Look for your question, a document. They can attach files, paste the details, or share a file path your assistant can read. Ask only for missing facts that change the result. If they ask you to start with what they have, complete the parts you can and mark the gaps. 3. **Do the job.** Follow the skill below with the facts and tools you have. Mark each gap with `MISSING:` where it belongs and never invent a fact to fill it. **Tools that do this best:** - **A chat AI that can read your files:** The skill works from records and drafts you provide. Research tasks also need current, checked public sources. ### When to Use This Skill Use this skill when the task is to build, revise, or troubleshoot the causal design of a nonprofit program — the logic that connects what the program puts in and does to the change it claims to produce. Concrete triggers: - "Build a logic model for our [tutoring / food access / job training] program." - "We need a theory of change for the board retreat / strategic plan / new program pitch." - "Our funder wants to see how our activities lead to outcomes." - "We're redesigning an existing program — help us map inputs to outcomes." - "What assumptions are we making that could break this program's logic?" - A program has been running for years but nobody can articulate why it should work. **Boundary — read before starting:** - Turning a finished logic model into funder-facing prose (narrative, budget narrative) is `nonprofit-grant-writing`. This skill produces the model; that skill writes it up for a specific RFP. - Deciding what to measure, how to collect data, and how to report actual results against the model is `nonprofit-outcomes-measurement`. This skill defines *what should happen*; that skill defines *how you'll know if it did*. - Determining whether a new program is needed in the first place, based on community data, is `nonprofit-needs-assessment`. Program design assumes the need is already established (or hands off from it). - Adapting a working model to new sites/populations is `nonprofit-program-scaling`. ### Core Frameworks #### 1. Logic Model (linear, single-program) The standard five/six-column logic model, in the sequence funders (United Way, W.K. Kellogg Foundation, CDC) expect: | Inputs | Activities | Outputs | Short-Term Outcomes | Mid-Term Outcomes | Long-Term Outcomes / Impact | |---|---|---|---|---|---| | Resources invested: staff, funding, volunteers, curriculum, partners, facilities | What the program *does* with those resources | Direct, countable products of activities (units of service) | Change in knowledge, attitude, skill (0-1 yr) | Change in behavior or practice (1-3 yr) | Change in condition/status — the ultimate impact (3+ yr) | Rules of thumb that catch most first-draft errors: - **Outputs are not outcomes.** "50 workshops delivered" or "200 meals served" is an output — it counts activity, not change in a person or system. If a cell says "number of X provided/attended," it belongs in Outputs, not Outcomes. - **Outcomes must be verb-of-change statements about the participant/system**, not the program: "Participants demonstrate increased financial literacy" (outcome) vs. "We ran 6 financial literacy classes" (output). - **Every arrow needs a plausible mechanism.** If you can't say *why* an output would cause the next outcome, the model has a logic gap — flag it rather than paper over it. #### 2. Theory of Change (ToC) Broader and less linear than a logic model — a ToC states the program's change hypothesis, usually as an "If...then...because..." backwards-mapped chain starting from the long-term goal: > "If [population] receives [intervention], then [short-term change] will occur, which will lead to > [mid-term change], ultimately resulting in [long-term impact], because [the underlying assumption > or evidence base]." A full ToC additionally documents, beyond the logic model's columns: - **Assumptions**: conditions that must hold true for the chain to work (e.g., "participants have reliable transportation to attend sessions"). - **Preconditions/pathways**: intermediate changes required before the outcome, often shown as a "pathway of change" map with multiple parallel tracks (individual, organizational, systemic). - **Rationale/evidence base**: the research or prior experience justifying each link — cite it. A ToC with no evidence base is an opinion, not a theory. - **External/contextual factors**: forces outside the program's control that could help or hinder (policy shifts, funding cycles, seasonality, community trust). Use a **logic model** when a funder or board wants a compact, boxed one-pager tied to a specific program. Use a **theory of change** when the organization needs to articulate or defend the underlying causal hypothesis — new program design, strategic planning, or when a funder explicitly asks "what is your theory of change." #### 3. Common Program Design Frameworks to Recognize - **Results-Based Accountability (RBA) / Mark Friedman's "Turn the Curve"** — distinguishes population-level results (community-wide conditions) from performance measures (how well a program did its job); useful when a program is one contributor among many to a community outcome. - **Collective Impact backbone logic** — when the program sits inside a multi-org initiative, the logic model should show the program's contribution to a shared community-level outcome, not claim sole attribution. - **Kellogg Foundation Logic Model Development Guide** — the most widely cited public template; default to its 5-column structure unless the funder specifies its own. ### Instructions 1. **Confirm the unit of design.** Is this a single program, a department, or the whole organization's ToC? Logic models work best scoped to one program; a full-org ToC sits one level above and can spawn multiple program-level logic models. 2. **Start from the long-term outcome/impact and work backward** (backward mapping). Ask: "What condition are we ultimately trying to change?" Then: "What would have to be true right before that for it to happen?" Repeat until you reach activities the program actually controls. 3. **Draft outputs and activities forward** from current/planned resources, then check they actually connect to the backward-mapped outcome chain. Where they don't connect, either the activity is unnecessary or an outcome step is missing. 4. **Stress-test every arrow** with "so that..." — "We deliver job-readiness workshops, SO THAT participants gain interview skills, SO THAT participants secure interviews, SO THAT participants are hired." If a "so that" doesn't hold logically, revise. 5. **Name the assumptions and external factors explicitly** in a dedicated section/row — don't leave them implicit. This is the single most commonly skipped step and the first thing a sophisticated funder or evaluator will probe. 6. **Distinguish outputs from short-term outcomes** with a gut-check: "Is this a count of activity, or a change in a person/system?" Move miscategorized items. 7. **Right-size the time horizons** to the program's actual cycle — short-term (0–1 yr), mid-term (1–3 yr), long-term (3+ yr) is a default, not a rule; a 6-week intervention may compress these. 8. **Validate with the people closest to delivery** (program staff, participants/beneficiaries if possible) before finalizing — designs built only by leadership frequently encode assumptions frontline staff know to be false. 9. **Produce the standard deliverable**: a one-page logic model table (for board/funder use) plus, for new or contested programs, a 1–2 page theory-of-change narrative with assumptions and evidence base called out separately. 10. **Hand off cleanly**: flag which outcomes need indicators and measurement plans (→ `nonprofit-outcomes-measurement`) and which sections a grant writer will need lifted into narrative form (→ `nonprofit-grant-writing`). ### Common Failure Modes - **Output/outcome conflation** — the most frequent error; "number served" dominates the outcomes column. Fix by applying the change-verb test in Step 6. - **Missing assumptions** — a model that looks airtight on paper but silently depends on unstated conditions (transportation, digital access, family support) that later explain "unexpected" underperformance. - **Outcome overreach / attribution creep** — claiming long-term, systemic impact (e.g., "reduces community poverty") that a single modest program cannot plausibly claim alone; use RBA's population-vs-performance distinction to right-size the claim, or explicitly frame it as contribution within a collective-impact effort. - **Designing in isolation from delivery staff** — leads to a model nobody on the ground recognizes or can execute against. - **No evidence base** — a theory of change asserted without citing prior research, pilot data, or comparable-program evidence reads as aspirational rather than credible to funders and boards. - **One-size logic model reused for structurally different programs** — copy-pasting a model across dissimilar programs instead of re-deriving it; surface-level edits leave stale, mismatched logic. ### For Advisors/Consultants When facilitating this for a client: - Run the backward-mapping (Step 2) as a live facilitated exercise with program staff and at least one board or leadership representative in the room — the disagreements that surface are the design work, not a distraction from it. - Bring an external framework name (logic model vs. ToC vs. RBA) into the room explicitly; clients often conflate "outcomes" and "outputs" and having a named framework to point to depersonalizes the correction. - Deliverable for a client engagement: a facilitated logic model workshop output (draft table), a revised final one-pager, and a short memo listing assumptions/risks the client should monitor — separate from the model itself so it survives as a standing risk register. - Flag scope explicitly to the client: this engagement builds the model; recommend `nonprofit-outcomes-measurement` as a distinct follow-on engagement (often a different SOW) rather than assuming measurement design is included. ### Standard Deliverables - One-page logic model (table format, Kellogg-style 5-column) - Theory-of-change narrative (1–2 pages) with assumptions, pathways, and evidence base - Assumptions/risk register (bulleted list, owner-assigned) - Handoff notes flagging which outcomes need indicators (for `nonprofit-outcomes-measurement`) and which sections need funder-narrative treatment (for `nonprofit-grant-writing`) ### After this When you've handed it back, suggest what they could do next in one short question. It's a suggestion: if they're done, that's fine. Offer these, and say they can type their own: - The [Product outcome roadmap planner](https://useaiblocks.com/skills/outcome-based-roadmap). It takes the plan. - The [Program keep-or-cut reviewer](https://useaiblocks.com/skills/program-keep-or-cut-reviewer). It takes the plan. - The [Nonprofit strategy planner](https://useaiblocks.com/skills/nonprofit-strategy-cycle-planner). It takes the plan. - **Lead the team** with the [Nonprofit change rollout planner](https://useaiblocks.com/skills/nonprofit-change-rollout-planner). It takes the plan. - The [Nonprofit executive board report writer](https://useaiblocks.com/skills/nonprofit-executive-board-report-writer). It takes the plan. If they pick one and that skill is added here, carry straight on with what you just made. If not, give the link and say what to bring.