From an idea in a conversation to a client who is very happy
Most of the work of running an agency happens in the gap between a client saying an idea is interesting and that idea becoming approved work. This is a map of that gap, left to right: every decision point on the way, and the sentences to say at each one.
Zoom out for the shape, in for the reasoning, all the way in for the words to say. Tap any box for the detail and the original phrasing.
Trace one project through it
The recording is explicit that there is no single path: which route a project takes depends on the nature of the project, the nature of the client, how much trust there is, how clear the impact is, how clear the sizing is, and how much technical risk it carries. Set the five reads below and the map lights the route that project would take.
What the map is claiming
The spine of it is one sentence: the job is to move a project from interesting and good to approved and being done, and everything on the left half of the map is a different route to that same box. Which route you take is not a matter of taste. It is read off the project and off the person in front of you.
Three of those routes are worth naming on their own, because they are the ones that get skipped.
- When a project is not defined well enough, the spec becomes the project. This is the move that unsticks most stalled conversations. You are not trying harder to approve a fuzzy thing, you are approving a small clear thing instead. And estimating a spec is genuinely easier than estimating a project, because a spec's output is not tightly defined either.
- A client who does not want to work hourly needs more specification, not less. Someone asking to buy an outcome is asking you to carry the risk, and the only honest way to carry it is to know what the thing is. The pricing follows: estimate the spec, double it because you now have to stand behind it, take the high end, and that is the number.
- Once several projects are running, the unit of approval changes. You stop getting projects approved and start getting the pipeline approved, which needs orders of magnitude rather than specifications, a quarter or two of horizon, and an explicit statement that none of it is a commitment.
The six dials
These are named in the recording as the things the workflow depends on. They are not stages, which is why they sit beside the map rather than in it.
The steel thread, and why it costs more on purpose
The most interesting thing in the recording is the treatment of technical risk, because it refuses the usual answer. A project nobody has built before might get stuck in the middle and come out badly, and the recommendation is still to try it, most of the time. What changes is the shape of the build: rather than building it end to end elegantly, you build every part end to end thin, prove the whole thing runs, then start again knowing how.
The arithmetic is stated plainly and accepted rather than argued away: a thirty hour project becomes thirty five, because the thread cost ten hours and only five of them carried forward. What the extra five hours bought is the answer to whether you know how to build it at all.
Where this map is thin, and honestly so
The recording defines project management as running from the general idea all the way past the end of execution to a client who is very happy, including the training, including everything. It then spends almost all of its detail on the first half. That asymmetry is drawn rather than hidden: the four boxes on the right with dashed borders are named in the recording and not worked through, and the map marks them so nobody mistakes a mention for a method.
The largest of those gaps is what you do at the moment you notice a project has gone off track. The risk is acknowledged up front and accepted deliberately, and then there is no procedure for the moment it lands.
Boxes with a solid border were worked through in the recording. Boxes with a dashed border were named and not detailed. A diagram that shows only the finished half of a system reads as a brochure.