How Products Go Bad (or Never Get Good)

A field guide to the warning signs that kill product quality

No one is trying to build bad products. So why do bad products get built? Why do good products stagnate and deteriorate?

After years of building products across different teams, I've learned to spot the early warning signs. Here's what I watch for when evaluating how well teams build products.

The Team Has Lost Touch With Reality

The team isn't using the product. If you aren't regularly using what you’re building, you are operating blind. You can't feel the friction, the annoyances, and the limitations that your customers feel.

The team doesn't know or understand the customer. When was the last time someone on your team talked to an actual user? Not through analytics dashboards or support tickets, but real conversations.

The team is operating from a place of fiction about product quality. Everyone agrees the product is "pretty good" (or worse “great”) while users are struggling with obvious pain points. This delusion is often reinforced by metrics that don't reflect real user experience.

Be product focused by being customer focused.

Incentives are Broken

Internal milestones and plans are taking precedence over the product experience. When hitting arbitrary deadlines becomes more important than shipping quality, you're optimizing for the wrong outcome.

Career progression is divorced from product quality. It doesn’t matter how much your leadership team says “we want to operate like a startup” or “we want product engineers” - over time, the incentive structures at your company will come to dominate the actions of your people, and your company’s outcomes.

If people get promoted for shipping features regardless of user impact, you've created a system that rewards the wrong behavior.

The product is just a vessel for the team to do their job. "I just write the code" is a red flag. When team members see themselves as isolated contributors rather than product builders, ownership disappears.

Design and User Experience Are Afterthoughts

Design is someone else's problem. Building a feature that is confusing, or integrating it in a poor way should be everyone’s problem. It’s a colossal waste of effort: time and money.

Design is immune from feedback. When design decisions can't be questioned or iterated on based on real user behavior, you get beautiful interfaces that don't work for actual humans.

Copywriting is an afterthought. Words are a huge part of the interface. And people don’t read. The right copy can save hours of engineering work and support costs. It can also drive usage up of your product.

Documentation is deemed unimportant. When you are in the trenches of the product development day in day out, it’s easy to forget that what you see as obvious requires explanation to users.

Good documentation in its many forms (think: videos, tutorials, cheat sheets) is a competitive feature.

The Technical Foundation Is Shaky

Non-functional requirements make or break the product. No one is tracking them. Performance, reliability, and security aren't features—they're the foundation everything else depends on.

There is no cohesive technical direction. If the engineering team keeps re-architecting the product, or jumping to different frameworks to solve problems, you are actually accumulating technical debt instead of paying it down.

Test automation, metrics and ticking boxes have replaced evaluating the product as a user experiences it. Experience is the product.

Organizational Dysfunction Shows Up in the Product

Only some members of the team can give feedback on design. Everyone who builds the product should have a voice in how it works.

Only some members of the team can give feedback on marketing. Engineers and designers often have the deepest product knowledge but are excluded from go-to-market conversations.

Only some members of the team can give input into what is built. When the engineering team is siloed off from the rest of the business, great ideas and insight never make it into the product.

The team is oblivious to the context that the product must operate and compete in. Building in a vacuum leads to products that don't fit their market reality.

Leadership has confused the map for the terrain. Plans, roadmaps, and JIRA tickets are tools for thinking and planning - not reality. You can close all the tickets and still end up with a bad product.

The team is not getting the support required to do good work. Resource constraints aren't just about money—they're about time, tools, and psychological safety to take risks and iterate.

QA and Engineering are at odds with each other—in the wrong way. Healthy tension between quality assurance and development velocity is good. QA and engineering is a partnership dedicated to the same goal: building a great product. Managing this relationship should be a priority and is the responsibility of both teams.

Complacency is Stagnation

The team is resting on their laurels. Past success can be the enemy of future quality. Teams that stop questioning their assumptions stop improving.

Good enough is good enough. There's a difference between strategic trade-offs and settling for mediocrity.

Improvements to product quality are not celebrated. If your team only celebrates new features but never quality improvements, you're training everyone to deprioritize the user experience.

Iteration on product development is too slow. When it takes months to test a simple hypothesis, you lose the ability to respond to user feedback and market changes.

Iteration on product development is too fast/chaotic. The opposite extreme: when everything is always changing, nothing ever gets truly finished or polished.

Foster a Culture of Product Excellence

The best engineers I work with understand that code is just one layer of the product. They think about user problems, business constraints, and team dynamics because they know these forces shape what gets built and how it performs in the real world.

If you're hiring engineers or building teams, look for people who can spot these patterns and care about the entire product.

If you have an existing team, think about how you can counteract some of the forces and attitudes described above. It’s an ongoing process.

None of this is easy - if it was, every software product would be good.