Stop copying your competitors' roadmap
Your competitor ships something. Someone forwards the changelog. Two weeks later it is on your roadmap, and a quarter later it is shipped and unused. That loop is not competitiveness. It is the fastest way to end up with a product that belongs to nobody.
Around 80% of features get built and never meaningfully used. Everyone in product has seen that number by now. And yet the most common way teams decide what to build next is still to look at what the company across the market shipped last month.
I have watched a lot of teams play this game of catch-up. It runs the same way every time.
The catch-up loop
A competitor ships a new feature. Someone on the commercial side sees it, or a customer mentions it on a call. It gets forwarded internally with a one-line message that ends in a question mark.
Then panic does the prioritisation. The feature appears on the roadmap without ever passing through a problem statement. It gets built, because it is now committed. It ships. Users ignore it.
And because nobody wants to be the person who says the last quarter was wasted, the loop resets on the next competitor release.
This is not strategy. It is reactive madness with a project plan attached.
The three sentences teams use to justify it
Every team in this loop has a reason, and the reasons are always one of three.
"We are staying competitive." You are not. You are diluting a strategy that was supposed to say what you are for. Every reactive build spends capacity that was allocated to the thing that actually differentiates you.
"We are meeting market demand." You are creating bloat. A competitor shipping something is evidence that they decided to build it. It is not evidence that anybody wanted it, and it is certainly not evidence that your users want it.
"We are innovating." You are imitating, one quarter late, without the context that made the original decision make sense.
What you cannot see from the outside
This is the part that gets missed. When you copy a competitor's feature, you are copying it with almost none of the information they had.
You cannot see whether it is working. That launch you are reacting to might already be sitting in their 80%, quietly unused, waiting to be deprecated in two quarters. You are reacting to a marketing announcement, not to a result.
You cannot see who it was for. They may be serving a segment you deliberately chose not to serve, in which case the feature is correct for them and wrong for you. Segment mismatch is the quiet killer here, and it is worth being deliberate about who you are actually building for before you copy anything built for someone else.
You cannot see what it cost them. Every feature carries a permanent bill: support, onboarding surface, QA, the migration you will owe it in three years. Not all features add value, but every feature adds cost, and the cost lands on you in full whether or not the value ever shows up.
And most competitive features solve problems your users do not have. That is the flat truth of it. You inherit the maintenance and none of the reasoning.
What good teams do instead
The teams that resist this are not more disciplined by temperament. They have something specific to be disciplined with.
They prioritise from insight, not from stimulus. The question is not "did someone ship this?" but "which opportunity in our own research does this address, and how big is it?" If a competitor's move does not map to a problem you have already found in your own customers, it is not a candidate.
They fall in love with the problem, not the solution. A competitor's feature is a solution to a problem you may or may not share. Extract the problem, throw the solution away, and check whether the problem is real for your users. Half the time it is not. The other half, your answer to it will look nothing like theirs.
They say no to nine out of ten requests. Melissa Perri's argument in Escaping the Build Trap is that the job is killing bad ideas early, before they consume time and energy. Focus is not only saying yes to the important things. It is saying no to everything else, on the record, with a reason.
That last one only works if you have a strategy that can rule something out. If yours cannot, everything stays permanently in scope and every competitor release wins the argument by default. If everything is a priority, nothing is.
The useful way to watch competitors
None of this means ignore them. Competitive awareness is real work. It just is not roadmap input.
Watch competitors to understand the market's direction, to spot which problems are becoming table stakes, and to find the segments everyone is crowding into so you can decide whether to go elsewhere. Treat every competitor release as a hypothesis about the market, and then go and test it against your own users the way you would test any other assumption.
When a competitor ships something and the room starts to move, ask four questions before anything reaches the roadmap:
- What problem does this solve, stated without naming the feature?
- Do our users have that problem, and where is the evidence in our own research?
- Which of our bets does this displace, and are we genuinely happy to drop that one?
- What is the cheapest way to test demand before we commit a sprint to it?
Question four is usually the whole answer. A fake door test tells you in a week whether anyone wants the thing, at a fraction of what building it costs. Most panic features die at that step, which is exactly what should happen to them.
If your roadmap currently reads like a merged changelog of the three companies you compete with, that is not a prioritisation problem to solve one item at a time. It is a missing strategy, and it is the specific thing our Product Strategy Consulting engagement exists to fix: a short list of bets you can defend, and a much longer list of things you have decided not to do.
Sometimes less really is more. The feature you cut is the one that stops costing you every quarter after this one.
.svg)
.svg)
