Competitive Analysis For Product Engineers

In my experience, most professional software engineers in industry have little to no experience doing competitive analysis. That’s a shame, because competitive analysis is one of the most useful skills that an engineer can have.

What Is Competitive Analysis?

Let’s define competitive analysis as “research and synthesis of existing solutions in the market”.

In bad companies this often isn’t done well. Vague customer asks, sales team musings, and more all combine into a mushy set of requirements that lead to bad products.

In good companies, this research is often done by product managers or product marketing managers and is used to inform initial requirements. Then engineers start partnering with PMs and designers on figuring out a solution.

However, even in good companies, you’ll often find engineers don’t significantly leverage competitive information.

Why Engineers Should Care About The Competition

There are a couple main reasons engineers should care about the competition.

Feasibility/Solution Hints

An existing solution signals feasibility and can point you towards potential solutions. Say you have a question about whether you can build a certain functionality, e.g. can I have my iPhone app detect when users have fallen and not gotten up so we can send an alert to ask if they are ok? If 2 of your 4 competitors already do this, you know it can be done.

This may sound trivially obvious, but there is non-trivial nuance.

Say you’re planning this feature and you estimate it will take 6 months to create. You happen to know that your 2 competitors built this feature end-to-end in 3 months. This information can prompt you to re-check your assumptions. It’s not uncommon in a scenario like this to then find out that, for example, you missed an API that iOS provides that means implementation is much simpler than you were planning.

Competitive insight can also signal infeasibility - if all 4 of your competitors offer feature X with a consistent limitation, that is a reasonable signal that the probability of an easy solution that doesn’t have that limitation is not very high.

That doesn’t mean to not ever try to innovate. But you should have this competitive signal and make clear that what you are doing is innovating if you’re breaking the trend, and you need to know that innovation is difficult and needs to be given the time and resourcing and possibility of failure to be done right.

Engineering Designed Products

Second, it’s not uncommon for engineers to find themselves needing to be able step into the shoes of a PM. This can happen when:

  • You don’t have a PM or PM bandwidth (e.g. early stage startup or employee departures)
  • You’re building a technical product, e.g. an API

When you find yourself needing to actually throw together a complete product, competitive analysis is essential. Absent comprehensive product management, looking at the market can provide engineers with the necessary shortcuts to get to the other side.

Let’s discuss a few heuristics you can leverage when you find yourself in this position.

Heuristic 1: Feasibility

See above. If you’re running without a true product discovery team, the odds it makes sense to truly innovate are very low. Look to the market for what’s possible and strongly consider staying within those bounds.

Heuristic 2: Consistency

Market consistency is a major hint towards where you should be driving things. If 4 out of 4 competitors have the exact same shape of a feature, you should likely just be building something that has that shape.

Beyond the various factors that likely lead to that consolidation (e.g. feasibility), the market has now established a standard. Veering from that can cause confusion for your users. E.g. if all of your competitors have JSON-based APIs that return a common data type as an array, anyone switching to your company would benefit from keeping that consistent. Otherwise, the switching cost increases, to your detriment.

Heuristic 3: Learn From The Best

The final heuristic is to not only consider your competitors but also consider competitors in adjacent markets. Many modern products are a composition of features. Each of those features often have entire industries that exist. You can look to those industries for what best-in-class can be.

For example:

  • If you’re designing an API for your company, you should understand the APIs of your competition, but you should also look at who has the best APIs across any industry.
  • If you’re designing a video system for your product, understand the competitive video landscape, but look to video industry leaders like YouTube for guidance.

Reasons Why People Don’t Do Competitive Analysis

Some reasons why people sometimes lean away from competitive analysis:

  • “Looking at other products will bias my creativity towards what already exists”. This might be ok while you brainstorm. At the point you’re actually ready to build a product, however, you’d better know what the competitive landscape is.
  • Fear of legal repercussions. Without enablement, it’s scary to look at the competitive landscape. Will you accidentally infringe on a patented feature? You should be distilling industry standards vs just doing what a single competitor does. If 80% of competitors have a feature, it’s likely just a part of the industry. Also, you should just be looking at public documentation to do your competitive analysis.
  • Feels like cheating. Looking at the competition can feel to some like taking a shortcut. But guess what - it is! That’s what’s so useful about it. Do you think Toyota would design a steering wheel without knowing what other people are doing for steering wheels?


Knowing the competitive landscape can be a superpower for engineers.