Published: May 17, 2025 on Medium
Part 1 of 8-part blog series on Customer Centric Systems
This post is the first entry in my new blog series on “Customer-Centric Systems”. I intend to bring forward several case studies where we forget the customers and build some “cool” products that no one wants. There is a reason why “Customer Obsession” is still the #1 Leadership Principle at Amazon. In this installment, we look into case studies of how not starting with the customer in mind results in disasters.
Why ‘Know Thy Customer’ Is the First Rule of System Design
It was supposed to be a historic win. Instead, the launch of Healthcare.gov in 2013 became a nightmare. Millions of Americans logged on to the new health insurance marketplace, only to encounter error messages, frozen forms, and glitchy loops that duplicated entries. The site kept crashing under real-world use, leaving frustrated would-be customers in limbo. Over a week, 8 million users visited the website, with a signup success of 1%. Post-mortem revealed one surprising culprit: a convoluted sign-up process that overwhelmed users and even contributed to the system’s failure.
That fiasco offers a painful lesson. Complex code and cutting-edge features aren’t worth much if actual humans can’t or won’t use them. In the end, systems don’t fail because the code crashes. They fail because no one wants to use them. “Know thy customer” is more than ancient wisdom – it’s the first rule of system design, and the cautionary tales are everywhere.
Assumptions Are Costly!
Too often, tech teams build in isolation, blinded by their own assumptions. We dream up solutions in meeting rooms without ever validating that anyone out there has the problem we think we’re solving. The result is disastrous: products land with a thud because they answer questions nobody was asking. Remember Google+? Google’s social network had plenty of engineering muscle and marketing might behind it. Yet it fizzled out after failing to understand what users actually wanted. At one point, a stunning 90% of Google+ user sessions lasted less than five seconds (source).
And then there’s Quibi, the $1.75 billion streaming platform that promised to revolutionize on-the-go video. Quibi’s founders were so confident that people craved high-end, bite-sized shows on their phones that they skipped over basic user validation. The outcome? Quibi shut down in barely six months, proving they had essentially run a $2 billion experiment on an unvalidated assumption.
You might ask, How often are we solving problems we’ve never actually confirmed exist? One analysis of startup failures by CB Insights found that “No market need” was the #1 reason, implicated in 35% of cases. In other words, more than a third of failed startups built something nobody really needed.
Long-Term Cost of Building Something That’s Not Needed
What does building the wrong thing do to a system over time? For one, unused features start to pile up like junk in a garage. Each extra button, module, or integration that sounded good in theory but nobody uses is essentially dead weight in the codebase. In fact, studies have found that as much as 64% of product features are rarely or never used.
All those “cool” features still carry a maintenance cost. Developers must babysit them through every update, QA has to test them, and UX designers have to accommodate them, creating complexity at every turn.
By one 2024 estimate, developers devote 30–40% of their time dealing with technical debt, which costs the software industry around $85 billion annually in lost productivity.
Bridge to Customer-Centric Design
So, what can we do about it? How can we ensure we are not accumulating junk over time? One useful tool here is the “Jobs to Be Done” (JTBD) framework. JTBD urges us to stop obsessing over features and start asking: what job is the user hiring this product or system to do? As an HBR article put it, it’s about understanding “the progress that the customer is trying to make in a given circumstance — what the customer hopes to accomplish.”
People don’t buy a drill because they love drills; they buy it to get a hole in the wall. Likewise, your system’s features should directly enable the real jobs your users need done.
One of the best examples of user-centric reinvention is Airbnb’s turnaround in 2009. Faced with flatlined growth, the founders embedded themselves with users in New York, saw that bad listing photos were killing trust, and personally took better ones. That “unscalable” decision doubled revenue in a week and rewired their product focus.
First Steps for Teams
Here are a few simple steps to begin:
- Run a stakeholder alignment workshop: Map out what success looks like for your system from the user’s perspective. Amazon’s PR/FAQ is a great way to start.
- Map your unknowns and blind spots: Explicitly document assumptions about users and prioritize validating the riskiest ones.
- Identify one key user pain point to investigate deeply: Conduct interviews or research to uncover root causes and design insights.
Conclusion
In the end, “Know thy customer” isn’t a one-time box to check – it’s an ongoing discipline and the bedrock of successful system design. The biggest risk is building something people don’t want — and that’s a risk you can eliminate by talking to your users early and often.
Last modified on 2025-05-17