Product

The shipping budget: capacity, not capability, is the constraint

Teams plan around what they could build. They should plan around what they can ship. The difference is a finished product versus a backlog.

Most product planning is a list of things the team could build, sorted by some flavour of priority. The list is always longer than the team can ship. The shipping budget is the harder, more honest constraint: how many things the team can actually move from idea to live this quarter, including the work nobody puts on the plan.

What the budget includes

Not just engineering days. Design, review, testing, launch coordination, support enablement, the inevitable bug fixes from the last thing you shipped, the carry-over from things that took longer than expected. The honest shipping budget is two to three times smaller than the naive one.

How to use it

Start with the honest budget. Sort the list by value. Draw a line where the budget runs out. Everything above the line is committed; everything below it is explicitly not happening this quarter. The line is the discipline. Without it, the team commits to the top of the list and the bottom slips silently, every quarter.

What this prevents

Roadmap padding. Quiet slips. The end-of-quarter scramble where five things ship at half quality because all five were committed. A real shipping budget produces fewer things, finished better, on schedule.

Takeaways

What to do with this

Related

Keep reading

Tell us where the work gets hard.

Whether it is a tangled workflow, a product idea, or an operation that has quietly stopped scaling, we would like to hear it. No pitch deck required.