Sometimes it is more helpful to know what not to do. Anti-patterns turn that idea into a diagnostic habit: they describe the failure shapes that show up repeatedly when organizational mechanisms do not match system demands. In practice, the value of anti-patterns is that they compress years of experience into a quick set of checks we can apply while the work is still malleable.
Anti-Patterns in the book
The book’s chapter structure consistently supports fast diagnosis. Each chapter introduces the core mechanism of the topic at hand and grounds it in an applied context. Case studies and examples from real teams ground the content in reality. Imporantly, the book examples are brief and reference the website, where the growing library of case studies is available for free. Each chapter ends with a wrap-up section that helps you navigate the book and to effectively use it as a quick reference.
Most chapters the Product Velocity book include a short anti-pattern section. When a pattern of failure appears across teams or contexts, it is named and described so that it can be recognized quickly in practice.
The number of anti-patterns per chapter stays deliberately small. Fewer than seven keeps the set usable. Practitioners can scan the list, compare it to their current situation, and identify likely problem areas without navigating a large taxonomy under time pressure.
Anti-patterns also introduce a discipline of alignment. They force a check between the way work is organized and the goal of the system it supports. When these diverge, the symptoms tend to follow familiar shapes. Some are structural, others are epistemic or economical, guiding readers on domains outside their core area of expertise.
Naming these failures makes them easier to discuss and harder to ignore.
3 Anti-Patterns
As of this writing, the book defines 126 anti-patterns drawn from recurring failure modes in real systems. Each chapter distills a small set to keep them usable in practice. The examples below illustrate the approach.
Incentive Inversion
Chapter Context: This anti-pattern resides in the chapter on culture and value flow (Part 2). The chapter explains how incentives shape behavior across the Velocity Loop. It connects local decisions to system outcomes and shows how misaligned incentives distort flow, delay learning, and shift effort away from customer value.
Anti-Pattern: The anti-pattern appears when local targets contradict system goals. Teams optimize utilization, output, or compliance while overall outcomes degrade. Work queues grow, feedback slows, and decisions favor local efficiency over end-to-end flow.
Advice: Align incentives with system outcomes. Tie goals to measurable customer value and flow efficiency, not local activity. Expose trade-offs across the system and make them visible in decision forums. Review incentives when queues grow, lead times increase, or teams optimize against each other. Remove metrics that reward local success at the expense of global results.
Interfaces as Secondary Artifacts
Chapter Context: This anti-pattern resides in the chapter on interface management (Part 3). The chapter defines interfaces as explicit contracts that expose behavior and hide realization. It distinguishes logical and physical interfaces and shows how they preserve intent across variants and enable parallel development. Interface quality determines whether change remains local or propagates.
Anti-Pattern: The anti-pattern appears when interfaces are implicit or unmanaged. Responsibilities blur, assumptions leak, and interfaces accumulate scope. Integration absorbs the resulting complexity. Mismatches surface late, coordination increases, and changes ripple across the system.
Advice: Treat interfaces as primary design decisions. Define them explicitly, limit their scope, and assign ownership. Separate logical intent from physical realization to stabilize behavior across variants. Validate interfaces against real usage and expected change. Refactor interfaces when integration effort rises or changes propagate beyond their boundary.
Uniform Synchronization Cadence
Chapter Context: This anti-pattern resides in the chapter on continuous integration and verification (Part 4). The chapter explains how synchronization cadence governs feedback speed, integration risk, and flow. It shows that different parts of the system operate at different natural tempos and that forcing a single cadence ignores this variation.
Anti-Pattern: The anti-pattern appears when all work is synchronized to the same schedule. Fast-moving parts wait, slow-moving parts rush, and integration happens at artificial boundaries. Feedback is delayed or distorted, and defects accumulate between synchronization points.
Advice: Match cadence to the work. Integrate fast-moving components continuously and decouple slower domains with stable interfaces and staged validation. Use asynchronous integration where possible and synchronize only where dependencies require it. Review cadence when queues form, integration risk rises, or feedback arrives too late to act.
Common Sense
Anti-patterns are diagnostic, but they still require common sense. The same symptom can have different causes depending on context, constraints, and the system’s dominant uncertainties. That is why the most consistent practice implied across the book is to ask why the failure shape is emerging right now, not only to label it.
“Why” should cover at least three angles:
- Why the current mechanisms do not produce the intended learning or value,
- Why the organization is being forced into local optimization, and
- Why the architectural or economic boundaries are failing to protect the important invariants.
Don’t use this as a checklist!
Common sense also means resisting the temptation to treat anti-patterns as checklists that fully replace judgement. Instead, anti-patterns should be used to narrow the search space and trigger targeted questions that expose the underlying mismatch between goal and mechanism.
Conclusion
These three anti-patterns come from different parts of the book, yet they share a single diagnostic core: breakdowns happen when what the organization measures, exposes, or learns is not the same thing the system needs to evolve.
When we use anti-patterns for what they are best at doing, we get a faster path to the real question: which mechanism is missing or miswired, and what boundary needs to be made explicit so Product Velocity can remain sustainable.
English
German