Building Products Users Love: Beyond the Feature Factory

In 2018, I sat in a conference room watching a product team celebrate. They had just shipped a dashboard redesign — six months of work, dozens of new widgets, a real-time data pipeline. The engineering was impressive. The design was polished. And three months later, engagement was flat. Users hadn't asked for any of it.

That moment crystallized something I'd been sensing for years: shipping features is not the same as solving problems. The teams that build products users genuinely love don't just execute faster — they operate from a fundamentally different playbook. They have a system for discovering what matters before they build it.

The Product Death Spiral

Most products don't die because they're poorly engineered. They die because they solve problems nobody has, or problems that aren't urgent enough to warrant switching from the status quo. I call this the Product Death Spiral:

  1. Stakeholder has an idea ("We need a reporting dashboard!")
  2. Team builds it because the stakeholder is senior
  3. Ships it. Nobody uses it the way they imagined.
  4. Stakeholder has another idea. Repeat.

After three or four cycles, you have a bloated product full of features that serve no coherent purpose. The antidote is product discovery: a systematic practice of figuring out what to build before you build it.

Jobs-to-be-Done: The Foundation

Clayton Christensen's JTBD framework is the closest thing product discovery has to a first principle. People don't buy products; they hire them to make progress in a specific circumstance.

When you buy a drill, you don't want a drill. You want a hole. And you probably don't even want a hole — you want to hang a shelf. And you don't want to hang a shelf — you want your living room to feel organized so you can host guests.

The JTBD Interview

Bob Moesta's interview technique reconstructs the moment someone "hired" or "fired" a product:

Users are terrible at predicting what they want, but excellent at describing what they've already struggled with.

Example: Superhuman

Superhuman studied power email users and mapped specific jobs:

The product's sub-100ms interactions, keyboard-first design, and "remind me later" features all trace back to these jobs — not to a competitor feature comparison.

Outcome-Driven Development

ODD, developed by Tony Ulwick, measures whether you're delivering on jobs:

The Opportunity Algorithm

code
Opportunity Score = Importance + max(Importance - Satisfaction, 0)

Survey users on two dimensions for each outcome:

  1. How important is this outcome? (1-10)
  2. How satisfied are you currently? (1-10)

Outcomes with high importance and low satisfaction are your underserved outcomes — the goldmine.

Continuous Discovery

Teresa Torres's continuous discovery framework rests on three pillars:

1. The Opportunity Solution Tree

Map from desired outcome → opportunities → solutions. Every solution must trace back to an outcome.

2. Assumption Testing

Five types of assumptions to test:

The fastest test is rarely the full build. Fake door test (hours) → concierge test (days) → full build (months).

3. Weekly Interviews

One user interview per week, minimum. After a year, you've spoken to 50+ users. You develop intuition no dashboard can replicate.

Putting It All Together

Building products users love isn't a mysterious creative act. It's a systematic practice:

  1. Understand the job — Not the feature request, but the progress the user wants to make
  2. Define the outcomes — Find underserved opportunities
  3. Test assumptions cheaply — Build only when cheaper methods can't answer your question
  4. Talk to users weekly — As a habit, not a project phase
  5. Ship, measure, learn, repeat

The teams that do this consistently don't just build features. They build trust, they build habits, they build products users wouldn't replace even if a competitor offered twice the features at half the price.

Published July 2026.