It isn’t enough for product managers and leaders to know what customers want and where the market is heading; they also need a clear view of how competitors move.
Competitive awareness informs positioning, pricing, messaging, and roadmap bets. So its fair to be aware.
But there is a world of difference between studying competition and becoming enslaved by it.
The moment that tests this distinction is familiar: someone in sales, leadership, or the board says, “Hey, the competition just launched X. What’s our answer?”
Today’s newsletter is about what to do in that moment and, just as importantly, what not to do.
Explore some beginner guides and courses:
Basics of Product Leadership (Video Course)
or simply Subscribe and Upgrade to get regular resources and special newsletter posts:
Competition is a powerful signal, but a bad master.
Used well, it helps you identify gaps in your own offering or messaging, understand where the category is evolving, and spot over-rotation in your own strategy. Used badly, it pushes you into building features that your users neither need nor value, fragmenting your roadmap into a reactive list of demands, and losing your differentiation by chasing parity instead of advantage.
Your job is not to mirror competitor roadmaps.
Your job is to build the best product for your users and your business, while staying informed enough to avoid blind spots.
The Three Questions When You Hear “They Just Shipped X”
When the “competitor just launched” message lands in your inbox, pause. Before any roadmap change, run this three-question filter.
1. Does this solve a real problem for OUR users?
This is the first and most important question, and it has nothing to do with the competitor. Ask what specific user problem this feature solves, whether you see this problem in your own user research, support tickets, and product analytics, and how intense this problem is compared to other pains in your funnel or workflows.
There are only three honest answers.
Yes, it’s a strong problem for your users too. In this case, the competitor has likely validated a pain you also see in your data. The feature might already be somewhere on your backlog, or you may simply have under-weighted it. This is a valid reason to revisit prioritization, not because they did it, but because it aligns with real user value.
Second, it’s a mild or edge-case problem. If this affects only a thin segment, or shows up occasionally but not at scale, it likely doesn’t belong anywhere near the top of your roadmap. Tag it, keep learning, but do not let it displace higher-impact work.
Third, no, we don’t see this problem at all. Then building it is almost certainly a distraction. Copying a solution to a non-problem is one of the fastest ways to bloat your product and burn engineering capacity.
The trap to avoid here is the “feature parity” mindset, assuming that if competitors have it, you must too.
Most products are already loaded with underused features. Research shows that approximately 45% of features never get used, and 80% of customer value comes from just 20% of functionality. Another one that doesn’t solve a real problem for your users helps no one.
2. Does this align with our strategy and financial reality?
Even if the feature solves a real problem for your users, that still doesn’t mean you should immediately respond.
You now ask whether this feature contributes meaningfully to your product strategy and positioning, whether it will move your key business metrics like revenue, retention, expansion, or cost to serve, and whether you can afford the opportunity cost versus other strategic bets.
Consider stage and scale.
What makes sense for a late-stage competitor with deep pockets may be completely wrong for a younger product still solidifying product-market fit. Consider focus.
If your thesis is “we win by being the simplest tool in the market,” blindly copying a complex analytics module might directly undermine your positioning. Consider economics.
Some features are margin killers: expensive to build and maintain, but hard to monetize. Just because a competitor is touting them doesn’t mean they’re making money from them.
Your roadmap should be a capital allocation document, not a fear-response log. A competitor launch is only relevant to your roadmap when it strengthens your ability to execute your own strategy and business model.
3. Is this a real capability or just PR smoke?
Not every announcement is what it appears to be.
Many “launched” features fall into at least one of these categories: thin proof-of-concept wrapped in big marketing, highly manual behind the scenes masquerading as automation, narrow in scope but described as category-defining, or technically present but barely adopted by users.
Before you spin up a squad to respond, treat the announcement as a hypothesis, not a fact.
Try to use the feature directly if possible, watch demo videos and onboarding flows not just landing pages, listen to what users say in public channels, reviews, and social posts, and look for adoption and usage signals over time.
Only then can you answer: is the competitor actually ahead, or just ahead in narrative? I
n many cases, what looks like a massive leap is actually a very incremental move wrapped in good storytelling. If it’s mostly PR, the best response may be narrative, not code: clarifying your differentiation, tightening your messaging, and educating your customers on what truly matters.
Four Possible Responses And When To Use Each
Once you’ve answered those three questions, you have four broad moves.
Build the competing feature
Do this when the underlying problem is clearly real and significant for your users, the capability is quickly becoming table stakes in your category, it aligns with your strategy and business model, and you can execute without jeopardizing higher-impact strategic bets. Even then, you should be explicit: you’re not “reacting to competition,” you’re accelerating something that matches your users’ needs and your product thesis.
Build a better answer to the same problem
Sometimes the competitor is right about the problem but wrong or limited in the solution. In that case, take the problem as a strong signal, go back to your users to deeply understand pains and workflows, and explore alternative, differentiated ways to solve it that are simpler, faster, or more native to your product. You are not copying the feature; you are competing on insight and execution.
Consciously ignore it
This is the most underused option, yet often the correct one. You decide to ignore a competitor feature when the problem is not material for your users or segment, it conflicts with your strategic focus, or the economics don’t check out for your stage or model.
Importantly, you don’t just “forget about it”; you document the reasoning. This lets you communicate clearly to leadership and sales why it’s a “no for now,” avoid re-litigating the same decision every quarter, and revisit later with better data if the market shifts.
Monitor and learn
Sometimes it’s too early to tell. In that case, treat the feature as a live experiment being run by your competitor. Track customer interest and questions coming to your own teams, re-check reviews, content, and signals after a few months, and talk to customers and prospects who have tested both products. Your “feature” here is insight. You are buying time and data instead of rushing into build mode.
Letting Your Users and Business Lead Not Your Competitors
The core mindset shift is simple: competitive moves are inputs, not instructions. When someone says, “The competition just launched this,” your default stance should be checking if this matters to your users, seeing how or if this advances your own strategy, and validating whether this is real advantage or just noise.
Your user base, target markets, and financial reality are the only reliable sources of truth for what belongs on your roadmap. If a competitor move fits into that context, great. Use it to sharpen your plan. If it doesn’t, have the discipline and courage to let it go.