A Bigger Competitor Just Shipped Your Best Feature. Now What?

A Bigger Competitor Just Shipped Your Best Feature. Now What?

Do nothing for a week, then find out whether customers actually switched. The instinct is to respond publicly and ship something bigger. Both are usually wrong, because a feature announcement is not the same as a feature that works, and a platform shipping version one of your product is not the same as a platform being good at it.

We have watched clients go through this on both sides: absorbed into a platform's roadmap, and doing the absorbing. The pattern is consistent enough to be useful.

Here is the sequence we would follow, and the two things that genuinely change your position.

How Often Does This Actually Happen?

Constantly, and increasingly it is announced in batches. Webflow's own updates page shows what this looks like from the platform side. On 2 September 2026 it shipped five things in a day: breakpoint canvas, components in CMS rich text, visual editing for AI code components, Agent Instructions generation, and Source, described as "now in a limited research preview." On 21 September it shipped MCP updates letting agents "build interactions, filter your CMS faster, and deploy or debug a Webflow Cloud app."

Several of those replace things that previously required a third-party tool or a code embed. Webflow says so itself about components in rich text: until that release, such components "often required third-party solutions or custom code embeds."

That is the modern version of being copied. Not a rival startup building your feature, but the platform your customers already pay for absorbing the job your product does. It is not personal and it is not avoidable.

What Should You Do in the First Week?

Gather facts, not opinions. Three specific things. Read the actual release notes rather than the coverage, because the limitations are usually published and usually significant. Try the feature yourself, properly, on a real task. And talk to five customers who use your product for that job.

The published limitations are where most of the reassurance lives. Webflow's components-in-rich-text release, for instance, states plainly that "components containing Collection Lists can't be placed in rich text," that components in rich text "can't be bound to the CMS," and that "their slots can't be exposed." Anybody whose product covers those cases is not replaced by that release.

Resist the urge to publish anything in this week. You do not yet know what you are responding to, and a defensive post written from a press release is a bad artefact that stays on your site.

Is a Public Response Ever the Right Move?

Occasionally, and it has to come from a position of confidence rather than fear. The best-known example is Slack's open letter to Microsoft, published on its own blog on 2 November 2016 and as a full-page newspaper advertisement, on the day Microsoft Teams launched.

What made it work is that it did not argue about features. It opened with "We're genuinely excited to have some competition," and its central claim was "It's not the features that matter." It argued instead that "building a product that allows for significant improvements in how people communicate requires a degree of thoughtfulness and craftsmanship that is not common in enterprise software," that "tiny details make big differences," and that Slack's teams had "spent tens of thousands of hours talking to customers."

That is the only version of this move worth making: an argument about depth, addressed to your customers, that would read well if you were wrong. A letter that lists your feature advantages ages badly within two releases, which is precisely why Slack did not write one.

Does a Platform Shipping Version One Really Threaten You?

It threatens your easiest customers, not your best ones. Platforms ship the 70% case, because that is what serves the largest number of their users. Your advantage, if you have one, is in the 30% they will not build because it is not worth their time.

The honest risk is that the 70% case was most of your revenue. If your product exists because a platform had a gap, and the gap has closed, you are not going to win that back with a comparison page. That is a strategy problem, not a marketing problem.

So the diagnostic question is uncomfortable and necessary: of your current customers, how many use the depth you are proud of, and how many bought the thing the platform now includes for free? You can answer that from usage data in an afternoon.

Where Does a Smaller Company Now Have a Structural Advantage?

In customer satisfaction, and the evaluation industry has started measuring it that way. Forrester documents that for Wave evaluations kicking off on or after 1 July 2024, "customer feedback will replace market presence on the graphic," explaining that this "reflects Forrester's strong belief in the value of customer obsession," and that "vendors with superior customer feedback will receive a more prominent marker on the graphic."

That is a meaningful shift. Market presence rewarded being large, which a challenger cannot fake. Customer feedback rewards whether the people using your product are happy, which a challenger can genuinely win, and which a platform shipping a version one of something frequently loses.

Forrester also moved to three bands, "Leader, Strong Performer, and Contender," aligned to a three-point scoring rubric. Fewer bands means relative position matters more than exact placement, which again favours a focused product over a broad one in a narrow market.

What Is the Wrong Response?

Racing to out-feature them. You will lose, because they have more engineers and a distribution channel you do not have. Building the next three things on your roadmap faster than planned, in reaction, is how a focused product becomes an unfocused one.

Discounting is the second wrong response. If your differentiation is depth, cutting price says you do not believe that. And you cannot win a price war against something included for free in a subscription the customer already pays for, which is the trap we described in marketing against a free alternative.

The third wrong response is silence toward existing customers. Your users saw the announcement too, and they are wondering whether to stay. Say something to them directly, even if you say nothing publicly.

What Should You Actually Tell Customers?

The truth, quickly, in an email rather than a blog post. Acknowledge the release by name. Say what it does well, because pretending otherwise damages your credibility more than the release does. Then say specifically what your product does that it does not, referencing the published limitations rather than your opinion.

Being generous about a competitor's release is a strength signal, and it is the tone Slack chose. Congratulating a competitor and then explaining why the problem is harder than it looks reads as confidence. Dismissing them reads as fear.

Finish with something concrete: a change you are making, a call you are offering, a date. An email that only reassures is forgettable. An email that reassures and commits gets replied to, and those replies are the input for the win-loss work we described in running win-loss analysis.

When Should You Change Strategy Rather Than Messaging?

When the answer to the usage question was bad. If most of your customers bought the commoditised capability, messaging will not save it, and you have roughly two options.

Go deeper into the segment that needs the hard version, accepting a smaller market with better retention. Or go adjacent, using the customer relationship you already have to solve the next problem in their workflow. Both are real strategies. Both take quarters, not weeks. Choosing between them is the decision we laid out in expanding your market against going deeper.

What is not an option is continuing as though nothing happened while hoping the platform's version stays bad. Sometimes it stays bad. Often it gets better every quarter, funded by revenue that does not depend on it.

What Is the Honest Long View?

If your product can be described in one sentence and built in one quarter, someone will eventually build it, and the platform that owns your customer's account is the likeliest candidate. That is not a reason not to build it. It is a reason to know from the start what you will do afterwards.

The companies that survive this are the ones whose value was never a single feature: they had a real understanding of a specific customer's work, a product with depth in the places that are annoying to build, and customers who would notice if it disappeared. That is exactly what Slack claimed, and whatever you think of the outcome, the argument was the right one to make.

The companies that do not survive are usually the ones that spent the following six months shipping reactively and saying nothing true to their customers. The response window is short and the right response is mostly listening.

If you are in this position and want a straight second opinion on whether it is a messaging problem or a strategy problem, we are happy to talk it through. You can find us at phoenix.studio.