AI Playbook

Build a Theory of Change with AI

6 steps · Works with any AI assistant · No signup required

Analyze the Problem

Before designing a theory of change, you need a rigorous understanding of the problem itself. This prompt produces a structured problem analysis that separates what you know from what you are assuming, which becomes the foundation for every subsequent step.

Prompt for this step

You are a senior M&E specialist with expertise in problem analysis, root cause diagnosis, and program design. Based on the program brief above, produce a rigorous problem analysis that will serve as the foundation for a Theory of Change.

Produce the following labelled sections:

1. **Problem statement** (2-3 sentences)
   - The core problem in precise, bounded language
   - Who is primarily affected and where
   - Why this problem matters now (urgency, policy window, or worsening trend)

2. **Root cause analysis**
   - Identify 3-5 contributing causes, structured as a cause tree (proximate causes first, then underlying structural causes)
   - For each cause, flag status as EVIDENCE-BACKED (with source type noted) or ASSUMPTION
   - Apply a "5 Whys" logic to at least one cause to reach a structural driver

3. **Affected population profile**
   - Primary affected group: size estimate, key characteristics, geographic concentration
   - Secondary affected groups: who else bears spillover effects
   - Relevant disaggregation dimensions (sex, age, disability, income quintile, location, ethnicity, etc.) that should shape program targeting

4. **Problem persistence**
   - Why have previous government, donor, or NGO efforts failed or fallen short?
   - Which assumptions in prior interventions proved wrong?
   - What has changed in the context that makes a new attempt viable now?

5. **Evidence base**
   - What we KNOW (with source type: peer-reviewed, grey literature, program data, expert consultation)
   - What we are ASSUMING (and why the assumption is reasonable or risky)
   - The single biggest evidence gap that should be closed before or during inception

Apply problem tree logic throughout, distinguishing symptoms from causes from structural drivers. Where you are inferring beyond the brief, mark inferences clearly with "INFERRED:" so the user can validate.

Output format: Return a single structured document with the five numbered sections above as headings, using sub-bullets under each. Use structured lists, not tables. Keep the full response between 600-900 words.
Step 1 of 6