Empathize-Then-Invent (The Stories Method)
Listen deeply to users for hours, then build something new — never the literal feature they asked for.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 92%
A product-development method that resolves the tension between listening to customers and following your own vision. You go deep with users (hour-plus conversations, not surveys) to understand how technology fits their lives, extract the underlying needs and frustrations, then invent a novel solution rather than shipping the literal request. Use it when user feedback and your product instinct seem to conflict.
Origin
Spiegel illustrates it with the invention of Stories: users kept demanding a 'send all' button and complaining about permanence, public metrics, and reverse-chronological feeds. Snap listened to all of it but built Stories — something new that answered the underlying needs without being the requested feature.
Core principles
- 01You must talk to customers and share ideas early and often — but you don't have to take their advice.
- 02Go deep (1-2 hour conversations about how tech fits their lives), not survey-shallow.
- 03Extract the underlying need behind the literal request.
- 04Invent a new solution that answers the need instead of building exactly what was asked.
How to run it
- 1
Share your idea early and listen widely
Put your idea in front of people as quickly and frequently as possible. The goal is to listen, not to collect votes or take instructions.
Pro tip Treat customers as 'an endless source of inspiration,' not a decision-making committee.
- 2
Go deep, not broad
Skip the survey model. Talk with individuals for an hour or two about how they actually use technology and how it fits into their lives.
Watch out Survey-style listening is 'not particularly helpful' — depth surfaces the real insight.
- 3
Separate the literal request from the real need
When users ask for a specific feature, identify the underlying frustration driving it. 'Send all' really meant 'let me share broadly without the friction'; complaints about permanence meant 'reduce the pressure and judgment.'
- 4
Invent something new that answers the need
Build a novel solution responsive to the insights — not the literal feature. Stories let people share with all friends without spamming, removed public metrics to cut pressure, disappeared after 24 hours, and ran in chronological order.
Watch out Building exactly what users ask for (e.g. a literal send-all button) often misses the deeper opportunity.
In the wild
Users demanded a send-all button and disliked permanence, public likes/comments, and reverse-chronological feeds. Snap absorbed every insight but invented Stories: broadcast without spamming, no public metrics, 24-hour disappearance, chronological order.
→ A feature now copied across the entire industry; Spiegel: 'we didn't build exactly what they asked for.'
Common mistakes
Building the literal request
Shipping the send-all button would have solved the surface annoyance while missing the deeper needs around pressure, permanence, and sharing.
Relying on surveys
Shallow survey feedback doesn't reveal how technology actually fits people's lives; only long, deep conversations do.
Is it for you?
Best for
Consumer product designers deciding how to weigh loud user feature requests against their own vision.
Not ideal for
Situations demanding fast literal fixes to clear usability bugs, where reinvention is overkill.
From the transcript
“You have to talk to customers. You have to share your idea.”
“going deep and talking with someone for an hour, 2 hours about how do they use technology”
“we didn't build exactly what they asked for. We we empathized and then you know, came up with something new”
From the episode
Snapchat CEO: Why distribution has become the most important moat
Evan Spiegel