Nonprofit program outcome planner

What goes in and out

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).
• Document (optional)

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.

How the task works

• Start with the change. Define the long-term aim, then work backward to the smaller changes needed along the way.
• Connect activities to results. Map resources, activities, counts of work delivered, and changes for people. Keep counts separate from outcomes.
• Check the assumptions. Test why each link should hold, name outside factors, and identify missing evidence or delivery knowledge.

Full instructions

• Open Claude, ChatGPT or Gemini. Paste in this skill's instructions. No code or paid tool is needed.
• Paste your program details: activities, resources, the need, and the change you want.
• Add counts and evaluation data if you have them. Say so if you have none.
• Read the table. Check that counts sit under outputs and changes in people sit under outcomes.
• Ask your AI to explain any link that does not make sense. Fix or cut it.
• Show the draft to the staff who run the program. Ask what assumptions are false.

Full instruction file

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:

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. It takes the plan.
• The Program keep-or-cut reviewer. It takes the plan.
• The Nonprofit strategy planner. It takes the plan.
• Lead the team with the Nonprofit change rollout planner. It takes the plan.
• The 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.