Recipes For Product Failure: Obsess Over Competitors

If product management was ever perfected and applied evenly to every single company and industry, we’d likely swim in products that solve all our problems. Unfortunately, good product management is unevenly distributed and often takes on patterns and practices that are very far from optimal. One such patterns is looking at competitors for strategy. You know, why bother understanding your own customers when you could instead look at what your competitor is doing and do that.

Building your product on the shoulders of a competitive growth curve (or, an apparent growth curve) is a huge, horrible, and totally avoidable mistake. Let me elaborate. Building a product while looking at a competitor and their work as a baseline for what your product should do and how it should behave is a mistake that is easy to make and hard to recover from. This is different from being competitor-aware - this is all about competitor-obsessed.

You’re going to encounter this approach in any company. It is usually a symptom of a poorly-run product organization and/or a product team that is not empowered to make the tough calls. In those teams, when folks think about what to build the default is to look at what their competitors are doing in the space and do that, or, if stars align, a slight variation of the competitive feature collection. After all, if they are building it, there must be customers that need that functionality, and if you don’t have it, how are you going to compete against a seemingly better product?

In my experience, product organizations that tend to obsess over competitors instead of trying to solve real customer problems tend to fall into three distinct categories (there’s more, of course).

1. Sales-driven. The sales team is in contact with prospective customers. Said potential revenue-generating folks jump on a call and say “I was doing the side-by-side comparison, and your competitor, ACME Corp., has been making screwdrivers from unobtanium instead of regular steel. How do you stack up against that?” Excited, the sales team runs to the product managers with a laundry list of things that are required to close the deal, including “Making screwdrivers from unobtanium.” Because, after all, they are motivated to close the deal and the deal won’t be successful until they can confidently tell the customers that their screwdrivers match one-to-one to what your biggest competitor is doing - that’s what the customers want, right? In more extreme cases, promises get made to the customer without consulting the product and engineering teams. And when the product team pushes back, this gets escalated to the CFO/COO/CEO and the product team then gets a top-down directive to go and build what the customer asked. Who doesn’t want guaranteed money?
2. Feature factories. Product leadership thinks in terms of roadmaps and feature lists instead of a broader vision for what the product actually enables. Instead of talking about solving customer problems, the conversations always fall back to “roadmaps” and “backlogs,” which result in product managers, engineers, and designers looking for features to build without having a deep knowledge of the market or the customer base. Not that roadmaps or backlogs are inherently bad, but they definitely are when used as a starting point, rather than a by-product of a crisp strategy. Understanding customers, trying to parse out the myriad of data sources is hard. Stack-ranking a list of random features and sequentially building them is easy in comparison.
3. Panicked laggards. Companies that know that they lag behind their competition but can’t easily catch up, so in the midst of the frenzy they assume that the competitor is successful because of a specific feature list rather than because of other, much less obvious, factors. Being afraid to be left behind, they rush to create often a sub-par, maybe somewhat similar feature or product that should theoretically bring new customers to their business.

I alluded to it earlier and it’s worth an explicit call-out again - this is not the same as being competitor-aware. When you’re competitor-aware, the product team knows the market, understands the customers, and is aware of what competitors in the space are doing to address the needs of the customers. This can inform their positioning, how big of a competitive threat the other organizations are, and whether they are tackling the needs of the same or different market segments. It’s good to be competitor-aware. It’s bad being competitor-obsessed.

When product teams obsess over competitors and their features, they make decisions while lacking access to any contextual information that can inform why the competitor is prioritizing specific features, strategies, or product changes. In this case, product teams that look over their competitor’s shoulders have zero clue whether the features being built are actually successful or not, or whether the market they are chasing is responding to them en-masse (and no, Hacker News comments are not representative of “en masse”).

Without contextual information, there are only two outcomes that can happen - either the product team gets lucky, or the product fails. The latter is more common when the product discovery and design process is fundamentally based on what competition is building.

So, how do you counteract this pitfall? To be blunt, as an individual contributor it’s going to be very hard to fight this, especially if the behavior is ingrained in the organizational culture. The only suggestion I have that I’ve seen be effective is - don’t bring a knife to a gun fight. If you’re a product manager reading this, you should be adequately prepared to cover all of the bases of the product you’re working on. Have as much data, quantitative and qualitative, about the market, the customers, and their needs. Be prepared to confidently go into a meeting with your manager, your sales team, and your executives and be able to explain why the suggested direction is not the right one.

If you are a manager, it’s your responsibility to empower your team to seek out the customer insights and steer them towards thinking about customers rather than competitors, all while providing air cover for top-down requests to randomize them with sales-driven feature requests or feature directives from the leadership that have no customer basis.

The job of the product manager is to be the undisputed expert in the product while also being the undisputed expert in the customer base that the product is targeting. Competitors are secondary to that.