On Monday, August 30, 2010, visitors to Digg encountered a strange sight. The front page of one of the internet’s most influential news sites was filling up with links to Reddit, its smaller rival.
This wasn’t an advertising campaign. Digg’s own users were doing it.
Five days earlier, Digg had rolled out the biggest redesign in its history. For years, its promise had been simple: anyone could submit a story, and the community could vote the best ones to the top. Digg had turned that idea into a phenomenon. In August 2010, it drew 18.4 million visitors worldwide.
The redesign was supposed to secure its future. The company wanted a more social experience, with greater emphasis on following people and publishers. Instead, familiar features disappeared. The page for discovering upcoming stories was gone. So was the button for burying bad ones. Major publishers seemed to dominate the front page. And the rewritten site arrived with bugs and stability problems.
Users didn’t merely complain. They rebelled.
They began promoting Reddit links on Digg itself. Soon, visitors looking for the day’s most interesting stories were being directed out of Digg and into its competitor. The mechanism that had made Digg powerful — its community deciding what deserved attention — was now being used against it.
At Reddit’s small San Francisco office, its six-person team was watching traffic climb. Before Digg’s relaunch, Reddit averaged about 600,000 daily unique visitors. Within days, it was seeing around 900,000. Engineers scrambled to keep up.
The following month, Digg’s audience collapsed. According to comScore, worldwide monthly visitors fell from 18.4 million in August to 12.8 million in September. Page views dropped 70%.
Digg had been losing momentum before the redesign, and not everyone who left went to Reddit. But the episode revealed something extraordinary: years of customer loyalty could unravel in a matter of weeks when the experience people depended on stopped working the way they expected.
Today, Reddit has over 1.3B monthly active users. Digg is struggling to survive after a 2026 relaunch.
That kind of sudden collapse is rare. Much more often, poor quality erodes a product in slow motion.
Consider Internet Explorer. In 2008, Microsoft’s browser accounted for roughly 70% of worldwide browser usage. Google launched Chrome with a different obsession: speed and stability. It even separated tabs into processes so one crashing page wouldn’t bring down the whole browser. Month by month, the balance shifted. By May 2012, Chrome had overtaken Internet Explorer globally.
Or consider Skype. Once so ubiquitous that its name became a verb, Skype grew cluttered and unreliable as Microsoft piled on new features. Zoom concentrated on making the video call itself simple and dependable. When the pandemic arrived, that difference suddenly mattered to everyone.
Zoom had made an unusual choice before COVID: it routinely maintained network capacity about 50% above its peak usage. Most of the time, that extra capacity wasn’t needed. Then demand exploded. Zoom expanded rapidly through its own infrastructure and the cloud, growing from 10 million daily meeting participants in December 2019 to 300 million by April 2020.
That choice reflected a culture built long before the crisis: reliability is worth investing in even if you can’t see the payoff yet.
Quality is your product’s most important feature.
Join the Top 1% Builder Series on Fridays
The Top 1% Builder Series is a free 12-part live workshop series (one week per competency) with Ravi for product managers, leaders, founders, designers, engineers, and builders who want to ship products customers love — with AI amplifying the judgment they already have. Live attendance is free. This week, on Friday, October 23, we’ll dive deep into Product Quality. Replays and slides are available to paid Top 1% Builder Club members.
Join the Top 1% Builder Series →
How to build remarkable products
As more people build products, the skills to do that well are becoming increasingly important. We can think about the job of building remarkable products as 12 competencies organized into four areas:
Product Execution — getting the right product built well
Customer Insight — understanding the people you build for
Product Strategy — choosing the outcomes that matter
Influencing People — rallying people around the org to make it so
Over the last couple of weeks we’ve discussed the first two competencies of Product Execution. The best product builders strive to execute flawlessly — they know there’s enough risk deciding what to build. Once we make that decision, we have to make it count.
Today, we’re diving into Product Quality, which I believe is both the most important and most overlooked part of executing flawlessly. In the rush to add more features, it’s easy to forget that your users count on what you’ve already delivered to them. They spend very little time thinking about your roadmap.
Product Quality, defined
The ability to set the quality bar, continuously evaluate against it, and maintain technical, functional, and business quality throughout a product’s life across all relevant platforms, markets, and use cases.
Four parts of that definition matter:
Set the quality bar. Make quality a priority and be explicit about what good looks like. Surprisingly few companies do this. OKRs and roadmap commitments have a seat at the table; quality often doesn’t. Without a clear standard, it gets quietly deprioritized whenever something more urgent comes along.
Continuously evaluate against it. A product that meets the bar at launch won’t necessarily stay there. New features can break existing experiences, and performance can degrade as usage grows. AI-powered features can drift as models, data, and customer behavior change. Maintaining quality means continually evaluating the experience against the standard — and treating any gap as work to do, not something to revisit at the next launch.
Technical, functional, and business quality. “The code works” is not good enough. Technical quality means the product is stable, responsive, and reliable. Functional quality means people can accomplish what they came to do — without confusing flows or workarounds. Business quality means the product delivers the outcomes it exists to create. A checkout can run without errors and still lose customers because it’s difficult to use. Define quality from the customer’s perspective, then measure its consequences through outcomes such as conversion, retention, and support demand.
Across all relevant platforms, markets, and use cases. Quality has to apply to everyone the product serves, not just the people whose experience resembles our own. A fast connection and a recent iPhone don’t tell us how the product works on an older Android device, in another language, or with a screen reader. The bar needs to hold across the devices, conditions, and needs customers actually bring.
Quality is not a launch checklist. It is a commitment to the people who rely on what we’ve built.
How Product Quality evolves with AI
Last week, we discussed how AI gives teams more room to refine what they build. That capacity also creates a temptation: keep adding functionality. Teams can now ship features faster than they can understand how those features affect the rest of the product.
The pace of building has increased. Our ability to protect quality has to keep up.
That challenge applies to every product built with AI assistance. When AI is part of the customer experience itself, the meaning of quality changes, too.
Traditional software gives teams a relatively bounded set of paths to test. A customer clicks a button, submits a form, or chooses from a menu. There are still plenty of ways for things to go wrong, but the team has defined the interactions.
A natural-language interface opens that up. Customers can ask for the same thing in hundreds of ways, combine requests the team never considered, or bring an unexpected language or context.
The output varies, too. An AI feature can work beautifully for one person and fail for another — even when both use it as intended.
A successful walkthrough isn’t enough. How often does the feature produce a useful result? Which mistakes are tolerable, and which destroy trust?
We need to understand the range of experiences customers receive, not just prove that a good experience is possible.
AI quality can also deteriorate without a code release. Models change. Information becomes outdated. Customer behavior and expectations shift. The product still responds, but its answers become less useful.
Customers rarely announce that they’ve lost faith in a feature. They work around it.
They double-check its answers. Repeat steps that didn’t land. Go back to the spreadsheet it was supposed to replace. Eventually, they stop using it altogether.
They’re quietly quitting your feature. No bug report. No angry email. Just fewer chances to earn back their trust.
That’s why evaluation has to look beyond whether the feature works as designed. Are customers accomplishing what they came to do, or finding workarounds? Are they relying on it for more of their work, or less? Are they finding new ways to use it, or getting less from it than you intended?
Your feature can keep working long after your customers have given up on it.
How it feels to master Product Quality
When you master Product Quality, you feel confident not because you expect a flawless product, but because you have a rigorous system for finding, prioritizing, resolving, and preventing quality problems.
Your team knows what good looks like, and quality has a seat at the table alongside OKRs and roadmap commitments.
Your product is as bulletproof as possible. It handles the expected use cases reliably and responds gracefully when customers do something your team did not anticipate. Problems do not block the customer from getting value. When something cannot work, the product sets clear expectations, provides a safe fallback, and helps the customer recover.
You hold the same quality bar for every customer — across devices, geographies, languages, accessibility needs, and patterns of use. You look beyond aggregate performance to find customers receiving a materially worse experience.
Most importantly, you treat quality as a living system rather than a launch checkpoint. You have feedback loops that show how the product performs in the real world — including where customers work around it rather than report a problem. You detect deterioration early and turn each failure into a stronger test, guardrail, or product decision.
Product Quality from APM to CPO
All 12 competencies matter at every level, but what excellence looks like changes as your scope grows. As you get more senior, your scope evolves:
Product managers build products.
Product leaders build the teams that build products.
Product executives build the systems that build the teams that build products.
As an APM, you test smaller product improvements across relevant platforms, markets, and use cases. You learn to distinguish an inconvenience from a launch blocker, explain the risk, and make a clear recommendation. You follow problems through to a complete fix rather than considering the work done when a bug is filed.
As a PM, you take on larger improvements and look for failures created by interactions across features. You bring in the right partners to assess complex or risky work, organizing broader bug hunts or reviews when needed. For AI features, you use representative inputs and evaluation cases to assess quality before and after release. You monitor the live experience and make sure customers can recover when something goes wrong.
Senior and Principal PMs take greater responsibility for defining what good enough means for customers and the business. For AI features, that means setting an acceptable performance range across inputs and contexts rather than treating quality as a binary pass or fail. You judge the severity and potential exposure of failures, then use that evidence to decide what can ship. When the product falls below the agreed bar, you reduce scope or change the launch plan — not quietly lower the standard.
When you manage a team, your responsibility expands beyond the quality of your own work. You coach PMs to exercise that judgment, mobilize expert partners, and build quality checks into planning, development, and release. People know who monitors quality after launch and who takes responsibility when something goes wrong.
At Director and Senior Director levels, you make those practices repeatable across teams. Shared expectations need shared support: the people, tools, and infrastructure for testing and AI evals. You build a culture where teams take pride in quality, raise problems early, and have time to fix them. You also connect quality investment to the company’s strategic goals, customer trust, and ability to move quickly.
At the executive level — VP or CPO — technical, functional, and business quality become an organizational standard. You establish clear accountability for sustaining it, including AI trustworthiness. Quality cannot depend on which team a customer happens to encounter or which leader happens to care most.
A quality-first culture is not what leaders say about quality. It is what they fund, what they reward, and what they refuse to ship.
That wraps up our three Product Execution competencies: Product Definition, Product Delivery, and Product Quality. Together, these competencies enable us to execute flawlessly. But we have to know what to build in the first place.
Next week: Fluency with Data, the first of our Customer Insight competencies.
Dive deeper into Product Quality
The free Product Competency Toolkit dives deep into the 12 competencies that turn good product builders into remarkable ones. Updated entirely for the AI era, it explains how each competency is evolving — whether you want to improve your own craft, coach your team, or help your entire organization level up.
It’s for anyone building products across product, design, engineering, marketing, leadership, or a venture of their own.
Get the Product Competency Toolkit →