Case studies play a strange role in product development. Everyone claims to value them, yet most case studies end up as polished success stories, stripped of the very details that would make them useful.
With Product Velocity, I want to treat case studies differently.
The first Product Velocity case studies are now available on the website. They are intentionally small, focused, and structured to make reasoning visible. This is the beginning of a growing library that complements the framework, the book, and future workshops.
In this post, I explain why case studies matter, how they are structured, and how to use them.
Why case studies matter
Product development speed rarely breaks down because teams don’t work hard enough. It breaks down because of mismatched assumptions across business, architecture, engineering, and delivery. These mismatches usually surface late, when change is expensive.
Case studies are one of the few artifacts that can expose these mismatches early. Not by celebrating outcomes, but by showing:
- What problem was actually addressed
- Which constraints mattered
- Which principles were applied
- Where trade-offs were made
The goal of the Product Velocity case studies is not to provide templates or best practices. The goal is to create shared reference points that support better conversations and better decisions.
This is also why the case studies are deliberately compact. Each one focuses on a specific aspect of a product, not the entire system. Read on, or watch the video where I explain the structure, using the Ameru Smart Bin as an example.
A standard structure for all case studies
To make the case studies comparable and searchable, they all follow the same structure.
Each case study starts with a header that provides immediate context:
- Title of the case study (e.g., Smart Bin Universal Interface)
- Company (e.g., Ameru)
- The Product (e.g., Smart Bin)
- Specific subsystem (e.g., Universal Mount)
- Primary benefit or outcome (e.g., Tool-Free Field Replacement, Future-Proof)
This allows readers to quickly decide whether a case study is relevant to their current question.
Next, each case study lists the applicable Product Velocity principles. Not all principles apply to every situation, and that is intentional. Making this explicit avoids the illusion that everything matters equally all the time.
In the same way, each case study lists the relevant elements of the Velocity Loop. This makes clear whether the example is primarily about business decisions, system stewardship, engineering work, delivery practices, or the interactions between them.
Finally, each case study includes a visual reference, typically a picture of the product or a specific product part. This is not decoration. It anchors the discussion in a concrete system and avoids abstract explanations detached from physical reality.
How case studies fit into the book
Book space is limited. Even in a comprehensive book, it is not possible to fully document complex products without losing focus.
For this reason, the book references case studies only where they support a specific argument. In the book, we usually look at a specific topic in detail, like interface design. The book focuses on the theory, providing short references to the case study in example boxes. The case studies themselves live on the web site.
This keeps the book readable while allowing the online case study library to grow independently and evolve over time.
A browsable library, not a linear list
The case study library is designed to be explored from different angles. For navigation, all case studies are tagged with the applicable principles, which are:
- Value Thinking Value Thinking
- Architect for Flow Architect for Flow
- Shift Left Shift Left
- Accelerate Accelerate
These tags are linked and lead to pages listing all case studies with the respective principle. Likewise, you will find tags for the Velocity Loops Business Business, System Stewardship System Stewardship, Engineering Engineering and Delivery Delivery, as well as the respective areas of the loop. These are also included in the text, allowing you to quickly find the relevant text passage.
More to come
Over time, this creates a network of examples rather than a static collection. As of this writing, three case studies are available, but more are planned.
Each case study is intentionally small and fits on a single page. Larger products will be represented by multiple case studies, each focusing on a different aspect, decision, or constraint.
New case studies will be added incrementally. The library is meant to grow organically, informed by real projects rather than a predefined catalog.
Conclusion
Product Velocity is not a checklist. It is a way of reasoning about complex products under real constraints.
The case studies are a key part of that reasoning. They provide concrete anchors for abstract principles and make trade-offs explicit.
The first case studies are now live. They are an invitation to explore, compare, and question how velocity is created—or destroyed—in real products.
English
German