Planning & Project Breakdown Patterns
Four patterns for turning a rough goal into an executable plan — the milestone ladder, risk-weighted sequencing, a definition-of-done generator, and a dependency mapper — each with the specific way it goes wrong.
Someone hands you a goal — "improve onboarding," "get this feature shipped by end of quarter," "reduce support ticket volume" — and it's your job to turn that sentence into a sequence of tasks with an actual order, actual owners, and an actual way to know when each piece is done. Most people do this by intuition, and intuition is fine right up until someone asks "why are we doing the easy stuff first when the risky part hasn't even been de-risked yet."
The four patterns in this lesson turn a rough goal into a structure you can defend: a ladder of milestones each with a testable finish line, a sequencing rule that doesn't quietly avoid the scary task, a way to generate acceptance criteria instead of vibes, and a map of what blocks what before you commit to an order.
Pattern 1: The Milestone Ladder (WBS Slice)
Take the goal and slice it into milestones — a work breakdown structure, rung by rung — where each rung has a name AND a Definition of Done specific enough that someone who wasn't in the room could check whether it's actually climbed.
The prompt shape:
Goal: [the rough goal]
Break this into 3-5 milestones between here and done. For each milestone,
provide: (1) a short name, (2) a Definition of Done — a specific, testable
statement someone else could check without asking me what I meant.
Order the milestones the way they'd actually need to happen.
When it works: turning any goal-shaped sentence into a sequence you can actually track — status updates become "we're on milestone 2 of 4" instead of "we're making progress."
When it fails: if the Definition of Done stays vague ("wireframes look good") instead of testable ("three named stakeholders sign off in writing"). A milestone with a fuzzy DoD isn't a checkpoint — it's a mood, and moods can't be marked complete by anyone except the person who felt them.
Pattern 2: Risk-Weighted Sequencing
Once you have milestones, the natural instinct is to do the easy ones first — quick wins build momentum. Risk-Weighted Sequencing argues the opposite for the riskiest piece: the task with the most uncertainty, the one most likely to invalidate your plan if it goes badly, should usually go first, because doing it last just means discovering the plan was wrong after you've spent everything else on the easy parts.
The prompt shape:
Milestones: [the list from Pattern 1]
For each one, estimate: (1) uncertainty of the estimate itself — do we actually
know how long this takes, (2) likelihood it blocks other milestones if it slips,
(3) cost of discovering it's wrong late vs early.
Recommend a sequence that front-loads the highest combined risk, and explain
the reasoning for the order — not just the order itself.
When it works: any plan where one task's outcome could invalidate the assumptions behind the rest — a proof of concept, a vendor evaluation, an unfamiliar integration. Doing that piece first means you find out early, while you still have runway to change course.
When it fails: when "riskiest" is subjective and un-defined, and the pattern becomes a rationalization for either doing the hardest task first out of anxiety, or quietly relabeling the scary task as "low risk" to justify avoiding it. The fix is the same either way — make the risk definition explicit (uncertainty, blocking potential, cost of late discovery) and require the reasoning alongside the ranking, not just the ranking itself.
Pattern 3: The Definition-of-Done Generator
This is Pattern 1's DoD step, isolated and run on its own whenever a goal shows up without any milestones yet — useful the moment someone hands you a one-line ask and you need to know what "done" even means before you can plan anything.
The prompt shape:
Vague goal: "[the one-line ask, verbatim]"
Turn this into 2-4 acceptance criteria that are specific and testable — someone
who did not write the original goal should be able to check pass/fail against
each one without asking what was meant. If the goal is ambiguous in a way that
changes the criteria, name the ambiguity explicitly instead of guessing.
When it works: the moment between "here's a goal" and "here's a plan" — it forces the ambiguity in a one-line ask to surface before you've sequenced anything on top of a shaky foundation.
When it fails: if you let the model resolve genuine ambiguity silently instead of flagging it. "Improve onboarding" could mean faster time-to-first-value, higher completion rate, or fewer support tickets — three different DoDs. A generator that picks one without telling you it had to choose has quietly made a product decision on your behalf.
Pattern 4: The Dependency Mapper
Before you commit to an order, map what actually blocks what. Two tasks that look sequential in a todo list might really be independent and parallelizable; two tasks that look unrelated might share a hidden dependency that will stall everything if you sequence them wrong.
The prompt shape:
Tasks: [the milestone/task list]
For each task, list what it depends on (must finish before this can start) and
what depends on it. Identify the critical path — the chain of dependencies that
determines the earliest possible finish. Flag any task that can slip without
affecting the overall timeline.
When it works: any plan with more than a handful of tasks and more than one person working on it — the map is what tells you which tasks can run in parallel and which ones are secretly gating everything downstream.
When it fails: when dependencies are asserted instead of verified. It's easy for a model (or a person) to assume Task B depends on Task A just because they were listed in that order, when they're actually independent. An unverified dependency map can sequence work more conservatively than necessary, or worse, miss a real dependency and let two teams collide.
If you want the deeper mechanics of why decomposition prompts outperform single-shot "make me a plan" requests — how scaffolding and chain-of-thought structure the model's reasoning — that's Prompt Engineering Mastery's territory. This lesson assumes you can already write the prompt; it's handing you the four shapes worth reaching for the next time a goal lands on your desk with no plan attached.
Bottom Line
Four patterns, one job: turn a rough goal into an order you can defend. The Milestone Ladder slices the goal into testable rungs. Risk-Weighted Sequencing decides which rung goes first for a real reason, not an emotional one. The Definition-of-Done Generator makes sure "done" is checkable before you start. The Dependency Mapper confirms your order doesn't secretly violate a blocking relationship. Together they replace "here's a todo list" with "here's a plan, and here's why it's sequenced this way."