How to Run a Rapid Learning Cycle: A Step-by-Step Guide
Stop asking if it worked. Start asking what you need to learn next.
Traditional evaluation asks: What happened?
Rapid learning cycles ask a different question: What do we need to learn in order to make a better decision?
The difference sounds small, but it changes everything about how a team works. It’s not really about speed. It’s about posture - treating learning as something woven into the rhythm of a project, rather than something that happens in a report at the end of it.
Many organizations today are working in environments where strategies evolve quickly, community needs shift, and new questions emerge faster than traditional evaluation timelines can answer them. By the time you’ve designed a study, collected six months of data, and written a report, the decision you were trying to inform has often already been made.
That doesn’t mean rigorous evaluation has become less important. It means there are moments when organizations need a different kind of learning alongside it.
Rapid learning cycles are one way to do that. Rather than trying to answer every question at once, they help teams investigate one focused question, make a decision, and use what they learn to identify the next question worth exploring.
I’ve used versions of this approach with nonprofits, foundations, and research teams that were testing new ideas, refining programs, or trying to understand emerging patterns before they became obvious. Here’s how I approach it.
Rapid Learning Cycle in Action:
Throughout this post, we’ll follow a fictional nonprofit that has launched a new peer support program. While attendance at the first session is high, only about half of participants return for the second session. The team wants to understand why before enrolling the next cohort.
Before You Start: Is This Even the Right Tool?
Rapid learning cycles are built for questions that are urgent, uncertain, and reversible. They’re a poor fit when:
The stakes are high and the decisions are hard to undo, like a major restructuring, a policy change affecting eligibility, or anything with legal or safety considerations. Those deserve slower, more rigorous processes and evaluation.
The decision needs broad buy-in, not just a good answer. If people who weren’t in the room will need to trust and act on the conclusion (for example, your whole staff, a coalition of partners, or a skeptical board), a fast cycle with five conversations may get you the right answer without getting you the legitimacy to act on it. That takes broader inclusion, which takes more time.
You genuinely don’t know where to start. Rapid cycles work best when you have a hunch worth testing. If a team can’t generate even a rough hypothesis about what’s going on, that’s a sign you need broader exploratory work first. The cycle works better once you have something to narrow in on.
The question isn’t really urgent. If nobody is waiting on an answer in the next few weeks, you don’t need a rapid cycle. You need a good evaluation plan.
If your situation fits one of those, this isn’t the wrong idea, just the wrong speed. Use rapid learning cycles alongside rigorous evaluation, not as a replacement for it. Often the fast cycle tells you what’s worth evaluating rigorously later.
What It Takes
Before diving into the steps, a quick gut-check on what running one of these actually requires:
Time: Roughly 2-4 weeks of calendar time, with maybe 3-5 hours of actual team time spread across the cycle (a sensemaking session, some light data-gathering, a short memo).
People: A small group of people with different vantage points on the decision. Try to keep it around 3-6 people, such as program staff who see the work day to day, a leader who owns the decision, and ideally someone once removed from the work (a partner, consultant, or different team member) who won’t share the same blind spots.
Cadence: Cycles chain together. One ends with the next question already identified, so a healthy rhythm is a new cycle kick off every few weeks, especially during a launch, pilot, or period of change.
Step 1: Start with a decision
This is where most rapid learning efforts already go off track - right at the beginning. Teams often begin with questions like:
Is our program work?
What impact are we having?
Those aren’t bad questions. They’re just too broad to be useful over the next 2-3 weeks. Instead, start by asking: What decision are we trying to make? For example:
Should we continue investing in this outreach strategy?
Should we redesign our onboarding process?
Should we scale this pilot to additional sites?
Which participant group should we prioritize next?
Once you’ve identified the decision, work backwards to the learning question.
| Decision | Useful learning question |
|---|---|
| Redesign onboarding | Where are participants getting stuck during their first two weeks? |
| Improve retention | What seems to influence whether participants return after their first visit? |
| Test a new coaching approach | How are coaches actually using the new model in practice? |
| Prioritize product improvements | Which frustrations are appearing most consistently across user feedback? |
A useful rapid learning question is:
Directly connected to a decision someone will make soon
Narrow enough that it can be explored in 2-4 weeks
Answerable with information you can reasonably gather
Likely to change what you would do if you learn something new
Once question I often ask teams: If we had a really good answer to this question, what would we actually do differently? If nobody can answer that, it’s probably not the right question.
In Action:
Decision: Should we change our onboarding process before the next cohort begins?
Instead of asking “Is our peer support program working?,” the team asks: What seems to influence whether participants return after their first session? This question is connected to a real decision, narrow enough to explore in a few weeks, and likely to change what the team does next.
Step 2: Gather “good enough” evidence
Rapid learning is not about collecting as much data as possible. It’s about collecting enough evidence to inform the decision you’re trying to make. Often, that evidence already exists.
Before launch new surveys or designing new interview protocols, ask:
What data do we already have?
Who has been closest to this issue?
What conversations have we already had?
What documentation already exists?
You might already have:
Open-ended survey responses
Notes or transcriptions from past interviews or conversations
Case notes, meeting notes, participant or partner emails
Slack conversations, CRM notes, observation notes
Customer service tickets
If you don’t already have relevant information, keep data collection intentionally lightweight. Rather than interviewing 30 people, talk to 5-8 people who represent different experiences. Rather than surveying your entire network, ask five staff members who interact with participants every day what they’re noticing.
Right now, the goal isn’t representativeness. It’s learning quickly enough to improve your next decision.
One practical rule: collect data until you’re hearing the same ideas repeatedly or until you’ve gathered enough evidence to confidently move the conversation forward.
In Action: Before collecting new data, the team takes inventory of what already exists: attendance records, facilitator notes, participant feedback forms, and follow-up emails. They realize they’re missing one important perspective: people who attended once but never returned. Rather than launching a large study, they talk to 6 former participants for 10 minutes each (at most).
Step 3: Make sense of the evidence together
Analysis and sensemaking are not the same thing. Analysis helps identify patterns. Sensemaking asks what those patterns might mean.
Bring together a small group of people with different perspectives (e.g., program staff, leadership, consultants, community partners, whoever is closest to the work or decision). Instead of presenting conclusions, present observations. For example:
Six of the eight participants described feeling confused after onboarding
Staff consistently mentioned transportation barriers
New users returned after the first coaching interaction
Then facilitate discussion around questions like:
What explanation might account for this?
Where do we agree? Where do we interpret the evidence differently?
What assumptions are we making?
What additional information would increase our confidence?
It helps to distinguish between four types of statements:
Observation: Participants stopped logging in after week one.
Interpretation: The onboarding experience may feel overwhelming.
Hypothesis: If we simplify onboarding, then participant engagement will improve.
Conclusion:Too early to tell.
Teams often jump from observation straight to conclusion. Slowing down long enough to generate multiple hypotheses usually leads to better decisions.
In Action: During the team’s sensemaking session, they notice several patterns: most participants felt welcomed, transportation was mentioned only occasionally, and several people described leaving the session unsure what would happen next.
Rather than immediately deciding onboarding is the problem, the team generates several possible explanations: expectations about future sessions weren’t clear, participants wanted more follow-up after the first meeting, or the first session may have felt emotionally overwhelming.
Instead of asking “which explanation is correct?,” they ask, “Which explanation should we test first?”
Step 4: Decide what you’ll do next
The purpose of a rapid learning cycle isn’t just to understand something better. It’s to decide what to try next. That decision doesn’t need to be perfect; it just needs to be explicit.
At the end of your sensemaking session, ask:
What do we believe is the most plausible explanation and why?
How confident are we?
What action makes sense given what we know today?
What assumptions are we testing with that action?
What should we pay attention to over the next few weeks?
Sometimes you’ll decide to make a meaningful change. Sometimes you’ll decide not to change anything because the evidence isn’t strong enough. Both are legitimate outcomes. The important thing is making your reasoning visible.
A simple template:
Based on what we learned, we believe…
Because of that, we’re going to…
We’ll know we’re moving in the right direction if…
You’re not trying to predict the future. You’re making your best hypothesis explicit so you can learn from it.
In Action: Based on the discussion, the team decides to test three small changes with the next cohort:
Revise the follow-up email after the first session
Add a five-minute explanation of what participants can expect in future meetings
Personally reach out to anyone who misses the second session
They also identify what they’ll watch: Do more participants return? Do participants report feeling clearer about what comes next? Are facilitators hearing different questions after the first meeting?
Step 5: Capture what you’ve learned before starting the next cycle
Document the learning while it’s still fresh. This doesn’t need to be a polished report. Those can slow learning down. A two-page memo is usually enough. You want to capture:
The question you explored, and why it mattered
What evidence you reviewed
Key observations
The hypotheses you developed
The decisions you made
What you’ll watch over the next few weeks
The next learning question that emerged
That last point matters most. Every rapid learning cycle should generate the next one. As you move through these cycles, you’ve progressively reducing uncertainty by asking better questions over time.
In Action: Learning memo:
Learning question: What influences whether participants return after the first session?
Evidence reviewed: conversations with past participants, feedback forms, case notes
Key observations: Most participants felt welcomed; transportation was mentioned only occasionally; several people described leaving the session unsure what would happen next
Working hypothesis: Participants needed clearer explanations after their first meeting.
Decisions: Revise the follow-up email after the first session; add a five-minute explanation of what participants can expect in future meetings; personally reach out to anyone who misses the second session
What we’ll watch: Attendance at the second session and participant feedback about the onboarding experience.
Next learning question: If attendance improves, which change appears to have made the biggest difference?
Quick Reference Checklist
Save this for your next cycle:
Name the decision someone needs to make in the next few weeks
Turn it into a narrow learning question that passes the “what would we do differently?” test
Inventory existing evidence before collecting anything new
Talk to 5-8 people if you need new data and stop when you’re hearing repeats
Separate observation from interpretation before jumping to conclusions
Generate multiple hypotheses, then pick one to test first
Decide explicitly what you’ll do next and what you’ll watch for
Write a two-page memo, including your next learning question
Start the next cycle
A final thought
One misconception about rapid learning is that it’s simply “evaluation, but faster.” That’s not quite right. The biggest shift isn’t the timeline. It’s the posture.
Traditional evaluation often asks, “Did this work?” Rapid learning asks, “What do we need to learn next to make a better decision?”
When organizations build that question into the rhythm of their work, learning stops being something that happens at the end of a project and becomes part of how the project evolves.
