The Problem With Building First
The graveyard of well-engineered products that nobody wanted is immense. Technically competent teams have built sophisticated, feature-rich products that users ignored, rejected, or couldn't figure out how to use. The technology was fine. The code was clean. The interface was polished. And it died quietly because it was solving a problem nobody urgently had, in a way nobody wanted it solved, for people the team had never actually talked to.
Building products people love is not primarily a technology problem. It's an understanding problem. The teams that build products people love have a different relationship with their potential users than the teams that build technically impressive failures. They know things. Specific, granular, often uncomfortable things about how people actually behave, what they actually struggle with, and what they actually want — not what they say they want in a survey, but what their behavior reveals.
Start With the Problem, Not the Solution
Every product that earns genuine user love starts with a genuine, well-understood problem. Not a product hypothesis. Not a feature set. A specific, specific human problem that real people experience.
The discipline required here is resisting the urge to generate solutions before you've deeply understood the problem. Product builders are usually people who generate solutions naturally — it's what they're good at and what they enjoy. The generative, creative energy that makes product people effective is also the thing that leads them toward premature solutioning.
The antidote is time spent in deep, qualitative user research before any significant building starts. Not surveys — surveys produce what people think they should say, not what they actually experience. Not analytics of products that don't yet exist. Conversations. Observations. Time spent watching real people try to do the thing your product will eventually help them do.
Paul Graham's advice to "do things that don't scale" is partly about this: before you build a scalable product, do the unscalable work of understanding people with granular specificity. Talk to fifty potential users. Watch ten people try to accomplish the task your product addresses. Ask what they've already tried. Understand the actual moment of frustration.
The Job to Be Done Framework
One of the most useful frameworks for understanding what drives genuine product love is the "Jobs to Be Done" approach, developed by Clayton Christensen and extended by practitioners like Bob Moesta and Alan Klement.
The core insight is that people don't buy products — they "hire" them to accomplish specific jobs in their lives. And those jobs have functional, emotional, and social dimensions that go far beyond what the product's literal function might suggest.
The famous example: people don't buy a quarter-inch drill bit. They buy a quarter-inch hole. And more specifically, they buy the ability to hang a picture so their house feels like a home. The functional job (make a hole) is different from the emotional job (feel like this is my space) and the social job (have friends over to a place I'm proud of).
When you understand the full job — functional, emotional, social — you understand what a product truly needs to deliver to earn love rather than mere utility. Slack wasn't beloved because it was a messaging app. It was beloved because it made work feel connected, transparent, and alive in a way that email never had. The job it was hired to do was "help my team feel like we're actually working together," not "send messages to colleagues."
Minimum Viable Products That Actually Test the Right Thing
The MVP concept has been so widely adopted and so widely misapplied that it deserves careful unpacking.
An MVP is not a low-quality version of your product. It's not a product with most features removed. It is the smallest, fastest, cheapest experiment you can run that tests your most critical assumption. And the most critical assumption is almost always about whether the problem is real and whether people want your specific solution — not whether you can build it.
Before writing any code, you can often test core assumptions with a landing page, a mockup, a manual process, or even a direct conversation in which you walk someone through your proposed solution and watch their reaction. The Dropbox demo video — which showed a product that didn't yet exist and captured 75,000 signups overnight — tested whether people wanted the product before a single engineering hour was invested.
The question an MVP must answer is: are we solving the right problem in roughly the right way for enough people to make this viable? Not: have we shipped a version with fewer features?
Designing for Delight, Not Just Utility
Products that are used are not the same as products that are loved. People use plenty of products they neither like nor feel positively about. The ones they love have properties beyond functional adequacy.
Speed: Nothing kills love for a digital product faster than slowness. Response times, page loads, interaction latency — these are not engineering optimization problems, they're user experience fundamentals. Stripe, one of the most-loved developer products ever built, built their reputation partly on exceptional speed and reliability, which in the financial infrastructure context was genuinely novel.
The "aha moment": Every truly beloved product has a moment at which the user experiences the core value for the first time and has a strong positive reaction. For Slack, it was the first time a message appeared in real time in a channel shared with your team. For Spotify, it was the first time a recommended song perfectly matched your taste. Identifying and accelerating the time-to-aha is one of the highest-leverage activities in product development.
Emotional texture: Great products have personality — a distinctive voice, a visual aesthetic, a set of small details that communicate care. The copy in Mailchimp's UI. The character of Notion's interface. The way Superhuman feels like it was built by someone who cares deeply about keyboard shortcuts. These aren't decorative. They communicate that the people who built the product give a damn, and that care is felt and returned by users.
Removing friction relentlessly: Every additional step in a user flow, every required field that could be optional, every decision the user must make that the product could make for them — these are friction points that reduce the experience from delightful to adequate. The products that earn love have typically been through dozens of iterations of friction removal.
The Feedback Loop That Sustains Love
Building a product people love is not a one-time act of design insight. It's a sustained loop of listening, building, measuring, and listening again.
The most important input in this loop is qualitative, direct user feedback — not just analytics showing what users do, but conversations that reveal why. Why did they stop using it? What was the moment they loved it? What do they wish it did? What do they tell their friends it does for them?
The teams that sustain product love have a culture of being genuinely curious about and bothered by every point of user frustration. The bug reports, the support tickets, the Twitter complaints — these are not PR problems to be managed. They're a stream of information about the gap between where the product is and where users need it to be.
Love Is Earned, Not Announced
The worst thing a product team can do is declare their product beloved rather than earn it. "Our users love this" as a defense against critical feedback, rather than as a genuine measurement. Early traction as a substitute for sustained user commitment.
Products that earn genuine, lasting love do so by solving a real problem better than any alternative, by delivering that solution with speed and personality, by listening relentlessly to their users, and by caring visibly about the experience of every person who uses what they've built.
The technology is often the easiest part. The understanding, the empathy, the relentless attention to the user's experience — these are what separate the products that matter from the ones that don't.
Start with deep understanding. Everything else follows.