About a third of startups die for one simple reason: they build something nobody actually wants. In this episode, we’ll drop into real moments—kids brushing their teeth, travelers booking a spare room—to explore how empathy quietly rewires the way innovation begins.
So how do you actually *do* this in the messy, rushed reality of work? Most teams rush straight to brainstorming features, like tourists snapping photos from a bus window—collecting surface impressions instead of stepping into the streets. The shift we’re exploring today is quieter: slowing down enough to notice what people *actually* do, not just what they say in surveys or brainstorms.
That’s where tiny, specific clues live: the way someone hesitates before tapping a button, the workaround they’ve invented with sticky notes, the offhand comment that contradicts the official process. These small “frictions” are often where the real opportunity hides.
In this episode, we’ll zoom in on how to spot those clues, how to turn raw observations into sharp insights, and how companies have used that lens to reduce the risk of building the wrong thing.
Think of this as shifting from “user research” as a checkbox to “user time” as a regular creative workout. Instead of waiting for a big project, you start weaving short, focused encounters into your normal week—ten minutes watching someone onboard to your app, a quick call with a frustrated customer, a quiet scan of comments in support tickets. You’re not hunting for validation; you’re collecting clues. Over time, those clues stack up like layers of paint on a canvas, revealing patterns you’d never see in a single workshop or quarterly review meeting.
Here’s where empathy gets practical: *what* do you actually look for when you’re with users, and *how* do you turn what you notice into something your team can build around?
Start small and concrete. Instead of asking, “What do you think of this product?” zoom into specific moments:
- “Walk me through the last time you tried to do X.” - “Show me where this typically goes wrong.” - “Pause when something feels annoying or confusing.”
You’re paying attention to tiny signals: a long pause, a nervous laugh, an eye-roll, a workaround they’re slightly embarrassed to show you. When someone says, “It’s fine,” but their shoulders tense, treat that dissonance as a data point. People often normalize pain because they’ve had to live with it.
A useful move: separate *what happened* from *what you think it means*. First, write down the scene in almost boring detail—who, what, where, when, exact quotes. Only after that do you ask, “So what might this reveal about what they value, fear, or are trying to avoid?”
Look at the Oral-B kids’ toothbrush story: the designers didn’t start with “How do we make a better toothbrush?” They lingered on how kids actually held things. The surprising detail—kids fist-gripping crayons instead of pinching them delicately—pointed to a completely different handle shape. The eventual design wasn’t an abstract brainstorm; it was a direct response to that physical reality.
The same pattern runs through Airbnb’s pivot. Hosts didn’t say, “I need higher-quality listing photos and reassurance about strangers in my home.” They talked about trust, safety, and “not wanting my place to look bad.” By being physically present, the founders saw the gap between what hosts said and what they actually worried about, then built improvements around that gap.
Empathy also becomes a filter for prioritization. Faced with a long list of feature requests, you can ask: “Which of these are anchored in real, observed struggles—and which are wish-list items?” That distinction matters. Features rooted in real scenes tend to move metrics like adoption and retention because they’re solving something people already feel daily.
Over time, this practice shifts your team’s default questions. Instead of “Can we build this?” the more powerful question becomes “Whose life gets meaningfully easier if we do?”
Think about the last time you tried a new productivity app. Maybe you didn’t rage-quit; you just quietly drifted away. That “soft rejection” is gold for teams who are willing to look closely.
One team I worked with noticed a strange pattern: users were creating projects in their tool but never adding tasks. Instead of blasting out a survey, they watched recordings of those first three minutes. They saw people pausing on a blank screen, flipping to a notes app, then returning. No one complained. But behavior whispered: “I need a place to *think messily* before I organize.”
They didn’t add more features; they added a scratchpad. Adoption of projects jumped, and support tickets about “confusing setup” dropped without a single tooltip.
Analogy from travel: some of the best city guides aren’t planned routes; they’re the worn footpaths people actually walk through parks and side streets. Those “desire lines” tell a more honest story than any official map. In products and services, your job is to find those desire lines—and decide when to pave them.
As tools get smarter, the edge shifts from knowing *what* people do to understanding *why* it matters in their broader lives. Empathy becomes infrastructure, not a workshop exercise. Teams start asking: “Who isn’t in this data?” and “What harms might this create on a bad day?” Inclusive choices—like defaults that respect time, privacy, and cultural nuance—compound quietly. Over years, that compounds into trust: not just “this works,” but “this brand is on my side.”
The real opportunity is to treat each interaction like opening a new book: you’re not skimming for plot points, you’re noticing side characters, margins, tone. Over time, those details show where to stretch, shrink, or rewrite what you offer. Let your next product tweak be a response to a lived moment, not a hallway hunch or slide-deck slogan.
Before next week, ask yourself: 1) “Where in my current project am I *assuming* I know what users feel, instead of actually hearing it from them—and who could I talk to this week (a customer, colleague, or end user) to test that assumption in a 10-minute conversation?” 2) “If I replay the last time someone gave me critical feedback on our product or idea, which part of their emotional experience did I ignore or minimize, and how would I respond differently now if my only goal were to understand, not defend?” 3) “Looking at one specific feature or decision we’ve made, whose experience is missing from the room (e.g., edge users, support staff, non-technical stakeholders), and what’s one concrete way I can bring their story into our next discussion—through a quote, a short audio clip, or a real person joining the meeting?”
