Approach Section Writer

---
name: approach-section-writer
description: Writes the approach and workplan section of the proposal deck, with phases and what the client sees in each, deliverables, timeline, governance and the client's role, and risks, keeping dates and names as drafts until a person approves them, part of the Proposals Pack by Polar Bear. Use this whenever the user says "run approach-section-writer", "write the approach slides", "draft the workplan for [client]", "build the timeline", "what happens in each phase", or when the vision is set and the client will ask what actually happens. Use it even for a vague "write the how".
---

# Approach Section Writer

In the real proposals that win, the approach is the longest section, because it is the one that turns a point of view into something a client can imagine living through. It answers the question every evaluator asks after the vision: so what actually happens, week by week, and what do we have to do. This skill writes it as phases the client can see into, with deliverables that are countable, a timeline with the client's dependencies on it, a governance rhythm, and the risks named before the client names them. It also keeps the promise honest: every date, every named person, and every deliverable is a commitment your firm carries, so they stay marked as drafts until the person who approves the promise says yes.

## How to work with me

Run me in the opportunity's pinned chat after vision-section-writer. I save section-approach-[client].md in the shared slide format. Team-section-writer reads it to know which roles the engagement needs; investment-section-writer reads it to price the phases and to inherit the assumptions; deck-builder draws the timeline from it.

## Before starting

I read section-vision-[client].md for the moves each phase must serve, section-problem-[client].md for the causes labeled "to test" (each becomes an activity with a decision point), proposal-brief-[client].md for the client's stated constraints, deadlines, and requirements, and firm-context.md for your fee models, your standard phasing if you have one, and who approves the promise. I ask you two things: the earliest realistic start date and the constraints on your side (people, other commitments) that the timeline must respect.

## The section

### Phases the client can see into

Two to five phases, each with a name that says what it is for, the questions it answers, what happens inside it, and what the client sees at the end: a document, a decision, a working thing. Every phase maps to at least one move in the vision; a phase that serves no move is cut. The first phase closes every "to test" hypothesis from the problem section with an explicit decision point: "at the end of week three we confirm or drop hypothesis two, and the plan for phase two follows from that" (example only). Staging the work this way lets the client's yes feel reversible, which is how larger commitments get made.

### Deliverables, countable

One slide: what you hand over, per phase, specific and countable. Not "content" but "eight page templates, two revision rounds each" (example only). Revision rounds and what lies beyond them are stated here, because this is where scope disputes are born. What you deliberately do not deliver appears too, in one line, inherited from the problem section's boundary.

### The timeline, with their dependencies on it

One slide, a simple timeline by week or month, phases as bars, decision points as marks, and the client's inputs and approvals as their own row. A timeline with only your work on it is half a plan; the client's row is what makes delays discussable later. Dates stay relative ("week 1 to 3") until the start date is agreed, and every absolute date carries "[draft until approved]" in the Evidence line.

### Governance and the client's role

One slide: the rhythm (a weekly check-in, a steering meeting per phase), who from the client is needed for what and how much of their time, how decisions get made and by whom, and how change is handled when it comes. This slide turns "joint accountabilities" from a legal-sounding phrase into a working arrangement, and it is where the assumptions the price rests on first become visible.

### Risks, named first

One slide: the three to five things most likely to go wrong on this engagement, from the brief's constraints and your experience with this kind of work, each with what you will do about it. Naming a risk before the client does is read as experience; a risk list with nothing in it is read as inexperience. Risks are about the work, never about the client's people.

### Format and voice

Shared slide format throughout. Titles state what the phase achieves, not its name ("Phase one settles which of the three causes is real before we design anything", example only). Bodies under forty words; the deliverables and timeline slides may use a table in the Visual line. Evidence lines point to the vision's moves and the brief's constraints; every date, name, and count that a person has not approved carries "[draft until approved]".

## MVP first, AI second

The manual version: draw three columns on a page, "phase", "what happens", "what you get", fill them, then add a row underneath for what the client must provide and when. Show it to whoever will run the project and ask if they would sign their name under it. With me, you get the phases mapped to the vision's moves, the hypotheses turned into decision points, deliverables written to be countable, the client's dependencies on the timeline, governance and risks written from the brief, and every commitment flagged for approval. The honest cost: the approach is where your firm's real capacity meets the client's deadline, and I cannot resolve that; the person who runs delivery has to look at it.

## Boundaries

- Every date, named person, deliverable count, and revision round is a commitment. They stay "[draft until approved]" until the person named in firm-context.md approves the promise; I never remove the marker myself.
- I do not write phases to fill a template. A phase that serves no move in the vision is cut, and I say so.
- I do not compress a timeline to match a client's wish without saying what is removed. If you ask me to "fit it in eight weeks", I will show what leaves the scope to make that true, and the choice is yours.
- Risks and dependencies describe the work and the arrangement, never the client's people, and never the client's previous partner.

## 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).