“The Competitor Has It — So Should We” Isn’t Enough

In project discussions, I often hear a sentence like:

“The competitor has it. We should have it too.”

Sometimes, that can point us in the right direction.

But by itself, it isn’t a requirement.

Most of the time, it’s simply an observation.

Seeing a button, workflow, or report in another product doesn’t mean the same thing will fit into our system at the same cost or within the same boundaries.

A Competitor’s Feature Comes From Their Context

Every product grows with its own trade-offs:

• who it serves
• which process it has simplified
• which complexity it has deliberately left out
• which technical debt it has accepted

Even if a feature looks simple on the screen, there are often years of accumulated rules, exceptions, and integrations behind it.

Simply copying it with a “we should have this too” mindset often means copying the appearance rather than the outcome.

These Are the Questions I Ask First

When a competitor reference comes up, I start by looking at a few things:

• What specific problem does this feature solve for the competitor?
• Do we actually have the same problem?
• Do we have the same users, the same usage frequency, and the same level of risk?
• Will adding it strengthen our core workflow, or distract from it?
• If we don’t build it, will we actually lose customers — or will we simply have one less item on the feature list?

If the only answer is “the competitor has it,” that’s not enough to start building.

Visible Simplicity Often Hides a Real Cost

Adding another option or status to a screen can look like a simple task.

But behind it, there may be:

• new business rules
• compatibility with existing data
• impact on other workflows
• additional support and explanation overhead
• cases where something that looks the same for everyone actually requires different behavior

So the question isn’t:

“How many hours will it take to build?”

The real question is:

“Does this change the boundaries and promise of our product?”

Sometimes the Right Answer Is “Not Now”

Following competitors doesn’t mean ignoring competition.

But adding everything we see in their product isn’t a strategy either.

For me, a healthier approach looks like this:

• first, understand our own bottlenecks and our own users
• treat a competitor-inspired idea as a problem to validate, not as a checklist item
• if it’s genuinely needed, build a version that fits our context
• if it’s simply a “nice to have,” put it in the backlog and protect the focus of the current version

Because when a product becomes a copy of a competitor’s interface, we often inherit not their strengths, but their complexity.

The Bottom Line

“The competitor has it” can be an observation.

But a good requirement sounds more like this:

“We have this problem. This solution addresses it in this way. That’s why we need it now.”

For me, this is where engineering begins — not by copying another product’s button, but by making the right decision in the context of our own product.