Relentless Improvement How to Move the Needle on Existing Products

Are you falling into the trap of adding more features to your software while your business metrics stay flat? For many teams, success is measured by how much code they ship, but true growth relies on improving product performance through focused optimization. Most software companies act as feature factories, relentlessly churning out new capabilities that users never actually use or value. This cycle leads to bloated, complex products that alienate the core audience and fail to drive revenue.

Marty Cagan, in his seminal work Inspired: How to Create Products Customers Love, argues that the best product teams spend as much time optimizing what they have as they do building what's new. They don't just guess what might work; they use hard data to find where users are struggling. By shifting focus from feature volume to business outcomes, you can turn an underperforming asset into a market leader.

Reframing Product Growth

Product optimization is the process of analyzing how users interact with an existing product and making targeted changes to improve business results. Marty Cagan explains that this is a core responsibility of the product manager, especially once a product has found its initial market fit. It requires moving away from the mindset of "more is better" and adopting a disciplined approach to metric-driven development.

In Inspired, Cagan highlights that the majority of product releases fail to meet their objectives, with industry experts claiming that as many as 9 out of 10 releases are unsuccessful. This failure usually happens because teams build solutions without a clear understanding of the problem. Real improvement comes from identifying a specific bottleneck—like a low conversion rate—and relentlessly testing ideas until that metric moves in the right direction.

Winning the Outcome War

Eliminate the Feature Factory Mentality

Many organizations suffer because they view their roadmap as a checklist of features rather than a list of problems to solve. They assume that if they just add that one missing feature requested by a vocal customer, the product will finally succeed. This approach ignores the reality that every added feature increases complexity and support costs.

Instead of prioritizing features, focus on business objectives like retention, churn, or lifetime value. Cagan suggests that every project should start with a clear value proposition and a measurable way to track success. If a proposed change doesn't directly contribute to a key business metric, it likely isn't worth the engineering effort.

Data Mining for Improving Product Performance

You can't improve what you don't measure. High-performing teams use site analytics and data mining to see exactly where users drop off in a process. For example, if you see that 100 people start a subscription flow but only 9 finish it, you've identified a clear opportunity for optimization.

Marty Cagan notes that improving product performance often yields a much higher return on investment than building a new 1.0 product from scratch. Doubling your conversion rate from 7% to 14% effectively doubles your revenue without increasing your marketing spend. This is the power of focusing on the "numbers" rather than the "new."

Dedicate Headroom for Continuous Refactoring

Existing products often slow down because of technical debt and infrastructure limitations. Cagan recommends a specific strategy used at companies like eBay: allocate 20% of your engineering capacity to "headroom." This isn't for new features; it's for rewrites, re-architecting, and performance improvements that prevent the system from collapsing as it grows.

If you ignore this 20% tax, you'll eventually hit a wall where the code base becomes unmanageable. Many startups fail because they neglect their infrastructure until it's too late, forcing a total rewrite that kills their market momentum. Consistent investment in the "engine" allows you to stay nimble and respond to user needs faster than the competition.

Improving Product Performance through Rapid Response

The work doesn't end when the code is deployed. High-growth teams utilize a "rapid response" phase immediately following a launch to fix issues based on live user data. Instead of moving the engineers to a new project the next day, keep them focused on the current release for at least a week to address friction points discovered by real customers.

This phase allows you to respond to site analytics in near-real-time. By observing where users stumble during the first few days of a release, you can push "hot fixes" that save an entire release cycle. This proactive approach builds trust with your community and ensures that your optimization efforts actually reach their goals.

Optimization in Action

The Online Insurance Conversion Win

A classic example of metric-driven improvement involves an online insurance provider struggling with low application completion rates. The team didn't add more types of insurance; instead, they analyzed the data to find where users quit. They discovered that users were hesitant to provide personal information early in the process without knowing why it was needed.

By prototyping different layouts and being transparent about data use, they tested their way to a solution. Through several iterations of the user experience, they drove the completion rate from 7% to 15%. This shift didn't require revolutionary technology, just a relentless focus on moving a specific needle.

eBay's Infrastructure Resilience

In 1999, eBay faced a near-death experience when its infrastructure couldn't keep up with massive transaction growth. The team had to stop all new feature development to focus on a massive re-architecture. They learned that they couldn't just keep adding features to a crumbling foundation.

Following this, they institutionalized the 20% headroom rule, ensuring they were always building for future scale. This allowed them to later migrate their entire site to a new architecture while simultaneously delivering record amounts of new functionality. They proved that investing in the foundation is what actually enables long-term product improvement.

Actions for Improving Your Product Results

1. Audit your current baseline metrics to find the biggest friction point. Don't look at a list of requested features; look at your funnel analytics to see where users are leaving your product in frustration. Pick one metric—like registration completion or checkout speed—and make it your sole focus for the next sprint.

2. Implement a 20% headroom policy with your engineering lead today. Explain that this time is reserved for their choice of refactoring and performance work to ensure the product remains stable as it scales. This move reduces the risk of future system failures and keeps your developers motivated by allowing them to maintain code quality.

3. Schedule a rapid response phase for your next release. Ensure your designers and lead engineers are available for at least three days post-launch to monitor analytics and address user confusion. This allows the team to fix problems immediately while the context is fresh, rather than letting issues linger for months in a backlog.

When Metrics Lead You Astray

While data is a powerful tool, relying solely on quantitative metrics can sometimes blind a team to the underlying "why." You might see that users are dropping off, but the data won't tell you they're confused by the terminology or that the visual design feels untrustworthy. Critics often point out that metric-driven development can lead to local maximums—making small improvements while missing a larger, more innovative path.

Marty Cagan emphasizes that data must be paired with qualitative user testing. If you only look at the numbers, you might optimize a bad experience until it's slightly less bad, rather than discovering a way to eliminate the friction entirely. Balancing hard analytics with direct user observation ensures you're moving the right needle for the right reasons.

Improving product performance requires a shift in focus from what you're building to what you're achieving. High-performing teams use data to identify bottlenecks and utilize their engineering capacity to maintain a strong technical foundation. Identify your most problematic business metric today and start testing prototypes to resolve the underlying user friction.