It was 9:47 a.m. on a Tuesday. The hiring committee at one of the big tech companies had just finished reviewing the fifth candidate in a row who checked every box on paper—top-tier school, FAANG pedigree, polished presentation—but failed to land. Again.
“Another smart generalist,” said the VP of Product, flipping the packet closed. “They can talk frameworks all day. But when we ask about strategy, they fall back on ‘we prioritized based on impact’ or ‘we aligned with the roadmap.’ That’s not strategy. That’s admin.”
We all nodded. We’d seen it too many times—the candidates who confuse velocity with direction, who treat strategy as a slide deck instead of a decision-making engine. And yet, when we dug into our own team’s recent failures, the pattern was the same: we weren’t distinguishing between tactics and strategy. We had forgotten how to ask the right questions.
So we built a litmus test. Four questions. Not frameworks. Not buzzwords. Just sharp, surgical questions that reveal how someone thinks about strategy when the lights are off and the KPIs aren’t moving.
Here’s what we discovered—and why most product leaders still fail this test.
1. “What Did You Decide Not to Do—and Why?”
We were evaluating a senior PM for a core growth team. On paper, perfect: owned a 30% increase in DAU, led a cross-functional rollout, launched in three markets. During her presentation, she covered every lever—onboarding tweaks, notification optimization, referral incentives. Polished. Precise. Textbook growth playbook.
Then one of the committee members leaned forward. “You mentioned six major experiments. Which one did you kill—and why?”
She blinked. “We didn’t kill any. We ran them all.”
“That’s not possible,” the director said. “You had finite engineering bandwidth. You had conflicting hypotheses. At some point, you had to choose.”
She hesitated. “Well… we deprioritized one A/B test on push timing because we didn’t have bandwidth.”
“That’s deprioritization,” the director said. “Not a strategic decision. Strategic decisions aren’t about what’s low effort. They’re about what’s misaligned.”
Silence.
The truth? Most product leaders don’t make real trade-offs. They manage trade-offs. They say “we didn’t have time” or “engineering was busy,” which isn’t a strategy—it’s a scheduling constraint.
Real strategy begins with subtraction.
At Amazon, the famous “six-pager” process forces teams to articulate what they’re not doing and why. One former exec told me, “If your narrative doesn’t have a ‘we are not doing X’ section, it’s not a strategy doc.” That’s not bureaucracy. It’s intellectual rigor.
In our hiring process, we now score every candidate on what I call the “Kill Score”: how many meaningful initiatives they killed, and how clearly they can explain the strategic reason—not just the resource reason.
For example:
“We killed the social feed MVP because it pulled focus from core search quality, and our data showed 78% of new users dropped off before they even reached feed. We couldn’t win engagement until we fixed discovery.”
That’s a strategic kill. It’s grounded in user behavior, aligned with the north star, and shows a hierarchy of problems.
But hear this: the most counter-intuitive insight here is that the best product leaders don’t optimize—they eliminate. They know that a roadmap full of “high-impact” features is actually a sign of strategic failure. Clarity comes from saying no to good ideas so you can say yes to the right ones.
One of our top PMs recently cut a $2M roadmap item six weeks before launch because new competitive intelligence revealed a shift in market behavior. Revenue ops was furious. But she was right: the feature would have been obsolete at launch. She didn’t just save engineering cycles—she redirected them to a defensive moat that increased retention by 14 points.
That’s not execution. That’s strategy.
2. “Whose Job Just Got Harder Because of This Decision?”
We were debriefing a stakeholder meeting after a major platform redesign. The UX lead was celebrating—“Users are spending 22% more time in the app!”—while Support was quietly fuming. “Calls are up 37%. First-time users are getting lost. We didn’t get any training docs until launch.”
The product lead? Oblivious.
This is the second fault line in product strategy: the failure to map consequence.
Most PMs think about who benefits from a decision. But the real test is: who pays for it?
At one company I advised, the product team launched a self-serve analytics dashboard. Internal NPS jumped 40 points. Engineers celebrated. But sales teams started losing deals. Why? Because prospects used the dashboard to conclude “your product doesn’t support advanced segmentation”—which wasn’t true, but the dashboard didn’t expose those features.
No one had asked: Whose job just got harder?
Sales now had to explain why the dashboard was limited. Customer success had to manage inflated expectations. Support had to troubleshoot UI confusion. The product team had optimized for one stakeholder (power users) while creating friction for three others.
We now run a “Consequence Mapping” exercise in every major planning cycle. It’s simple:
- List every team or role impacted (engineering, support, sales, legal, finance, etc.).
- For each, ask: Does this decision make their core job easier or harder?
- If harder, what mitigation is in place?
The result? One team killed a “zero-touch onboarding” feature because it increased churn among enterprise buyers, who wanted handholding. Another delayed a pricing update because it would overload account managers during Q4 renewals.
This isn’t about consensus. It’s about antenna. Strong product leaders don’t just hear their own users—they feel the ripple effects across the organization.
One counter-intuitive truth: the more internal friction a decision creates, the more strategically significant it probably is. But only if you acknowledge and resource the friction.
At a company like Salesforce or Adobe, where product changes ripple across thousands of customers and partners, this kind of stakeholder consequence mapping isn’t optional. It’s table stakes.
I once reviewed a product spec where the PM had listed “increased support ticket volume” as a feature—not a bug. “We expect a 15–20% spike,” they wrote, “but it’s concentrated in the first two weeks, and we’ve pre-briefed support with scripts and diagnostics. Long-term, this reduces ticket load by 30% by preventing configuration errors.”
That’s not defensive. That’s strategic ownership.
Most PMs avoid this conversation because it surfaces conflict. But conflict isn’t the enemy of strategy—complacency is.
3. “What Does This Make Impossible?”
We were reviewing a candidate who had led a major infrastructure migration. Great story: reduced latency by 40%, cut cloud spend by $1.2M/year, improved uptime.
Then a staff engineer asked: “What can’t you do now that you could before?”
The candidate paused. “Nothing, really. We made everything better.”
The room went quiet.
The engineer said, “That’s not how trade-offs work. You moved from a monolith to microservices. That means slower iteration on cross-service features. You standardized on Kubernetes—great, but now you can’t spin up legacy workloads for edge customers. Every architecture decision closes doors.”
The candidate hadn’t considered that.
This is the third blind spot: confusing progress with preservation of optionality.
Strong strategy isn’t just about what you gain. It’s about what you give up—and whether you did it deliberately.
In venture capital, partners talk about “option value.” Early-stage startups keep their options open. But as they scale, they must close options to build focus. The same applies to product.
Consider Apple’s decision to remove the headphone jack. On paper, a loss: users couldn’t plug in legacy headphones. But it made room for battery, water resistance, and ultimately, AirPods—a $30B business.
Apple didn’t just remove a feature. They made something impossible—wired audio—so they could make something inevitable—wireless ecosystem dominance.
Most product teams never ask, “What are we killing permanently?” They assume every change is additive.
But here’s the insight: the most powerful strategies are defined by irreversible decisions.
At a fintech company, the product team decided to go all-in on automated underwriting. That meant sunsetting human review for 90% of loan applications. The gain? Processing time dropped from 7 days to 90 seconds. The cost? They could no longer handle edge cases—like self-employed borrowers with irregular income.
They chose that impossibility. Why? Because data showed those borrowers represented only 4% of volume but 34% of losses. The strategic trade-off wasn’t about speed. It was about risk profile.
When we evaluated that decision in a post-mortem, the CFO said, “I didn’t love losing those customers. But now we know who our real customers are.”
That’s strategy: using impossibility to define identity.
In our product reviews, we now require a section titled “What This Makes Impossible.” It’s often the most revealing part.
One team wrote: “This new permissions model means admins can no longer grant ad-hoc access. That increases rigidity, but reduces security risk by 60%. We accept that trade-off.”
Another: “By focusing on vertical SaaS for healthcare, we make it impossible to serve retail efficiently. That’s fine. We’re not trying to be Shopify.”
Weak strategies try to keep every door open. Strong ones close doors on purpose.
4. “If This Succeeds, What Other Strategies Die?”
This one came from a former Google X lead during an offsite. We were debating a new AI-powered feature. The PM laid out the case: improves user satisfaction by 18%, reduces support load, differentiates from competitors.
“Fine,” the exec said. “But if this works, what else becomes irrelevant?”
The team looked confused.
He pressed: “If AI can resolve 70% of customer issues automatically, why do you need a 200-person support team? Why invest in chatbot UI improvements? Why build a knowledge base?”
The room shifted. This wasn’t about the feature anymore. It was about strategic cannibalization.
Most teams think in terms of adding value. But the best think in terms of replacing systems.
Consider Netflix. When streaming took off, it didn’t just add a new product line. It killed the DVD business—even though DVDs were still profitable. Why? Because they knew streaming would eventually make DVDs obsolete. Better to kill it themselves than let the market do it.
Same with Adobe. When they shifted to Creative Cloud, they killed perpetual licenses. Revenue dipped in Year 1. But they eliminated piracy, created recurring revenue, and locked in 95% of professional creatives.
They didn’t just launch a new model. They executed the old one.
Back to our AI feature. After that offsite, the team didn’t just build a chatbot. They built an exit plan for human support. Their roadmap included:
- Q3: AI handles 40% of Tier 1 tickets
- Q4: Reduce new hires in support by 30%
- Next year: Reassign 50 support agents to proactive UX research
That’s not cost-cutting. That’s strategic foresight.
The counter-intuitive truth: if your new strategy isn’t threatening an existing investment, it’s probably not strategic.
At one company, the product council killed a “dark mode” initiative because, while popular, it didn’t challenge any assumptions. “We’re spending 6 weeks on aesthetics when we should be rethinking discovery,” the CPO said. “Where’s the system-level impact?”
Contrast that with a team that rebuilt their search algorithm around behavioral signals instead of keywords. That didn’t just improve results—it made their old SEO strategy irrelevant. Partners were upset. SEO tools had to be rewritten. But organic engagement jumped 26%.
They didn’t ask, “How can we do more?” They asked, “What can we stop doing because this works?”
That’s the mark of strategic thinking: it doesn’t coexist. It replaces.
In hiring, we now ask: “Tell us about a time your success killed another team’s project.” The best answers are uncomfortable.
One PM said: “We launched automated reporting. It saved users 11 hours/month. But it made the BI team’s dashboard suite redundant. We worked with them to pivot to predictive analytics.”
Another: “Our new API reduced integration time from 3 weeks to 3 hours. The professional services team lost $4M in consulting revenue. But we redirected that team to build templates and accelerators.”
These aren’t failure stories. They’re strategy stories.
FAQ: Strategy Questions in Practice
Q: How do I ask these questions in a meeting without sounding combative?
A: Frame them as curiosity, not challenge. “Help me understand—what did we say no to here?” or “Who’s going to feel this change most?” Use “we,” not “you.”
Q: What if my team hasn’t made any real trade-offs?
Then you’re executing, not strategizing. Pause. Run a “Kill List” workshop: list everything on the roadmap, and debate what to cut. Force the conversation.
Q: Aren’t these questions only for senior leaders?
No. Junior PMs can answer them too. One entry-level hire aced her interview by saying, “I killed the tutorial video because data showed 89% skipped it, and it delayed launch. We put that time into tooltips instead.” That’s strategy.
Q: How do I balance stakeholder friction with velocity?
You don’t. You resource it. If a decision makes sales harder, give them tools, time, or headcount. Strategy without enablement is just orders.
Q: What if leadership won’t accept that some things must become impossible?
Then you’re not doing strategy—you’re doing roadmap theater. Real strategy requires permission to close doors. Advocate for that scope.
We’ve now used these four questions in over 200 hiring decisions and 40 product reviews. The pattern is clear: those who can answer them concretely—rooted in data, trade-offs, and consequences—are the ones who drive step-change outcomes.
Not incremental gains. Not smoother workflows. But shifts in trajectory.
Because strategy isn’t about doing things right. It’s about doing the right things—and only those.
The rest is motion.