The Difficulty of “Feature Parity”

Icon by Pavel N. from the Noun Project

At first it starts off innocuously. You create an iOS or web app that does really well in the market, and after a while you want to expand to another platform. A list of features in the current app is made, and you get to work replicating them. 6 months later, you’re still not done and your competitor has launched an app on that platform with less features, but more users because they have the first mover advantage. You’re still struggling to complete the first half of your list of features. I’ll tell you the punch line now…

“Feature parity” should not be treated as a hard requirement when building for a new platform or redesigning a product. It’s a risky blanket statement that causes bloat by including all the mistakes you made while building the original product.

Where Does the Requirement for Feature Parity Come From?

The pressure of having to achieve feature parity can come about due to a number of factors. The three below are the most common ones I’ve heard in conversations with other Product Managers.

  1. Competitive pressure against other companies: When trying to compete (especially in a crowded market), it can be a death knoll to release without a feature list that rivals others’. This can happen in industries reliant on high-touch sales orgs (hello RFPs) for revenue.
  2. Internal pressure to maintain equality at release: This happens frequently at larger companies who start feeling like they have something to lose. “What happens if we get bad PR about missing feature X?” or leadership’s requirements of perfection around releases can push a team towards maintaining feature parity.
  3. It’s an easy answer whenever someone asks “why?”: The past history of releases on other platforms can often be treated as gospel for the team, and they fail to ask “why” until they’re too deep in. Once one feature is put on the table for negotiation, then every feature in the release scope can be put on the table — and there are teams that avoid that conversation for fear it’ll open up a can of worms.

Managing Feature Parity During a Product Rewrite

A product rewrite is rarely fun. The base requirement of taking a set of existing features and rebuilding them from scratch means that in order to move customers to the new product, it has to support their existing workflows.

While I was at SendGrid, we rewrote our entire email marketing application with a stronger tech stack and architecture, with the purpose of making it more scalable as we grew our customer base. When I took over the product line, our original version of the app was 2 years old and couldn’t withstand the load we were putting on it. Customers needed robust contact segmentation, but our legacy contact database technology couldn’t handle it.

We faced a problem. We needed to ship a product with underlying technology that would let us compete in the email marketing red ocean, but also all the existing bells and whistles so that existing customers could start migrating to the new tool. There was no way we could get to feature parity in a reasonable amount of time (1 year), but damnit, we were going to start from the highest priority features and try anyway.

Partway through, we realized we didn’t need the feature debt.

You see, feature parity included a lot of feature debt as well: features and UX that made sense at the time, but didn’t perform as well as we hoped. Features that would not have been included if we wrote it today. I started cutting as many of these out as I could to decrease the time estimate, and pushing other nice-to-have features past the v1 marker. My engineering lead Ben and I eventually realized that the project would take much longer than the team had initially estimated a year ago, and started brainstorming “drastic” measures.

We decided on an MVP that would fulfill the needs of the smaller end of our user base and any new user starting out with email marketing. The plan was to ship this and continue iterating towards feature parity from there. We had been so focused on this need to create a solution that would work for 100% of our customers, that we had forgotten about the Pareto principle — we could serve 80% of our customer base with 20% of the features.

From there our marketing team did some magic and voila, we had an Early Access invite-only program that let users opt in at a discounted rate. This program let us test our app out with real users and collect revenue, while continuing to build out our offering. Now SendGrid offers one platform for companies to send both their transactional and marketing emails.

The pressure of “feature parity” disappeared because we proved ourselves wrong — customers were perfectly willing to pay for a product that didn’t have all the bells and whistles.

Defining Scope with Metrics when Building for a New Platform

A new platform is another instance of needing feature parity. Customers have been using your feature set on one platform, and now want to use it on another one. A classic example is starting with web and moving to mobile, or vice versa.

At FullContact we ran into the “feature parity” problem while building for a new platform. The product started on the web, and we had shipped an iOS app in January 2015 that was performing well. Users would often ask when we would build an Android app. With 2 Android developers, we knew we had to reduce scope to get a product to market. We looked at the full feature list of our iOS app and this time checked the usage of each feature. A lot of low-usage features were moved past the “must have” line in the process, which helped us start testing the app with beta users sooner. The beta feedback also provided signal for whether our assumptions about nice-to-have features were correct (if nobody complained about not having them, then we made the right decision).

Bets You Can Make

Being a PM can be like playing poker sometimes — you’re making small bets about your product every day. After one or two of these situations, the levers you can pull become clearer. If there’s low risk in the following bets, then you have freedom to move around.

  • Your product has features that won’t be missed in v1.
  • Customers will still value a product that doesn’t have full feature parity.

How to Cut Down “Feature Parity”

If you do have the flexibility to plan a smaller release, here’s how to do it.

  1. Write out all the features you’d need to build if you were aiming for feature parity. It’s important to start with the full list, and make deliberate decisions about what to remove.
  2. Consider your core metrics. What goals do you need the product to still accomplish even if you release a smaller set of features? For example, if you need the app to make revenue from the start, then you’ll need billing and any features that cause conversion on your other apps.
  3. Start striking out features on your list that a) aren’t part of your core functionality, b) don’t drive [core metric], or c) aren’t used often. A good question to ask yourself is “what’s the worst thing that will happen if this feature isn’t there on day 1?”
  4. Prioritize the list and start working through it. As Alex Le and Kavin Stewart say, “Product management is really just three things: Brainstorm the list, prioritize the list, do the list.” Make sure to de-risk your assumptions by testing the product with your customers along the way.

The thing we often forget when building for a new platform or rebuilding is that the product originally starts with just a few pieces of core functionality. You didn’t start out with all your features at once, and your customers may not mind if you don’t have everything perfect right away, as long as the core functionality works.


** I talk about “core functionality” a few times in this article. By that I mean the functionality your customers come to you for — your competitive advantage.

Found this post useful? Give it a 💚.