Welcome to the Delivery Playbook

This is the Customer Obsessed Delivery Playbook — a reference manual for designing, building and shipping software that delights customers. It’s the companion to the Customer Obsessed Engineering blog, but it serves a different purpose: Where the blog explores ideas at length — arguments, case studies, stories — the playbook is lean, prescriptive and ready to use at your desk, with supporting tools ready-to-go.

Think of it as a pilot’s checklist, not a pilot’s autobiography.

A living reference manual

The playbook is alive. It evolves constantly. New chapters, refined guides, additional templates, sharper process steps — these show up whenever I learn something worth writing down. That’s the whole point: A good playbook is never finished, because the craft of software delivery isn’t finished either.

If you bookmark any page here, you’ll always find the latest version. Nothing gets stale in a drawer.

What’s inside — and why it matters

The playbook is organized around five working tools. Each one was added because it closes a specific gap that costs teams real time, real money or real trust. Here’s what they do for you.

The subway map

The subway map is your orientation. It shows the full delivery lifecycle as a connected sequence of activities — from pre-mobilization through operations — so you always know “where am I?” and “what comes next?” Click any stop to jump straight to the relevant chapter.

You can access the subway map at any time by clicking the in the upper right corner.

The value: Teams lose more time to ambiguity than to hard problems. The subway map eliminates the ambiguity. No more debating which activity comes first, whether you’re ready to move forward, or what you’ve skipped. One glance tells the whole team — engineers, designers, product owners, customers — exactly where you are on the delivery path. It’s the single most effective onboarding asset I’ve ever produced: New team members become productive in days, not weeks.

The chapters

The playbook’s 28 subway-map activities each have a dedicated chapter. Every chapter follows the same shape: Goals and impact, inputs, activities, outputs — plus detailed methods, examples and suggested tools.

The value: This is the playbook’s depth. When your team is about to start strategic event storming, or build an architecture umbrella, or run a security review, the chapter tells you exactly how to do it. What inputs must be in place. Who needs to be in the room. What artifacts to produce. What “done” looks like. No more re-inventing the approach on every project. No more “we thought we were ready but we weren’t.” The chapters turn senior-level expertise into something any team can execute — reliably, the first time, and every time.

The guides

The guides cover the techniques teams reach for throughout delivery: fishbone diagrams, pre-mortems, dot voting, the 5 Whys, A3 problem solving, Pareto analysis, TRIZ, SWOT, 1-2-4-All and more. You’ll also find deep-dive workshop walk-throughs for the workshops I run most often with teams (rework, automation and planning).

The value: Every guide is short, structured and focused on how to run it — not theory. When you need to unblock a decision, diagnose a defect, facilitate a retrospective or prioritize a backlog, you open the relevant guide and you’re running the technique five minutes later. These are the moves that separate teams who can self-correct from teams who spin. And unlike the blog articles, the guides are working instructions — no filler, no backstory, just the play. You won’t find these anywhere else.

The templates

The templates are working artifacts — real, battle-tested starting points for architecture umbrellas, product visions, feature specifications, risk logs, stakeholder maps, domain detail, gap analyses, service catalogs and more. Every template has been used on real projects, hardened through real feedback and refined to remove the parts that don’t earn their keep.

The value: Templates collapse weeks of work into minutes. Instead of your team arguing about what an architecture document should contain, they’re filling one in. Instead of re-designing a risk log for the fifth time, they’re logging risks. Each template carries an enormous amount of tacit knowledge — what fields matter, what structure scales, what the customer actually needs to see. Copy one, adapt it to your context, ship. These are playbook-only too.

The structure itself

Every piece of the playbook follows the same pattern: clear inputs, a defined activity, explicit outputs. Every chapter, every workshop, every template expects something from the previous step and produces something for the next. This is the quiet superpower.

The value: The structure is your quality gate. You can’t move forward with half-baked inputs. You can’t leave an activity without producing the outputs the next team needs. It makes quality non-negotiable without anyone having to police it. Projects that follow this structure don’t drift, don’t surprise the customer and don’t arrive at launch missing a critical deliverable. In my experience, that’s worth tens of thousands of hours across a program, and it’s the difference between a team that ships and a team that firefights.

How to use it

The short answer: Use it every day. Open it when you’re stuck. Open it when you’re planning. Open it when you want to remind yourself of a step. Open it during workshops, during design reviews, during onboarding. Treat it the way an airline pilot treats a preflight checklist — not as bureaucracy, but as the thing that keeps the plane in the air.

For a deeper orientation, start with these three chapters:

• How to use a playbook — what a playbook actually is, and why development teams benefit from one.
• 12 reasons to level-up your team — the measurable gains a good playbook delivers.
• Getting started: Using the Delivery Playbook — a walk-through of the subway map and how the pieces connect.

A quick note about me

I’m Zac Beckman — I’ve been building software for about forty years, leading engineering teams for most of them. This playbook is the distillation of what’s actually worked across defense, entertainment, research, enterprise and startup contexts. Every pattern in here has been used, broken, refined and used again. If something in the playbook seems too opinionated, it’s probably because I’ve watched the alternative fail.

Have a look around. And welcome.