I sat in a dimly lit conference room at one of the big tech companies, watching a product lead present their six-month roadmap to the executive staff. The slides were polished. The metrics looked strong—engagement up 14%, retention ticking upward. But when the head of engineering leaned over and said, “Cool features. But who the hell asked for this?” — I knew we were in trouble.
That moment stuck with me. Because it wasn’t just that team. It’s most teams. We build things that look good on paper but solve nothing real. We confuse motion with progress. We ship fast, measure faster, and still end up with products no one actually wants.
Here’s the hard truth: Great execution doesn’t save a bad insight. And most of the time, the insight is bad because we never asked the right question.
Let’s fix that.
The Debrief That Killed a $2M Project
It was a Friday afternoon. The kind where everyone’s checked out by 3 PM, but the leadership team insisted on closing the quarterly product review. The product manager walked in with confidence—new dashboard UI, personalized recommendations, deeper integration with third-party tools. Her team had been working on it for 18 weeks.
“Pilot results show a 23% increase in session duration,” she said, beaming.
Silence.
Then the head of customer success spoke: “I just got off a call with our top five enterprise clients. None of them mentioned this feature. In fact, when I asked if they’d use it, two said it looked like clutter.”
Another pause.
The VP of Product turned to the group: “Let’s be honest—did any of our customers ask for this?”
No one raised a hand.
They killed the project that day. Not because the tech failed. Not because the UX was bad. But because they realized too late: they’d built an answer to a question no one had asked.
We do this all the time.
We fall in love with solutions. We optimize for engagement, speed, and feature density. But we forget the first rule of product: you’re not building for yourself.
Hiring Committees Don’t Hire Innovators—They Hire Safe Bets
Let me tell you what really happens in hiring committees.
You walk into a room—sometimes virtual, sometimes real—with five people holding clipboards. They’ve read your resume. They’ve heard about your last exit. They’re impressed.
Then they ask: “Tell us about a time you launched a successful product.”
And what do you say?
If you’re smart, you talk about metrics. Velocity. A/B test results. How you scaled to 1M users in six months.
But here’s the truth: No one in that room actually knows if the product mattered. They know if it performed. They don’t know if it was necessary.
I’ve sat in over 30 hiring committee meetings. I’ve seen teams pass on candidates who built products that failed—but solved real problems—because “the numbers weren’t there.” Meanwhile, we hired people who shipped endless iterations of a mediocre internal tool because “their process was solid.”
That’s how we end up with competent executors and a shortage of real problem finders.
Here’s a counter-intuitive insight: The best product people often have a string of “failed” projects on their resume. Why? Because they were working on hard problems—ones that didn’t have obvious solutions or fast wins.
But hiring committees? They want proof of success. Not evidence of curiosity.
So we get people who build what’s measurable, not what’s meaningful.
Stakeholder Meetings Are Theater—Until Someone Asks “Why?”
You’ve been in these meetings.
Product lead: “We’re increasing user engagement by 18% with this new onboarding flow.”
Engineering: “We’ll need three more weeks to stabilize the backend.”
Design: “The micro-interactions are still being refined.”
Everyone nods. Slides advance. Decisions are “made.”
But no one asks: Why are we doing this at all?
I once sat in a stakeholder alignment meeting for a major mobile app overhaul. The room was packed—product, marketing, legal, support, analytics. We spent 45 minutes debating button color and tooltip placement.
Then the new VP of Customer Experience, who’d come from a non-tech background, raised her hand.
“Before we decide where the button goes—can someone tell me what problem this redesign is solving?”
Silence.
The product director stammered: “Well… we’re modernizing the experience. Improving engagement.”
“Based on what customer feedback?”
Another pause.
“…We haven’t spoken to users directly. But the analytics show drop-off in onboarding.”
“And what did support tickets say?”
“They mention confusion—but not about onboarding. Mostly billing and sync issues.”
She looked around the room. “So we’re spending $750K redesigning onboarding… while customers are calling support about billing errors. Is that right?”
The room deflated.
That meeting didn’t kill the project. But it delayed it by six weeks—long enough to run actual user interviews. What we found? Users didn’t hate onboarding. They hated that the app charged them twice in one week.
We’d been optimizing the wrong thing.
Three Counter-Intuitive Truths About Building Things People Want
After 15 years in product—from startups to public tech giants—I’ve learned that the rules most of us follow are wrong. Here are three truths no one wants to admit:
1. The Loudest Users Are Usually Wrong
We love to listen to customers. But we listen to the wrong ones.
The people who fill out surveys, reply to emails, jump on feedback calls? They’re not representative. They’re the 5% who care enough to complain. And often, they’re asking for features that benefit only them.
At one company, our power users demanded a custom scripting layer so they could automate workflows. We spent nine months building it.
Launch day came. Usage? 1.2% of active users.
Turns out, the people shouting the loudest weren’t the majority—they were outliers.
The real insight came from watching silent users—the ones who never submitted feedback. They weren’t asking for scripting. They were struggling to even find basic features.
Lesson: Don’t build for the vocal minority. Build for the silent majority.
2. Speed Kills Insight
We fetishize speed in tech. “Move fast and break things.” “Ship, learn, iterate.”
But here’s what no one says: If you don’t understand the problem, moving fast just gets you lost faster.
I worked with a team once that launched a new social feature—real-time collaboration on documents. They built a prototype in two weeks, tested it with 100 internal users, saw a 40% engagement spike, and pushed it to 10% of customers.
Great, right?
Except three months later, usage collapsed. Why? Because we never asked: Why were people collaborating?
Turns out, the spike wasn’t about collaboration. It was about notification overload. People were clicking into documents just to dismiss alerts.
We mistook noise for demand.
Had we slowed down and done five in-depth user interviews, we’d have caught it. But we were “shipping fast.”
Lesson: Fast feedback loops only work if you’re measuring the right thing. Otherwise, you’re just validating your assumptions faster.
3. The Best Products Start as “Stupid” Ideas
The ideas that change markets never look impressive at first.
Airbnb started as “air mattresses in my apartment.”
Notion began as a personal knowledge tool for one engineer.
Linear? Originally a side project to fix internal workflows.
But in most companies, these ideas would’ve been killed in the first review.
Why? Because they don’t come with TAM charts. No 5-year ROI model. Just a hunch and a prototype.
I once had a junior designer pitch a feature: a “quiet mode” that would mute all non-essential notifications during focus hours. The room laughed. “People will just turn off notifications themselves,” someone said.
We tested it quietly with a small team. After four weeks, focus time increased by 33%. Support tickets about overload dropped 58%.
Now it’s a core part of the product.
Lesson: Don’t confuse lack of polish with lack of potential. The best insights are often buried in “naive” questions.
How to Stop Building Things No One Wants
So what do we do?
We need a new operating model—one that puts problem discovery before solution delivery.
Here’s how I run product teams now:
1. Start with “No” Before “Yes”
Before any project, I require a one-page memo titled: “Why This Shouldn’t Be Built.”
It forces teams to confront the risks, doubts, and gaps in logic upfront. Not as a box-checking exercise—but as a real challenge.
One team wrote: “This feature benefits only enterprise customers, who make up 8% of revenue. SMBs, our growth segment, won’t use it. We’re doing it because sales asked.”
That memo killed the project before a line of code was written.
2. Replace “Voice of the Customer” with “Ears on the Ground”
Most companies have a “Voice of the Customer” program. It’s usually a deck with quotes and survey stats.
But quotes don’t tell you why people do things. Observation does.
I now mandate that every product manager spends at least four hours per month in direct customer interaction—not sales calls, not surveys, but unmoderated observation.
Watch how they use your product. Sit in on support calls. Visit their workplace.
One PM spent a day with a logistics manager using our routing software. He noticed the manager printed every route and scribbled on it with a pen.
Why?
“Your app doesn’t let me mark ‘delivered’ when the driver’s offline. So I print it, hand it back when they return, and manually update.”
That observation led to an offline mode feature that reduced data entry time by 70%.
No survey would’ve surfaced that.
3. Measure “Problem Validated” Before “Feature Shipped”
We track everything: velocity, cycle time, NPS.
But we don’t track the most important thing: Did we understand the problem correctly?
Now, every project starts with a “Problem Validation Score”—rated from 1 to 10.
Criteria include:
- Number of customers observed with the problem
- Frequency of problem occurrence
- Severity (time lost, revenue impact, emotional stress)
- Evidence it’s not just a one-off
No project green-lit until score is 7+.
One team scored a 4 on a proposed analytics dashboard. They thought people wanted more metrics. But interviews showed users were overwhelmed by data, not starved for it.
They pivoted to a “daily digest” summary instead. Adoption jumped to 68%, vs. 12% for previous custom reports.
4. Kill Projects Publicly—And Reward the Team
Most failed projects die quietly. No post-mortem. No learning.
But that teaches the worst lesson: failure is shameful.
Now, when we kill a project, we do it in a company-wide meeting—with applause.
We say: “Team X spent 10 weeks testing a hypothesis. They discovered no one needs this. That’s a win. They saved us $500K and six months.”
And we reward them—not with a bonus, but with a “Truth Finder” badge and first pick on the next high-impact project.
Result? Teams aren’t afraid to test risky ideas. Or to kill them early.
FAQ
Q: How do you balance customer feedback with long-term vision?
A: Feedback tells you what’s broken. Vision tells you where to go. Use feedback to validate the path, not set it. Steve Jobs didn’t run focus groups for the iPhone. But he understood the problem—clunky mobile experiences—deeply.
Q: What if execs demand features based on their own ideas?
Name it: “HiPPO” (Highest Paid Person’s Opinion). The fix? Require the same validation process for executive-driven ideas as any other. “Great idea. Let’s test it with five customers before we staff it.”
Q: How do you prioritize when everyone wants something different?
Map requests to outcomes, not inputs. Instead of “Sales wants a reporting tab,” ask: “What outcome does sales need?” Maybe it’s closing deals faster. That could be solved with better lead scoring—not a report.
Q: Can you move fast and still validate problems?
Yes—but redefine “fast.” Moving fast isn’t shipping code. It’s learning quickly. A week of customer interviews can save three months of wasted build time.
Q: What’s the first step for a team stuck building unwanted features?
Stop building. For two weeks. Have every product person interview five real users—no agenda, no pitch. Just listen. Then ask: “Are we solving the right thing?”
The Real Job of a Product Builder
We don’t get paid to ship features.
We get paid to eliminate waste—wasted time, wasted money, wasted attention.
The most valuable skill in product isn’t roadmap planning or stakeholder management. It’s ruthless prioritization of what not to build.
Because the next big thing isn’t hidden in a flashy prototype.
It’s hiding in the quiet frustration of someone trying to do their job—and failing.
Go find it.
Then build that.