The Hiring Committee That Killed a "Visionary" Candidate
I sat in a windowless conference room at one of the big tech companies, late on a Friday afternoon. Four senior product leaders, two engineers, and a design lead were reviewing a final-round candidate for a director-level role. The candidate had strong credentials—ex-FAANG, shipped multiple consumer apps, MBA from a top school.
He walked us through a product he’d led: a social fitness app. “Our mission was to empower people to live healthier lives,” he said. “We believed that community could drive real behavior change. That’s why we built group challenges, leaderboards, peer encouragement.”
Silence.
One of the engineers finally spoke. “Cool. But why’d you build this specific feature? Not another one?”
The candidate blinked. “Because it aligned with our mission?”
Another product lead leaned forward. “Right, but why that leaderboard? Why 7-day challenges instead of 30-day? Why public sharing instead of private goals? You say you wanted behavior change—what specific behavior, in what context, for whom?”
The candidate stammered. “I mean… we wanted people to move more. Be healthier.”
The room deflated.
Later, in debrief, one director said, “He’s smart. But he can’t articulate a grounded ‘why.’ He speaks in slogans. If we hired him, he’d burn cycles chasing vague north stars while the market passes us by.”
We rejected him.
That moment crystallized something I’ve seen repeat across dozens of hiring committees: smart, experienced builders fail not because they lack vision—but because they mistake inspiration for intention. They say “why” like it’s a mantra, not a mechanism.
Great product leaders don’t just “start with why.” They build with why—specific, testable, and tied to real user behavior. The rest? They’re just selling posters.
The “Why” That Everyone Quotes—But No One Uses Correctly
Simon Sinek’s “Start With Why” is one of the most misapplied ideas in tech.
I’ve seen it in 100+ product reviews. Leaders say:
“We’re building this because our why is to connect people.”
“Our why is to democratize finance.”
“Our why is to make work more human.”
That’s not a “why.” That’s a brand tagline.
Sinek’s model—the Golden Circle—gets flipped in practice. Most teams treat “why” as the top-level mission, “how” as the product strategy, and “what” as the features. But in product development, that order reverses.
Here’s the real workflow:
- You observe a specific user behavior or pain point (the what).
- You design a solution path (the how).
- You link it back to a broader company mission (the why).
In other words: you arrive at the why—you don’t start there.
Let me show you what happens when you get it backward.
At a late-stage startup I advised, the CEO insisted their “why” was “to eliminate loneliness in modern life.” Beautiful. Emotional. Dangerous.
The product team spent six months building AI companions—chatbots with fake backstories, voice personalities, even “memory” of past conversations. They launched. Engagement was terrible. Retention cratered after 48 hours.
Post-mortem revealed the truth: users didn’t feel less lonely. They felt more lonely—because the bots highlighted what was missing: real human connection.
The “why” wasn’t wrong. But it was too broad. It didn’t connect to a specific behavior in a specific context.
When we reframed, everything changed.
We didn’t abandon the mission. But we narrowed the focus: “Help remote workers feel seen during isolated workdays.”
Suddenly, the “how” became clear: lightweight, opt-in peer recognition. Not deep emotional AI—but a simple Slack integration where teammates could send quick, visible kudos.
Retention jumped to 68% weekly active use. NPS went from -12 to +41 in eight weeks.
Same company. Same north star. But one version of “why” led to wasted months. The other drove growth.
The insight? A good “why” isn’t inspirational. It’s diagnostic.
It doesn’t motivate the team. It constrains the team.
Three Counter-Intuitive Truths About Building With Why
1. The Best “Why” Is Boring—And Specific
At a stakeholder meeting for a fintech product, a product manager pitched a new savings feature. “Our why,” she said, “is to help people achieve financial freedom.”
I interrupted. “Define ‘financial freedom.’”
She paused. “Uh… not living paycheck to paycheck?”
“Okay. How many of your target users are actually living paycheck to paycheck?”
“About 60%.”
“And how many of those are under 35?”
“80%.”
“So we’re talking about young professionals who make $50K–$80K, rent in high-cost cities, and want to save but keep failing?”
“Yes.”
“Then say that.”
She rewrote the “why”:
“To help early-career urban professionals save $200/month consistently, so they can build a 3-month emergency fund within 18 months.”
No one clapped. It wasn’t “bold.” But the room shifted.
Engineers asked: “What’s the biggest reason they fail to save $200 today?”
Designers said: “Should we focus on reducing friction at payday, or better goal visualization?”
Data scientists proposed: “Let’s track the correlation between savings momentum and late-night spending.”
The “why” became a filter—not a banner.
Six months later, the feature launched with a “payday split” mechanic: automatic allocation at the moment income hits the account. Conversion was 31%, beating the benchmark by 14 points.
The lesson: If your “why” doesn’t exclude someone, it’s not useful.
2. The “Why” Should Be Testable—And Falsifiable
At a product offsite, a founder pitched a wellness app. “Our why is to help people become their best selves.”
I asked: “How would you know if you failed?”
He smiled. “We’d see low engagement.”
“But what if engagement is high, and people feel worse?”
Silence.
“Let’s say users spend 45 minutes a day on your app. They complete all the challenges. But their anxiety scores go up. Have you succeeded?”
He paused. “I… don’t know.”
That’s the problem. His “why” wasn’t falsifiable.
A strong “why” must include a failure condition.
The best ones follow this structure:
“We believe [specific user] struggles with [specific problem] in [specific context], which leads to [specific negative outcome]. We will know we’re right if [measurable change] occurs.”
Example from a real product spec:
“We believe remote knowledge workers miss spontaneous peer recognition, which leads to feeling invisible and disengaged. We will know we’re right if users who receive a kudo in a given week show a 15-point higher eNPS score and 25% higher task completion rates.”
Now you can test it.
If kudos go up but eNPS doesn’t move? Your “why” was wrong.
If engagement rises but task completion drops? You created distraction, not motivation.
This isn’t philosophy. It’s hypothesis-driven product development.
At a stakeholder review last year, a PM presented a calendar scheduling tool. His “why” was “to give people control over their time.”
I asked: “What does ‘control’ look like in practice?”
He said: “Less chaos. Fewer double-bookings.”
“Define ‘fewer.’”
“We’re aiming for a 30% reduction in rescheduled meetings.”
“Okay. And what’s the user’s real job-to-be-done?”
He thought. “To feel confident their time reflects their priorities.”
Now we had a testable “why”:
“We believe mid-level managers lose confidence when their calendar doesn’t reflect their stated priorities, leading to stress and overwork. We will know we’re right if users who adopt our auto-prioritization feature report a 20% drop in after-hours work and a 10-point increase in time satisfaction scores.”
Three months later, data confirmed it. The feature shipped. The “why” wasn’t sexy. But it was actionable.
3. The “Why” Is a Team Tool—Not a Marketing Pitch
I once sat in on a startup pitch where the founder said: “Our why is to revolutionize how humans interact with machines.”
Great for a homepage. Useless for a product roadmap.
The exec team nodded. The investors smiled. But the engineers stayed silent.
Later, I asked an engineer: “What does that mean for your sprint planning?”
He laughed. “Nothing. We’re just trying to fix the API latency.”
That’s the danger: when “why” becomes external-facing fluff, it loses internal utility.
The best “why” statements are used in decision meetings, not press releases.
At a quarterly planning session for a B2B SaaS product, the team debated whether to build a mobile app.
One lead said: “Our vision is to be the central hub for distributed teams. Mobile is table stakes.”
Another countered: “But 87% of our usage is desktop, during core work hours. Only 4% of actions happen on mobile—and most are status checks.”
The product leader stepped in: “What’s our working ‘why’ again?”
The PM pulled it up:
“We believe distributed engineering teams waste hours weekly reconciling work status across tools, leading to launch delays. We solve this by syncing key project signals in one dashboard, accessed during morning standups.”
“Where do standups happen?” he asked.
“At desks. On laptops.”
“So mobile isn’t about status checks. It’s about participation in rituals.”
The team paused.
They decided to delay mobile and instead build a “standup mode”—a desktop-optimized view that surfaces only what’s needed for daily syncs.
Engagement in standup sessions rose 40%. Adoption in engineering teams jumped from 52% to 76%.
The “why” didn’t inspire the press. But it saved six months of engineering time.
How to Write a “Why” That Actually Works
Forget Sinek for a moment. Think like a scientist.
Your “why” is a hypothesis—not a creed.
Here’s the template I use in real product specs:
“We believe [user segment] experiences [specific pain] when [specific context], which leads to [undesired outcome]. We will test this by measuring [key metric] before and after [intervention].”
Let’s break it down.
Step 1: Name the User—Precisely
Not “busy professionals.”
Try “marketing managers at mid-sized tech companies with 5+ direct reports.”
Not “young savers.”
Try “first-time homebuyers in cities with median home prices over $600K.”
Specificity forces clarity.
Step 2: Define the Pain—Behaviorally
Not “they feel stressed.”
Try “they manually copy data between tools 5–7 times per week.”
Not “they don’t save enough.”
Try “they set savings goals but fail to contribute in 3+ out of 4 weeks.”
Anchor to observable actions.
Step 3: Link to Outcome—With Consequence
Not “they’re less productive.”
Try “this causes 2–3 week delays in campaign launches.”
Not “they lack confidence.”
Try “this leads to 30% higher churn in first-year homeowners with mortgages.”
Show the cost of inaction.
Step 4: Make It Measurable
Pick one primary metric that proves or disproves your “why.”
Examples:
- Time saved per week
- Reduction in error rate
- Increase in goal completion frequency
- Change in self-reported confidence (via survey)
If you can’t measure it, you can’t learn.
Real Example From a Shipping Product
“We believe supply chain coordinators at midsize retailers experience delays in shipment tracking because they must log into 3+ carrier portals daily, which leads to missed customs deadlines and late inventory. We will test this by measuring the change in on-time arrival rate for international shipments after we launch a unified tracking dashboard.”
This “why” did three things:
- Focused the design on unified view, not new features
- Gave engineers a clear integration scope
- Let marketing position the product as “fewer missed deadlines”—not “smarter logistics”
The feature launched. On-time arrivals improved by 22%. The team shipped in seven weeks.
No vision talk. No posters. Just progress.
FAQ: Your “Why” Questions—Answered
Q: Shouldn’t the company’s mission be the “why”?
A: The company mission is the context. The product “why” is the application. Think of the mission as the sun. The “why” is the shadow it casts at 10 a.m. on a Tuesday—specific, directional, and changing.
Q: What if our users are too diverse for one “why”?
A: Then you have multiple products—or you’re not ready to build. Even broad platforms like Slack or Notion segment their “why” by user type. For Notion, the “why” for students is different than for engineering leads. Write one per core persona.
Q: Can the “why” change?
A: It should. If your data disproves it, update it. I’ve seen teams treat “why” like scripture. That’s dogma, not product leadership. A living “why” evolves with evidence.
Q: How long should a “why” statement be?
A: 1–3 sentences. If it needs a slide, it’s too vague. If it fits in a Slack message, it’s probably sharp enough.
Q: Do investors care about this level of detail?
A: Early-stage, they want vision. Growth-stage, they want proof. Your “why” is the bridge. Show them a testable hypothesis, and you signal discipline—not just ambition.
Final Thought: The “Why” Is a Compass—Not a Billboard
I once reviewed a product deck where the first slide said: “Our why: To change the world.”
I closed the doc and wrote back: “Cool. Now tell me how you’ll know.”
We shipped a better product that quarter.
The most effective product leaders I’ve worked with don’t lead with slogans. They lead with clarity.
They don’t ask, “What’s our big vision?”
They ask, “What specific problem are we solving, for whom, and how will we know we fixed it?”
They use “why” to say no—to features, to timelines, to stakeholder requests.
They treat it like code: precise, functional, and always ready for a refactor.
So next time you’re tempted to write “to empower users” or “to transform industries,” stop.
Ask instead:
Who exactly?
What are they doing now?
What breaks?
What changes if we succeed?
Write that.
Test it.
Ship from it.
That’s not just good product work.
That’s leadership.