Lessons from Papa Don

Donald Reinertsen’s Principles of Product Development Flow is a book that every engineering manager and product leader should read. It is packed with wisdom on how to make product development faster, smarter, and less chaotic. While the book dives deep into concepts like economic models and queueing theory, this post distills a few of its key lessons into hopefully practical tactics that are immediately applicable for modern teams.

It's a big book, and one of the densest in terms of words-per-wisdom. He's mentioned a few times in the more than recent past that he's working on a smaller primer, but pending that, here's a baby-simple starter post. If you have never thought about flow, small batch sizes, or the cost of delay before, this is a good place to start.

---

The pursuit of Flow

There’s a certain pride teams take in being busy. Full calendars, Slack threads overflowing, every hand on deck. It’s tempting to look at that busyness and assume all is well. But then why do things still feel stuck? Why does every sprint feel like a mad rush to nowhere?

Reinertsen’s Principles of Product Development Flow offers an uncomfortable truth. Busyness is a distraction. Flow is the goal. It’s not about doing more or doing faster, but about how work moves, smoothly, deliberately, through a system. A shift like this sounds simple enough, but in practice, it’s radical.

This post explores a handful of Reinertsen’s core principles: flow, small batch sizes, WIP limits, and decentralized decision-making. There is much more in the book, but these ideas are enough to get you started.

---

The Myth of Efficiency

Many teams follow an unwritten rule to keep everyone busy. If every person is at full capacity, surely the output will take care of itself. It sounds logical but it is completely wrong.

Reinertsen explains that optimizing for efficiency at every step creates a rigid and overloaded system. Pipelines fill up, complexity multiplies, and everything slows down. Teams mistake busyness for productivity and forget that real progress comes from a system that works smarter, not harder.

The surprising truth is that leaving some capacity unused, whether it is downtime for individuals or slack in the workflow, opens the door for meaningful progress. Without this breathing room, teams collapse under their own weight and become trapped in endless cycles of busywork.

---

Small batch sizes and cycle times

Reinertsen emphasizes the importance of keeping batch sizes small. For software engineering, this means breaking down work into smaller, deployable chunks. Instead of bundling features into massive releases, aim for frequent, incremental updates. Small batches not only reduce risk and make debugging easier but also deliver real feedback from users faster, allowing teams to adjust course quickly.

Cycle times are just as critical. Classically, cycle time is measured from ideation to done, but teams can also start simpler and measure from "in progress" to done. The key is to keep this time as short as possible. Long cycle times hide bottlenecks and delay learning, while shorter cycles help surface problems early. If your team uses pull requests, keep them small and review them quickly. Trunk-based development is almost always better, but perhaps that is a matter for another post.

The takeaway is simple. Ship smaller, ship faster, and learn as you go. The faster the feedback loop, the sooner your team can adapt and improve.

---

Work in progress: the silent killer

Reinertsen describes excessive Work in Progress (WIP) as one of the greatest threats to flow. In software engineering, this often shows up as a pile-up in the columns on your kanban board: “In Progress,” “Needs Review,” or “Ready for QA.” The more tickets sitting in these queues, the more progress slows down. Every new piece of work competes for attention, creating bottlenecks and delays.

A good way to start is for the team to agree on a limit for each column. For example, you might decide no more than five tickets can sit in the “Needs Review” column. The moment the limit is reached, the team shifts focus to clearing that queue before moving on to new work. You don't have any business picking up another task into "in progress" until the review column is cleaned up. This keeps the flow smooth and prevents backlogs from becoming overwhelming.

Similarly, if “Needs QA” starts to overflow, engineers can collaborate with QA to test and resolve issues. The idea is simple—focus on what is stuck, clear the blockages, and then move forward. The less WIP there is at any given moment, the faster your team will deliver.

---

Cost of delay: the hidden price

Cost of delay is one of the most overlooked yet impactful concepts in product development. Every piece of work sitting idle has a price—whether it is lost revenue, delayed customer value, or missed opportunities. Reinertsen makes it clear that understanding this cost is critical to prioritizing effectively and keeping the flow of work healthy.

In software engineering, this can mean shipping features sooner rather than letting them linger in development. For instance, a feature that could immediately resolve a major customer pain point has a higher cost of delay than a backend refactor. But here lies a common problem. Engineers are often not equipped to differentiate between the cost of delay for two product features, because they lack the full context of customer impact or business priorities.

The solution starts with collaboration. Engineers, product managers, and business stakeholders need to create an open dialog about the impact of each feature. Product teams should clearly articulate why a particular task has a higher cost of delay, backed by customer feedback, analytics, or market research. Engineers can then use this information to make better decisions during planning, even without diving into business details themselves.

A practical way to bring cost of delay into focus is by asking, “What happens if we delay this work by a week? A month? A quarter?” Features that carry a high cost of delay should move up the queue, even if they feel less glamorous than other work. Once teams start framing work this way—and including engineers in these discussions—prioritization becomes less about opinions and more about delivering the most value.

---

Decentralised decisions

Reinertsen highlights one of the most common bottlenecks in product development. Centralized decision-making. When teams rely on a single person or a small group to approve every decision, delays are inevitable. Work stalls, frustration builds, and the cost of inaction quietly rises.

You're better off federating the decisions to the team. This works particularly well when combined with small batch sizes. When teams deliver work in smaller, incremental chunks, the risk of any single decision going wrong is significantly lower. A less-than-optimal decision is no longer catastrophic—it can be identified and corrected quickly because the team is now operating with shorter cycles and faster feedback. Mistakes become opportunities to adapt rather than roadblocks to success.

---

Flow is everything

...and as engineering manager, it is your job to protect that fire. Reinertsen’s Principles of Product Development Flow challenges the way we think about work. It shifts the focus from isolated tasks and individual efficiency to the broader system, emphasizing flow as the true measure of progress.

Improving flow isn’t about rigid rules. It’s about rethinking the way work moves through your team.