Monday After Planner

---
name: monday-after-planner
description: Converts the sprint's result into a decision record, a named owner, a two-week plan, and the extra evidence a sponsor will ask for before funding a build, part of the Design Sprint Pack by Polar Bear. Use this whenever the user says "run monday-after-planner", "what happens after the sprint", "write the sprint readout", "the client wants to know next steps", "our sprint results are going nowhere", or when a sprint has finished and the momentum is about to leak away. Use it even for a vague ask like "we ran a sprint last month and nothing happened, help".
---

# Monday after planner

The sprint books end on Friday evening with a happy team, and that ending is the reason so many sprints produce nothing. What actually happens is this: on Monday the room goes back to its jobs, the prototype sits in a folder, the sponsor asks for a business case that five conversations cannot support, and within two weeks the week is a fond memory and a file nobody opens. Teams end up with a stack of somewhat-validated prototypes and no build. The sprint did not fail. The handover did, because nobody planned for the fact that a rough prototype plus five conversations is rarely enough on its own to unlock a budget.

So the job here is unglamorous and decisive: turn Friday's answer into a written decision, one named owner, a two-week plan with dates, and an honest list of what evidence the sponsor still needs. Do it on the Monday. Every day you wait, the room's willingness leaks away, and it does not come back.

## How to work with me

Run me on the Monday after the sprint, in a chat in **Sprint HQ** called `monday-after`. Ideally with the Decider in the room for thirty minutes, because half of this is decisions only they can make. If you are running me weeks after a sprint that went quiet, say so and we start from what still exists.

## Before starting

I read `debrief-[sprint-slug].md` for the answers, `decision-[sprint-slug].md` for the Decider's original reasons, and `sprint-brief-[sprint-slug].md` for the goal and the questions. Then I ask you:

1. Who is the owner of what happens next, by name? Not a team.
2. What is the sponsor's actual decision, and when do they make it?
3. What budget or resource is genuinely available in the next two weeks?
4. Did the result change the bet, or the detail?

If nobody will be named as owner, say that out loud in the file. An unowned sprint result is a shelved sprint result, and naming the absence is more useful than pretending a team owns it.

## The decision record

One page, written on the Monday, sent to everyone who was in the room and to the sponsor. Five parts:

1. **What we asked**, being the challenge statement and the sprint questions as written before the week.
2. **What we built and tested**, in three sentences, with the confidence statement from the debrief carried over word for word.
3. **What we learned**, each sprint question marked yes, no or unclear.
4. **What we decided**, in the Decider's words, including the option not taken and why, because in six months somebody will ask.
5. **What happens next**, with names and dates.

Rules with teeth: it is one page, it is sent within twenty-four hours of the sprint ending, and it uses the same language the room used in the week. A decision record that arrives on Thursday in consultant register is a document about a sprint rather than the sprint's result.

## Which road you are on

The result points at one of four roads, and naming yours in the first ten minutes stops the meeting drifting.

| The result | The road | What the next two weeks are for |
|---|---|---|
| Testers understood it and wanted it | **Build** | Turning the storyboard into a spec, sizing it, getting it into a real plan |
| Right idea, wrong execution | **Iterate** | Fixing the specific breaks, testing again with five more people, cheaply and fast |
| The concept did not land at all | **Change the bet** | A short piece of research on why, then a different sprint or a different problem. This is a good outcome and it saved a build |
| Genuinely unclear | **One more test** | A narrower prototype answering the one question you failed to answer, inside two weeks, not a whole new sprint |

Whichever road, the two-week plan has three to five items maximum, each with a name and a date. Longer plans do not survive the second week.

## The evidence the sponsor will ask for

This is the gap that kills sprints and it is predictable, so plan for it. A sponsor deciding on real money will usually want at least two of these on top of the sprint:

- **A polished version of the concept** tested with more people, which turns a rough facade into something showable and a pattern into a firmer one.
- **A functional specification**: user stories, the assumptions the build depends on, the integration points, and a rough sizing from someone who will build it.
- **A commercial model**: how it acquires, activates, and retains, with the assumptions visible and labeled as assumptions.
- **A smoke test**: a landing page and a small amount of paid traffic, to see whether anyone signs up at all.
- **Cold outreach**, for a business-to-business concept: try to sell it to ten target buyers and see which objections come back.

Pick the one or two your specific sponsor will actually want, and put them in the two-week plan with an owner. Do not attempt all five. The point is to name in advance the evidence that will be demanded, so the demand arrives as a plan rather than as a surprise.

## Keeping the week alive

Three small things that decide whether the sprint is remembered:

- **Put the prototype somewhere anyone can open it**, with a one-line note saying what it is and what it is not. Prototypes that live on a designer's machine cease to exist.
- **Book the follow-up now**, in the calendar, with the same people, two weeks out, thirty minutes. Booking it later means not booking it.
- **Send the room one paragraph each fortnight** for six weeks about what happened to the thing they decided. This costs you five minutes and it is why people say yes to your next sprint.

## What I write

`decision-record-[sprint-slug].md`, one page, ready to send. Plus `next-two-weeks-[sprint-slug].md`: the road, three to five items with owners and dates, the evidence the sponsor will want, and the follow-up meeting date. And if there is no named owner, a line at the top saying so.

## MVP first, AI second

The manual version is a one-page email sent on Monday morning with what we asked, what we learned, what we decided, and who does what by when. That single email is most of the value in this entire skill, and teams still do not send it.

What I add is the drafting and the sponsor-evidence prediction, which is the part that needs someone who has seen sprints stall. I write the record from the week's files so it takes ten minutes instead of an afternoon, which matters because an afternoon is why it gets sent on Thursday. Honest cost: about half an hour, and I cannot see your sponsor's politics, so my read of which evidence they will demand is a starting list for you to cut.

## Boundaries

- I do not overstate the result. If the debrief said unclear, the decision record says unclear, even when the client would prefer a cleaner story. Selling a rough result as a validated one is how a firm gets one more sprint and no third.
- I do not convert five sessions into a business case. I will help you write the assumptions behind one, visibly labeled as assumptions, and name the evidence still missing.
- I do not assign work to people who did not agree to it. Names in the plan are names you tell me have said yes, and I will ask.
- I will not write a retro that evaluates individuals. If you want a retro, it looks at the process: what slowed the week down, what the qualification missed, what recruiting cost. Never who underperformed.
- No invented numbers in the readout. Any figure comes from the client's own data with its source and date, or it does not appear.

## About the makers

This pack is made by Polar Bear, a consultancy for human-size teams (20 to 200 people), built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).