Enough Disruption: Build Better Products

In his recent article, “How Silicon Valley is disrupting democracy,” MIT Technology Review’s Bryan Gardiner writes:

Regulating Big Tech will be a crucial part of leveling the playing field and ensuring that the basic duties of a democracy can be fulfilled. But…another battle may prove even more difficult and contentious. This one involves undoing the flawed logic and cynical, self-serving philosophies that have led us to the point where we are now.

What if we admitted that constant bacchanals of disruption are in fact not all that good for our planet or our brains? What if, instead of “creative destruction,” we started fetishizing stability, and in lieu of putting “dents in the universe,” we refocused our efforts on fixing what’s already broken? What if…we admitted that technology might not be the solution to every problem we face as a society, and that while innovation and technological change can undoubtedly yield societal benefits, they don’t have to be the only measures of economic success and quality of life?

Gardiner is critiquing tech on a philosophical level (and I agree with him). But it works as a critique of tech products, too. We’re so busy disrupting and reinventing that our products suffer on a mundane level. They’re buggy, unstable, clunky, confusing, and all too often don’t meet user needs.

But fixing that problem doesn’t require innovation or disruption or deep tech, so we dismiss it as uninteresting. To take our everyday apps — docs, spreadsheets, presentations, messaging, maps, photos, notes, and all the rest — and make them stable and elegant doesn’t require heroic feats of computer science. It’s tractable, if only we build effective teams to deploy the UX, product, and software-engineering skills we’ve cultivated for years. But instead, we build MVP after MVP embodying moonshots we’ve rethought from first principles for the tenth time. Getting to v1 is a bit of a running joke, and “fast follow” is a synonym for “probably not gonna happen.”

Here’s what it looks like in the real world:

1. Every time I open Gmail on my iPad a dialog appears saying, “Oops, something went wrong.” (I’m not paraphrasing; that’s what it says.)
2. My wife wants to join Iceland Air’s frequent flyer program but can’t because their email-verification system is broken. It has been for months.
3. The Zoom app on my Mac updates itself on launch. So: a meeting tool is designed so it regularly makes people late to meetings.
4. Whatever Apple is doing here:

I don’t know what a system private window picker is; do you?

By now everyone’s used to this sort of thing, and that’s sad: it doesn’t have to be this way. It is this way because we, in tech, don’t prioritize making things good. Or we refuse to prioritize anything we can’t map onto short-term results. So our users build workarounds for our broken functionality or simply give up, while we sit in meeting rooms talking about next big thing.

Our best practices for product development — the hypothesize-and-test methodology found in Inspired or Lean Startup — fail us here. Not to reject that process: I’m a fan! But it’s not sufficient here because building well-designed, stable products isn’t a hypothesis, not something we need to prove or disprove. Once we have product-market fit we should make the product great. And once we’ve done so, we don’t need to reinvent it unless users’ needs change.

To be fair: if your sole objective is to make a quick buck, you don’t need a great product. Find initial, imperfect product-market fit; build an early customer base; engineer a modest exit. I say it like it’s easy, and of course it’s not — finding that first product-market fit is incredibly hard — but you can achieve it with a mediocre product.

But if you’re in it for the long haul — if you want to build a bigger business — then a higher-quality product — a real v1 — starts to matter. Consider some famous historical examples:

• Google originally succeeded via UX: a simple search box. As they expanded through the 2010s, they placed greater and greater emphasis on usability — not to mention stability, security, and performance.
• Netflix has always offered a polished, reliable experience, since the days of DVD mailers.
• “Move fast and break things” notwithstanding, Facebook in its early years provided a reliable, easy-to-use product that met (and evolved in response to) a clear, unique user need.
• Instagram became the first $1B tech acquisition via a product that was extremely focused and highly polished.
• OpenAI started with a first-mover advantage, but is no longer in the lead from a pure tech standpoint. But ChatGPT has remained the standard by being a simple and approachable product.
• Sonos’ premature release of a buggy, unfinished app last May has damaged their brand, their business, and resulted in the firing of their CEO this week.

It’s more than that, though. Whether you care about becoming the next unicorn or not, most of us like the idea of changing the world. Who wouldn’t? But as an industry, we came to perceive the act of disrupting any status quo with technology as inherently good; indeed, a lot of today’s militant techno-optimism is a defense of that in the face of clear evidence it’s not that simple.

But maybe, a little bit, it can be that simple — if we recognize that changing the world doesn’t always need to be disruptive.

Fundamentally, we build tools. What Gardiner is saying — and it’s important — is that we’ve erroneously convinced ourselves those tools should regularly remake the fabric of society, and our expertise in tool-building qualifies us to do so without really thinking through consequences. And we’re so focused on that myth that we’re building shitty tools — failing at both the thing we’re qualified to do and the the thing we’re unqualified to do.

Billions of people use our tools every day. We possess the skills to make those tools shine. So, what if we made the world a better place simply by building great ones?