strategy · hard
"A competitor just launched your feature: what do you do?"
A competitor just launched your feature. What do you do?
The most common failure mode for this question is not ignorance of strategy: it is the urgency trap. Candidates hear “competitor launched” and immediately propose shipping faster. That signals panic, not leadership. The interviewer is testing whether you can separate signal from noise, anchor to users before touching the roadmap, and give a decision recommendation rather than a reaction.
Structure a strong answer
Start with diagnosis across three axes. Present a decision tree. Name the option you’d choose and why. Reserve acceleration as one of four possible responses, not the default.
strong
"First, I'd resist treating this as an emergency until I know it actually is one. My immediate move is diagnosis across three axes: user signals, competitive completeness, and strategic fit.
On user signals: are we seeing actual churn indicators, or is this internal anxiety? I'd pull retention cohorts for the affected segment, check support tickets and NPS verbatims for any mention of the competitor, and if there's a sales motion, loop in account managers for live customer feedback. The data tells me how real the threat is before I touch the roadmap.
On competitive completeness: a launch announcement is not a shipped product. I'd have someone do a teardown: is their version actually usable, or is it v0.1 with a press release? If it's incomplete, we may have a window. If it's polished and well-distributed, that changes the calculus.
On strategic fit: is this a feature-parity threat or a product-architecture threat? If it's a large platform player shipping the feature natively, that's a distribution threat, and the right response is probably to differentiate up-market or find a different moat, not to win on the same axis. If it's a peer competitor, I'd ask: does their version serve the same user segment, or are they going after a different job-to-be-done?
From that diagnosis, I'd bring leadership a decision recommendation, not a panic plan. The four options are: (1) accelerate, if retention risk is real and our version is differentiated enough to win; (2) differentiate the feature so we're not competing on parity terms; (3) deprioritize this feature and invest in a different moat they can't easily copy; or (4) explicitly not respond (a valid choice that requires defending). I'd close with the two or three metrics I'd watch in the first 30 days to know whether our response is working."
weak
"We should ship our version as fast as possible before we lose users. I'd talk to the team about accelerating the roadmap, maybe cut some scope to get something out in the next sprint, and then monitor if users are noticing the competitor's feature. We can always improve it later." This treats every competitive move as equally urgent, skips diagnosis entirely, assumes speed is the only lever, and gives the interviewer nothing on differentiation, user research, or strategic tradeoffs. It is the answer of someone who panics, not someone who leads. It also ignores the possibility that the competitor's version is incomplete, serves a different segment, or actually validates the roadmap rather than threatening it. When the follow-up comes ("why would users switch?"), this answer has no foundation to stand on.
What the interviewer is actually testing
This question appears in strategy rounds at Google, Meta, Amazon, Stripe, and Airbnb. The interviewer is not asking whether you can ship faster. They are checking four things simultaneously:
- Composure under pressure: do you reach for data or for the roadmap?
- Signal vs. noise discrimination: can you distinguish a real switching moment from an announcement?
- User-first reasoning: does your first move involve users, or internal politics?
- Prioritization judgment: can you defend the “do nothing” option when the data supports it?
Senior candidates name the urgency trap explicitly and explain why they are not falling into it. Mid-level candidates describe a process without a decision rule. Junior candidates walk straight into the trap.
The distribution-vs-architecture distinction
Not all competitive moves are the same threat. The distinction that separates senior answers from mid-level ones is this:
When an incumbent platform player ships your feature natively (Apple adding it to iOS, Google folding it into Search), that is a distribution threat. They are not necessarily better at the problem: they have guaranteed reach. The right response is rarely “ship faster.” The right response is to find the job-to-be-done the platform version cannot serve: the edge case they will not build for, the workflow they won’t integrate with, the enterprise configuration they’ll never support.
When an AI-native startup ships your feature, that is more likely an architecture threat: they may be building from a different substrate that is inherently cheaper or more accurate at the core task. Shipping faster does not fix an architecture problem.
The consumer vs. enterprise calculus
Diagnosis differs by market. In consumer products, churn signals can appear in days, switching costs are low, and distribution dominates. In enterprise products, customers are under contract, switching involves procurement cycles, and the threat is more likely at the acquisition surface than at the retention surface. Enterprise PMs should look at pipeline and net-new close rate before worrying about existing logo churn. The question to ask is not “will our users leave?” but “will the next procurement committee default to the competitor?”
The 2026 reframe
In 2026, the race is not winnable on speed alone. Feasibility is roughly free for both sides: a competitor can match your acceleration just as fast as you can ship. The real question is whether their version creates a switching moment, and if it does, what version of this feature is actually lovable, not just functional.
Lovable means the feature meets users where they already work, anticipates the next step in their workflow, and integrates into their context instead of interrupting it. Viable means you can sustain building and improving it at a margin that makes sense. A competitor who shipped something functional does not threaten you unless your version is not lovable. Build the lovable version, or find the moat they cannot copy.
Canonical examples
Instagram’s response to Snapchat Stories in 2016 is the standard case. Facebook accelerated, shipped a near-identical feature, and won because of distribution. Snapchat had product-first advantage; Instagram had network-architecture advantage. Instagram’s response was correct for their actual differentiation, not because shipping fast is always right.
The counter-case is Google+ copying Facebook’s social graph. Parity feature shipping without a differentiated reason to switch led to failure regardless of speed or resources. Diagnosis before action: what is your actual differentiation, and does your version of this feature compound it?
For the 2026 context on why feasibility no longer determines winners, see feasibility is free and lovable, not just usable.