Delivery

Spike. Epic. Kanban. Sprint. Scrum master.

Back on the home page I told you nobody gets into product because we enjoy made-up words. I stand by that. But you're going to spend a real part of your career swimming in them, so this is the section where they stop being noise and start meaning something. Not all on this page. This page is the map; the pages it points to are where each word gets unpacked.

By the time you reach this section, you've already done the hard thinking. Back in Part 04 you decided what to build and validated it, which here means you proved a real problem, found a real solution, and gathered evidence that customers actually want it before anyone wrote a line of code. The opportunity backlog (your prioritized list of customer problems worth solving) has done its job and handed you a solution worth building. That's where this section picks up.

And here's the trap. Most people treat what comes next as the easy part. The thinking's done, now we just execute. Hand it to engineering, go dark, come back when it's done.

Then what ships isn't what you validated.

Delivery is where validated ideas go to die. Not because the idea was wrong. Because the build was run badly. Badly run process kills more good product than bad strategy does, and it kills it quietly, one fuzzy ticket and one missed assumption at a time. How you build decides whether the validated idea survives contact with a real team and real users.

So this section is about the build itself. Four pieces, and each one sits inside the one before it.

The SDLC is the whole field: the software development lifecycle, start to finish. The team that builds it, the phases the work moves through, and what good looks like at each one. You don't have to write the code. But if you can't tell a healthy dev process from theater, you can't protect the outcome you just validated.

Agile is the operating rhythm. Not the calendar ritual most teams call agile. The real thing: release to real customers, learn from what they actually do, let the data pick your next move. That's empiricism, and it carries this whole section's rhythm. If you don't release to your customer, you can't be empirical. And if you're not being empirical, you're not being agile. You're doing waterfall (plan everything up front, build for months, ship once at the end) in two-week chunks and calling it something cooler.

Just-in-Time Development is how the right work gets pulled through the flow instead of pushed. You refine and build the next thing just before you need it, in small scoped pieces, instead of stockpiling a six-month backlog of guesses. The borrowed idea is lean, Toyota's system for building only what's needed when it's needed instead of stockpiling ahead, and it maps onto product cleanly: plans built far ahead of the work are inventory, and inventory rots. A plan written six months early is built on guesses that are wrong by the time you reach it.

The three guides are how you write the work so the team can build it. The hierarchy runs epic, then story, then task, each level one step smaller than the one above it. Written well, anyone who reads any of them knows what to build, why it matters, and when it's done.

A quick note on tools. No single tool manages this whole flow well, from discovery through delivery. I've used the popular ones. They're built for how people already work, not how people should work, so you end up bending your process to the tool. Don't. Learn the hierarchy and the why behind it first. The tool is just where you type it.

That's the map, and the pieces stack. The SDLC is the field you're playing on. Agile is the rhythm you play it at. Just-in-Time is how the work moves through that rhythm. The three guides are how you write the work that moves. Get these right and the thing you validated is the thing that ships.

Let's build.