Why Beautiful Products Fail

The hard part isn't building quality—it's finding quality problems worth solving

In 2009, Google Wave became Twitter's top trending technology topic. The demo was mesmerizing—real-time collaboration that made email look ancient, an interface that was genuinely innovative, features that no other product offered. Tech reviewers called it revolutionary. Millions wanted invitations to try it.

Less than two years later, Google shut it down. Despite giving out 100,000 invitations, only 27,000 people were actually using it. Twitter filled with "Got Google Wave—now what?" memes as confused users tried to figure out what to do with this supposedly amazing product.

Google Wave had beautiful design. It had cutting-edge features. It had technical sophistication that impressed engineers. The execution was flawless by every traditional metric. But it was a false positive—something that looked like quality but wasn't.

---

If you only have 5 minutes: here are the key points

• Selection beats execution. Most products fail because they chase the wrong problem, not because the code or design is bad.

• Four foundations filter false positives. (1) Ultimate vs proximate goals (2) Study existing workflows (3) Embrace convergence (4) Buyer reality check.

• AI makes “looking polished” cheap. When anyone can ship beautiful software, judgment about what to build is the last moat.

• False positives are deadly**.** They burn months of talent and morale on sophisticated features no one uses.

• Quality = willingness to sacrifice. If users won’t pay—or at least trade time/attention—you haven’t found real quality.

---

We're solving the wrong quality problem

Most people think the hard part of product development is building high quality products. They obsess over code quality, design systems, user research methodologies, agile processes. Engineering teams debate technical architecture for weeks. Design teams conduct endless usability studies. Product teams create elaborate roadmaps with detailed acceptance criteria.

That's completely backwards.

After managing data platforms for 700+ users at Unite and building AI tools that people actually pay for at MAIA, I've learned something counterintuitive: quality is 90% determined before you write a single line of code. The hard part isn't building well—it's finding high quality problems worth solving and matching them to solution ideas that actually work.

Most "quality" failures happen in the selection phase, not the execution phase. Google Wave failed because they selected the wrong problem to solve, not because they executed poorly. They built a beautiful solution to a problem nobody actually had.

This distinction matters more than ever. AI is making building products easier than ever. GitHub Copilot writes code. Figma generates interfaces. ChatGPT drafts copy. The barrier to creating something that looks professional has collapsed to nearly zero. In a year, you won't be able to walk out your door without stumbling over 100 competitors with beautiful, well-executed products.

When anyone can build something that looks good, quality becomes the only defensible difference. But not quality as we traditionally measure it—quality in problem selection and solution matching. Quality that users will actually sacrifice for.

The real problem with product quality isn't that we don't care about it—everyone claims they're building quality products. The problem is we're terrible at avoiding false positives: things that LOOK high quality but aren't. We mistake beautiful design for quality. We confuse feature completeness for quality. We think customer satisfaction equals quality.

"It's not worth it to do things of non high-quality. And yet, it is rare to find companies that do focus on quality." - Karri Saarinen, CEO of Linear App.

These false positives are expensive. Google spent 18 months and millions of dollars on Wave before admitting failure. But the cost isn't just money—it's opportunity. While Wave's team built beautiful, sophisticated features nobody wanted, competitors were building ugly, simple tools that users actually adopted.

I've seen this pattern destroy teams and startups alike. Engineers spend months perfecting elegant solutions that get ignored. Designers create beautiful interfaces that confuse users. Product managers build comprehensive feature sets that overwhelm rather than help. The work is high quality by every traditional metric, yet it fails completely.

This is my framework for ensuring the things I build are HIGH quality. Yes, I might miss some high quality products this way, but I avoid tons of false positives. And in product development, false positives kill you. They waste months of development time, drain team morale, and leave you with features that impress in demos but die in real usage.

(My) quality products are determined by four foundations that filter out those false positives:

Foundation 1: Ultimate vs proximate goals

In investing, there's the concept of ultimate drivers of business success versus proximate drivers. Proximate drivers influence short-term price changes—sudden shocks, news, market sentiment. Ultimate drivers are the business fundamentals that determine long-term value. Smart investors use short-term volatility to buy businesses with strong fundamentals at decent prices.

The same idea applies to product management. We have to do everything to ignore and cast away proximate influences when evaluating a product idea. There's a simple test for this:

Testing the fundamentals of a product idea:

• Do: Ask "Would someone cancel their day to solve this problem?"

• Pursue: Product ideas that solve ultimate human goals, not workflow steps

• Ditch: Features that optimize for proximate goals while ignoring fundamental needs

Jeff Weinstein, Product lead at Stripe, puts it perfectly: "I got it wrong for a decade in a row where I would build software for myself or friends that wasn't motivated out of any reason but it was motivated out of 'hey wouldn't it be cool if.'" He learned to focus on problems "big enough where you would cancel the rest of your day to solve."

At MAIA, one of the first features I built was a "select all" button. MAIA is an AI knowledge management tool, and theoretically, the more specific you are about what you want to know, the more accurate the answer. So there is a conflict here. The proximate goal suggested precision—make users select exactly what they need. But the fundamental goal? Nobody actually wants to do extra steps if they can get their answers without them.

We built the feature. Users love it. And we're still chasing the ultimate goal: getting accurate answers with zero selection required. That's the difference between optimizing for the workflow step (selection) versus the human goal (answers).

When Linear's Karri Saarinen started the company, he could have built another project management tool with beautiful interfaces and comprehensive features. Instead, he focused on one thing: "issue tracking you love using." Not issue tracking that looks amazing, not issue tracking with every feature imaginable. Issue tracking that developers actually want to use daily. Linear is a beautiful product, but that's a consequence, not the foundation.

Notes on actually executing this:

Distinguishing ultimate from proximate goals is brutally difficult in practice. Every proximate goal can be disguised as fundamental. "Improve user engagement" sounds like it serves users, but it's often optimizing for metrics rather than human needs. The trap is that proximate goals feel more actionable and measurable.

The select all button gave me quite a bit of stomach pain in discovery. The product logic seemed obvious: more specificity = better answers.

The hardest part is that proximate goals often have passionate advocates. Engineers love technical elegance. Designers love interface beauty. Product managers love feature completeness. But none of these correlate with solving fundamental human problems. You have to be willing to disappoint internal stakeholders to serve actual users.

Foundation 2: Study existing workflows extensively

There is nothing new under the sun, literally. Great investors hunt for patterns, for business frameworks that have worked in the past and are now being applied to new sectors, new technologies. Even VCs don't really invest in new things—they look for proven patterns in new contexts. You should too! Great products solve something that users are already doing, not something they "wish to do."

Test for actual workflows:

• Do: Watch what users actually do (painfully) by hand

• Pursue: Product ideas that automate/simplify existing behaviors

• Ditch: "Wouldn't it be cool if" features that force new workflows

This foundation eliminates the biggest false positive in product development: building elegant solutions to non-problems.

A big breakthrough feature I built at MAIA is called the "High Precision Mode." I don’t know of any other knowledge management tools that have anything like this. Its goal is to cut down the users time in verifying and answer after it is generated. The system double-checks its own answers by pulling 1-1 quotes from source documents, then validates assumptions based on those quotes. Seems like random extra work, right?

But it isn't random at all. If you upload a document to ChatGPT and ask a question, have you ever found yourself double-checking the answer against the original document? Of course you have, in certain situations you simply need to double check (if it is important what is said 1-1 in the doc). I do that often with web sources I would like to cite for an article.

We studied this painful existing workflow extensively before building anything. Users were already performing manual precision checks. We just automated what they were doing anyway.

Karri Saarinen describes Linear's approach: "we went out there and asked our friends or people in the industry... what are you doing, what are the problems?" Not "what features do you want?" but "what are you already doing?"

Weinstein emphasizes the same principle at Stripe. Before building business formation tools, they studied existing painful workflows: companies struggling with legal setup for VC meetings, founders spending weeks on paperwork that should take hours. They built automation around workflows that already existed and were already painful.

Notes on actually executing this:

Studying existing workflows extensively sounds simple until you try it. The temptation is to ask users what they want—they'll give you their wished-for ideal state, not their painful reality. You have to become obsessive about watching what people actually do when they think nobody's watching.

I am spending hours and hours every single week observing users interact with the products I build. I observe them in their workflows at their workplace. At Unite, I went out and visited my customers and watched them go about their day. I spend time in Communities of Practice for our customers (not run by us) to understand their pains, their day to day work.

And most of the time, nothing comes out of it, other than a deep understand for our customers day to day.

This foundation requires patience that most product teams don't have. Watching real workflows is slow and often boring. It's much more exciting to brainstorm innovative features than to study mundane user behaviors, and their workday. But those mundane behaviors reveal the problems actually worth solving.

Foundation 3: Embrace convergence

In business as in user interactions, new things suck. Nobody knows how to use them. There is such a thing as convergence—convergence on standards, practices, workflows. Look for product ideas that thrive on existing convergence, don't try to break it.

Testing for convergence:

• Do: Meet users where they are + follow successful patterns

• Pursue: Product ideas that improve existing solutions dramatically

• Ditch: "Revolutionary" approaches that fight human nature

This foundation filters out the most seductive false positive: the breakthrough innovation that nobody adopts.

The third ever feature I built at MAIA was subfolder support for document uploads. Why would that be anything to talk about? Well, most users at the moment upload data manually to MAIA. Adding subfolders means letting them dump thousands of files into our system in whatever folder structure they want. Of course this means more irrelevant data will be in our systems, and thus answer quality will on average get worse slightly, until we optimize the system again.

But here's the reality: humans live in folders. It's how we organize information on every device we use. Why would we force people to copy and flatten folder structures for 15+ minutes when we could simply support the organizational pattern they already use everywhere else?

As former Twitter CEO Dirk Costolo notes: products should work "the way people want to do these things" rather than forcing new workflows. He points to Figma: "let's just design it here and then it does it the way we designed it." Instead of requiring users to adapt to the product, the product adapts to how users already work.

Costolo elaborates: "Products that work that way instead of you having to pound a square peg into a round hole are the new wave... I think of things like Notion and Figma and Linear instead of like I've got to do all this process work to fit to the product and then move it over to the way I work—you just, the product works the way you work."

Linear exemplifies convergence. Issue tracking wasn't a new category—tools like Jira had existed for decades. But Karri didn't try to revolutionize issue tracking. He converged on the existing pattern while making it dramatically better: "issue tracking you love using." Classic convergence—take something that works but sucks, and make it excellent.

SpaceX provides another example. Weinstein notes: "everyone was complaining about people who needed to put things in space seemed to complain about the cost of going to space and the safety of it." SpaceX didn't invent space travel—they made the existing pattern (rockets) dramatically better through reusability.

Notes on actually executing this:

Embracing convergence feels like giving up on innovation, which makes it psychologically difficult for most product teams. There's tremendous internal pressure to be "revolutionary" and "disruptive." Investors ask about your "defensible moat." Engineers want to build something technically novel.

The subfolder support felt like surrendering to user chaos. I had elegant ideas about how document organization should work in an AI system. Surely we could teach users a better way?

But convergence isn't about being unambitious—it's about being strategic. When you converge on existing patterns, you eliminate friction that kills adoption. Users don't have to learn new workflows, change existing habits, or convince their teams to adopt unfamiliar processes.

The hardest part is distinguishing between patterns worth preserving and patterns worth improving. Not all existing workflows deserve convergence—some are genuinely broken. The key is identifying which patterns users are deeply attached to versus which they'd happily abandon for something better.

Revolutionary approaches feel more exciting in product meetings, but convergent approaches actually get adopted. When you fight human nature or established patterns, you're betting that your solution is so dramatically superior that users will change fundamental behaviors. That's a losing bet most of the time.

Foundation 4: Buyer reality check

At the end of the day, we're all in the business of money. If people don't pay for your product, it's not a high quality product. Payment isn't always currency—time and attention are equally valid forms of payment. But there must be some sacrifice that proves real value.

Test for buyer's willingness to pay:

• Do: Validate what people will actually pay for your new idea/feature with time/money/attention

• Pursue: Product ideas with clear economic value

• Ditch: Features people admire but won't sacrifice for

This foundation eliminates the most persistent false positive: features that generate praise but no actual usage.

When I was Product Manager at Unite, managing the data platform for 700 employees, I wanted to switch from our existing BI tool to Tableau. This required finding an additional $100,000 in budget. That money had to come from other departments giving up their budget allocations to fund our platform upgrade.

That took serious convincing. But it was easy because Tableau solved their problem #1, not problem #38. Weinstein is crystal clear about this: "customers are smart, they have a lot of alternatives in the world, and so they will pay for things that solve their problem and they tend not to pay a lot of money when you solve problem 38 that they have. They tend to pay a lot of money and love the software that solves problem one or two."

The departments at Unite literally paid for using Tableau because it solved fundamental problems they couldn't solve otherwise. That's the buyer reality check in action.

At Arch.dev, the company behind Meltano (the open source data integration framework), I initially obsessed over the UX of the open source, free-to-use version. Why? Nobody was paying for it directly, right? But they were! People were spending tons of time trying to understand the tool, community developers were paying tons of time to fix bugs, create feature requests, and set up Meltano at their companies. UX was paramount in that situation, not an afterthought. People do pay with their time.

Notes on actually executing this:

The buyer reality check is emotionally brutal because it forces you to confront whether people actually value what you're building. Most product teams avoid this test because the answer might be uncomfortable.

The Tableau budget fight at Unite was terrifying because it required me to bet my credibility on whether other departments would sacrifice real money for our platform upgrade. If they'd said no, it would have meant either the upgrade wasn't actually valuable or I'd failed to prove its value. Both options were career-damaging.

But that's exactly why the test works. When people have to sacrifice something real—budget, time, attention—they reveal their true priorities. Users will praise lots of features they'd never actually pay for. Politicians will claim to support policies they'd never vote to fund. Customers will request features they'd never actually use.

The hardest part is defining "payment" broadly enough to be useful but specifically enough to be meaningful. At Arch.dev, recognizing that open source users "pay" with time and attention was crucial. But we had to measure that payment: GitHub stars, community contributions, implementation effort, support forum activity.

Money is the clearest form of payment because it's zero-sum—spending on your solution means not spending on alternatives. But time and attention work similarly when measured correctly. The key is proving that users are making real trade-offs, not just expressing interest.

Quality is a selection problem, not an execution problem

These four foundations filter out the false positives that destroy most product teams. They won't catch every high quality product idea, but they'll save you from building beautiful, well-designed, customer-requested features that nobody actually uses.

The conventional wisdom says quality comes from good execution: clean code, beautiful design, rigorous testing, user research. But that's optimizing for the wrong variable. Google Wave had exceptional execution. So did Google Glass, Microsoft Zune, and countless other beautiful failures.

Quality products win because they solve the right problems with the right solutions, not because they're built perfectly. Linear didn't succeed because of superior engineering—Atlassian has more engineers and bigger budgets. Linear succeeded because Karri identified a problem worth solving (developers hate existing issue tracking) and matched it to a solution worth building (issue tracking you actually want to use).

The selection phase determines 90% of product outcomes. Everything else is execution detail. In a world where AI makes execution easier every day, selection becomes the only sustainable competitive advantage.

When anyone can build something that looks professional, the winners will be those who know which problems are worth solving. That's not a technical skill or a design skill—it's a judgment skill developed through experience, pattern recognition, and systematic application of frameworks like these four foundations.

The future belongs to products that pass these tests: solving ultimate human goals, automating existing painful workflows, embracing user convergence patterns, and creating real economic value. Everything else is just beautiful products that nobody uses.

Further Resources

The company Linear, has a lovely have this lovely series they call “Conversations on Quality.” Guided by Zoe Wellner the company interviewed a ton of great product leaders on the question of what makes or breaks a high quality product. It is amazing how many of those product leaders echo the “selection problem over execution problem” and the stark separation people IMHO have to make between problems and solutions in order to build something truly high quality in the end. I particularly liked the conversations with

• Dick Costolo (ex-CEO of Twitter, but came with Ev from Odio etc. if you ever followed that journey. Has a long history of creating amazing high quality products)

• Karri Saarinen (CEO of Linear)

• Jeff Weinstein (Product at Stripe, if you want to dive deeper into the history of Stripe I recommend the conversation of Patrick Collison with Tim Ferriss - warning it’s a long and deep one.)

• Ethan Eismann (Design at Slack, for more information on how that amazing product came to be, take a look at the Masters of Scale episode with Steward Butterfield)

Finally, since I do believe product should lean much more on existing other fields, in particular on investing, I do recommend “What I learned about investing from Darwin” by Pulak Prasad. It is a great book by one of the few investors who has managed to match Warren Buffets returns over a 20+ period, and still manages to do so. He’s publishing his whole playbook, which as you might imagine is very close to what Warren Buffet does. Now the important thing is, Pulaks main strategy is super simple, it is to “become permanent owners of high quality businesses for a fair price.” The book spends a good third on what “high quality” really means, and is very close to what I described above, and to what Dick, Karri, Jeff and Ethan describe IMHO.