Reading Time: 4 minutes

How To Kill Your Product Best — 6 Product Delivery Anti-Patterns

Main Takeaways

Reading Time: 4 minutes You can sabotage your product delivery by focusing on customer/user feedback over product vision, by changing given requirements or by adding new requirements too often. In delivering a product there are six well-known anti-patterns: Product Death Cycle, Product Build Trap, Feature Hell, Experience Rot, Scope Creep, and Feature Creep.

Product Death Cycle and Product Build Trap

The Product Death Cycle was first described in a tweet by David J. Bland, a management consultant based in San Francisco. The Product Death Cycle is the failure mode where a Team making a B2B, or B2C Product focuses on Customer/User feedback over Product Vision (Bland 2014).

There is no Product Vision or Product Strategy.
The Product Manager forgets about the “Why” and becomes a kind of steward for Customers, Users, and Stakeholders.
To please everyone, the Product Manager collects and waterfalls all the requirements to the Team.
Features shipped in a hurry do not solve anyone’s problems and do not drive the expected business results.
The Team is under high pressure and cuts corners, compromising the quality.

The Death of the Product becomes a real risky possibility.

Product Build Trap

The Product Build Trap was first described by Melissa Perri. It happens “when organizations measure their success by Outputs rather than Outcomes!” (Perri 2014, 2018).

The reason for the Build Trap is that our first ideas are not always the best. When we immediately jump into build mode, we don't have much information on how our Customers will respond to our Products, what they would want to do with them, or if the Products even solve a problem. Our design or Product decisions are not based on facts, but on our best guesses. And most of those guesses are wrong.

“The Build Trap is when organizations become stuck measuring their success by Outputs rather than Outcomes. It’s when they focus more on shipping and developing Features rather than on the actual Value those things produce.

Companies can get out of the Build Trap by setting themselves up to develop intentional and robust Product management practices […] to maximize business and Customer Value.”

– (Perri 2018)

Product Death Cycle and Product Build Trap happen when the Product focuses on Customer/User feedback more than on Product Vision, and success is measured by Outputs rather than Outcomes.

A lot of companies are building Feature after Feature, without stopping to validate what Customers truly want and need.
Instead of measuring the Customer/User Value, companies tend to place proxies there.
It’s wrong to think that the faster we code, the more money we make.
It’s wrong to think that the more Features we deliver, the more the Customer/User likes what we make.
Our Products become a hodgepodge of Complexity.
The Death of the Product becomes a real risky possibility.

Feature Hell and Experience Rot

When we start to develop a new Product, the Team starts with a certain amount of Features for which they have evidence to hold them as being essential for successful Product Usage, feedback, and market fit. Then the Team releases the first version 1.0 as a minimum viable Product (MVP).

With feedback from real Customers, the Product evolves more and more over time. At a certain time, the number of Features grows so much that the Complexity of the Product exceeds a certain critical threshold.

In the end, the Complexity is so high that it is hard for the Users to understand the Product. At this point, a once great User Experience from the beginning is rotten to a point where it is hard for the User to actually know and use all the Features.

This Experience Rot is bad for as well existing Users as new Users. Existing Users won't use the new Features and will stick to the old known essential ones instead. And the new Users first need to figure out which basic essential Features they need and where to find them.

But the Complexity is not only a problem for the Users. It is also extremely hard for the Product Development Team as well. Maintaining, extending, and innovating the Product becomes harder and harder.

With every new Feature, new demands on the Product Architecture rise up, probably not considered from the beginning. These demands stress the Architecture to the consequence, that Technical Debt builds up and the need for Refactoring increases. In consequence, for every change, the development and release time get longer and longer. — Welcome to the Feature Hell. — And, have more fun, Dependencies aren't counting in here!

Scope Creep and Feature Creep

Scope Creep and Feature Creep are two terms often used for changing given and adding new requirements (i.e. Features). The Team starts with an initial Product Vision and a core set of Features identified (MVP). It bundles these Features into an MVP and starts developing them.

But over time the Team, the Product Owner, and the Stakeholders come up with new Ideas for small changes or small additional Features. And as they go along with them, they shift the Scope more and more.

This happens often unnoticed by the Team. Scope Creep leads to a delay in the Product release timing and increases the cycle time of Features and releases. This increases the risk and the costs of Product Development. In the worst case, the identified core Features are extended so much with added functionality that the Product is getting harder to use.