Competitor launched a feature? Use this response framework

The message arrives in the product channel before nine: a link to a competitor's launch post and one line from the CEO. "Do we have this?"

By noon there's a meeting. By Friday a feature nobody planned sits at the top of the backlog, and the work it displaced has no new date.

Nobody decided the launch deserved a response. The roadmap changed because the question arrived with urgency and there was no process to slow it down. This framework is the process. It takes two questions and about an hour.

Why the first reaction is usually wrong

A launch post is marketing. It's written to make the feature look finished, popular, and important. On launch day you know none of those to be true.

Three facts are missing in the first 24 hours:

• Availability: whether the feature is live for every customer, limited to one plan, or in a closed beta
• Depth: whether it handles real use or the one scenario shown in the demo
• Demand: whether your customers want it at all

Reacting before you have these means reacting to the announcement, not to the product.

The cost of a copied feature is never the feature. It is the work you planned for a reason and then stopped doing.

There's a second cost. A team re-planning after every launch teaches itself to follow. Its roadmap becomes a delayed copy of someone else's, built with less context than the original.

The two questions

Score every launch on two questions. Both have concrete tests, so two people scoring the same launch should land in the same place.

How much does it affect your customers?

This measures demand, using evidence you already have.

Score it high if any of these are true:

• Customers or prospects asked for this capability in the last 90 days
• It came up as a reason in a lost deal
• It removes a step your customers do by hand today

Score it low if the only people talking about the launch are inside your company.

How much does it overlap your strategy?

This measures whether the launch touches a bet you've made.

Score it high if any of these are true:

• It targets the same customer segment as your current top priority
• It weakens a claim in your positioning
• It's an area where you planned to invest in the next two quarters

Score it low if it serves a segment you chose not to pursue, or a use case outside your product's scope.

The four responses

Two questions with two answers each give four quadrants. Each one has a response, an owner, and a time limit.

Log: low impact, low overlap

Record the launch in your competitor log with a date and a link. Tell nobody who didn't ask.

Most launches belong here. Logging is a decision, and it's the correct one for a feature your customers don't need in a segment you don't serve.

Watch: low impact, high overlap

The launch is in your territory, but customers aren't asking for it yet. Don't build. Set a trigger.

A watch item needs three parts:

1. A trigger: the event that moves it to "respond," such as three customer requests or one lost deal citing the feature
2. A review date: 30 to 60 days out
3. An owner: the product manager for the area

Without a trigger, "watch" turns into "forget."

Reposition: high impact, low overlap

Customers care about the capability, and it's outside your strategy. Building it would pull you off course. Ignoring it costs deals.

The answer is in the message, not the roadmap:

• Give sales a clear answer for when a prospect raises the feature
  • Say what you do in its place
  • Say who the competitor's approach fits better
• Update comparison pages and battlecards within the week
• Consider an integration or a partner that covers the need without your team building it

Sometimes the honest answer is that the competitor is a better fit for the customers who need this. Saying so keeps your pipeline full of customers you can serve well.

Respond: high impact, high overlap

Customers want it and it hits a bet you've made. This quadrant is the only one where the roadmap changes.

Responding doesn't mean copying. You have three options:

• Accelerate: you planned this already. Move it up and ship your version.
• Leapfrog: skip their approach and solve the underlying problem in a way their architecture makes hard.
• Match: build parity because the capability has become a requirement to be considered at all.

Matching is the weakest of the three. Use it when the capability is a checkbox in buying decisions, and spend as little as you can on it.

Whichever you choose, name what you're stopping to make room. A response with no tradeoff stated is a plan to do both and finish neither.

The 48-hour timeline

Speed matters less than teams assume. A response decided in two days with evidence beats one decided in two hours without it.

1. Hour 0 to 2: acknowledge. Reply in the channel where the launch was shared. Say you've seen it, who's assessing it, and when the assessment lands. This one message stops most of the panic.
2. Hour 2 to 24: gather facts. Read the documentation, not the launch post. Check which plans include the feature. If there's a free trial, use the feature yourself.
3. Hour 24 to 40: score. Answer the two questions with evidence from support tickets, sales notes, and your roadmap.
4. Hour 40 to 48: decide and share. Post the quadrant, the response, the owner, and the review date. Put it in your competitive intelligence brief as the change that matters.

Three ways the framework gets misused

A scoring model can be bent to justify a decision someone already made. Watch for these patterns.

Scoring impact from inside the building

Internal excitement feels like demand. An engineer admires the competitor's approach, a salesperson forwards the launch post, and the feature starts to seem urgent.

None of those count as customer evidence. The impact score comes from requests, lost deals, and manual work your customers do today. If you have none of these on record, the score is low, however loud the channel gets.

Treating every overlap as a threat

A competitor entering your territory confirms the territory is worth having. It doesn't mean their version is better or their customers are yours.

Read the overlap question narrowly. It asks whether the launch touches a bet you've made for the next two quarters. It doesn't ask whether the two products look similar on a comparison page.

Skipping the tradeoff

"Respond" is an easy answer when nobody has to say what stops. Teams add the response to the roadmap, keep everything else, and miss both dates.

Require the tradeoff in writing before the decision is final. One sentence is enough: what moves, to when, and who has been told.

The launch you didn't see coming

The framework handles a launch once it's public. The better position is to expect it.

Launches rarely appear without warning. Public signals tend to show up weeks or months earlier:

• Job postings for a skill the company hasn't hired for before
• Documentation changes, such as new API endpoints or a renamed section
• Beta programs and waitlist pages
• Conference talks and podcast appearances by product leaders
• Changelog entries for groundwork features with no obvious use yet

Each of these is weak evidence alone. Two or three pointing the same way are enough to score the likely launch ahead of time, and to decide your response before the announcement.

A team that scored the launch a month ago answers "Do we have this?" in one message: what it is, which quadrant it's in, and what happens next.

Score the last launch first

Take the most recent competitor launch your team discussed. Answer the two questions with the evidence you have today, and see which quadrant it lands in.

If the result differs from what your team did, you've found the gap this framework closes. Keep the matrix where the next launch link will be posted.