7 Ways to Build an Awful Product (So You Can Avoid Them)
No product manager sets out to build a bad product. And yet the graveyard of failed products — features nobody uses, products nobody wants, launches that fell flat — is enormous and continuously populated with the efforts of capable, well-intentioned people.
Most bad products don’t fail for dramatic reasons. They fail for predictable, preventable reasons that experienced product managers have seen play out many times. Understanding these patterns — and recognizing them before they produce bad products rather than after — is one of the most practically valuable things a product manager can learn.
Way 1: Build What’s Easy to Measure, Not What Matters
When the metrics you’re measuring don’t capture the value users actually care about, you optimize for the metric rather than the value. Products that optimize for page views, download counts, or other vanity metrics at the expense of genuine user value are being driven in the wrong direction by the instruments they’re using to navigate.
The fix is starting with the outcomes users care about — the changes in their lives the product is supposed to create — and building measurement that captures those outcomes, not just the activities that correlate with them.
Way 2: Prioritize by Who Asks, Not by What Matters
When the most recent request, the loudest stakeholder, or the most valuable customer drives the roadmap regardless of how well those requests serve the broader user base and business strategy, the product becomes a collection of customizations rather than a coherent platform.
The fix is a principled prioritization framework that evaluates all requests against the same criteria — user impact, business value, strategic alignment — regardless of their source.
Way 3: Skip the Discovery Phase
Building features before validating the underlying problem is the most reliable way to waste development capacity. The majority of product failures are failures of product-market fit — the product doesn’t create enough value to justify adoption — not failures of execution.
The fix is treating discovery as non-negotiable: validating that the problem is real, significant, and widely shared before committing engineering resources to building a solution.
Way 4: Design by Committee
Products designed to satisfy every stakeholder’s preference end up with the coherence of a product designed by no one with a clear vision. Compromises between genuinely different perspectives produce neither perspective’s benefits.
The fix is recognizing that design leadership requires genuine authority — not veto power over everyone else’s input, but the responsibility for making coherent choices that reflect a considered point of view rather than the average of all stakeholders’ preferences.
Way 5: Treat the Launch as the Finish Line
Teams that celebrate shipping a feature and immediately move to the next initiative never learn whether the feature created the value it was supposed to create. Without post-launch measurement, the feedback loop that should improve future product decisions is broken.
The fix is treating launch as the beginning of the learning cycle rather than the end of the development cycle, with pre-defined metrics and post-launch measurement commitments built into every significant feature investment.
Way 6: Build Features, Not Outcomes
A product roadmap full of feature descriptions doesn’t answer the most important question: what will change for users when these features exist? Products built without outcome orientation often ship features that are technically complete but fail to create the user value they were intended to create.
The fix is defining every major product investment in terms of the user outcome it’s designed to create, and measuring whether that outcome was achieved.
Way 7: Confuse Motion with Progress
Teams that are busy building aren’t necessarily building the right things. High development velocity directed at low-value features is not product progress; it’s the efficient production of waste.
The fix is deliberately evaluating whether each development cycle’s output is moving the product’s strategic objectives forward — not just measuring whether the sprint was completed on time.
Key Takeaways
Bad products are built through predictable patterns that can be identified and corrected before they produce their characteristic failures. The common thread across all seven: the absence of genuine user outcome orientation, principled decision-making, and systematic learning from what was built. Product managers who recognize these patterns in their own organizations are positioned to change them before they produce the next feature nobody uses.