“So, tell me about your favorite product that you have worked on in your 10 years of product management,” asked the interviewer. I have appeared for umpteen interviews and this one was no different. And I knew at some point this question would come.
I answered, “Backstage, a fresh content management system that we built to replace an older content management, Comet.”
He asked, “Why is this your favorite?”
To which I replied, “Because this was the longest project I worked on, it went on for two years and the complications and challenges were a juggernaut.” We went in-depth about the product, but the other reason this product was my favorite was that it was a migration project. Migration from an old system to a new system that could handle future use cases.
Migration projects always have one important point of discussion — feature parity. Feature parity is when you develop a product that will replace the product already in place. To do this, you need to make sure that the new product has equal features or else it will harm the user experience.
We had a brief discussion about feature parity since it was one of the core parts of the migration project. In this article, you’ll learn more about feature parity, how to achieve it, challenges you might face, and how to overcome them.
Feature parity is when you ensure the features between two versions of a product remain balanced so that the customer experience isn’t impacted.
At Zalando, we had to make sure that all the features Comet already had were built into Backstage so that the internal users using Comet would be able to keep working as they normally would. This is where feature parity came into the picture. We had to figure out what features Comet had and try to build the same in Backstage.
When we were building Backstage, we had 500 users using Comet. The job of these users was to create content using our content management system. Let’s say when we rolled out Backstage, we missed out on a couple of core features.
That would’ve impacted the entire content production. And in turn, would have impacted the end users. The following are additional reasons why feature parity is important.
If you have feature parity, there will be fewer questions coming to the support team about missing features or inconsistent behavior. This means a lesser burden on the support team especially when the product is migrated to the new platform.
In addition to the reduced support burden, it’s easier for the engineering team to maintain the software. Ask any engineering team and one of the main problems is maintenance especially when the software is complicated and has hundreds of use cases. This is where having feature parity helps.
You don’t want to lose your customers to your competitor because your product lacks features between two different versions. Users expect products to work smoothly and help them do things they use the product for. So if the product doesn’t function as it should, they’ll be quick to move to the next best product.
This brings me to the last point, customer satisfaction. If the users move to the competitor products, it shows the customer isn’t satisfied. Lower customer satisfaction can lead to lower business and in turn, negatively impact the company. In other words, consistency builds confidence.
When I was at Zalando, we also discovered that there were certain features that the users never used. So what was the point of building them again just in the name of feature parity? Not only would it have increased the development time and hence extended the go-live date, but it would’ve also required resources that wouldn’t have led to an ROI.
This is why as a product manager you need to be very cautious of what you’re building and why, especially during migrating or upgrading a product/software. Below I have shared the situations where feature parity isn’t needed:
As a PM you’ll often get into situations where the new platform might not support certain features because of technical constraints. This happened to me while building Backstage. Comet was built on a very old version of Java while Backstage was built on node.js.
And some features were technically not possible to build. So we understood the impact of this feature and depending on this decided to either skip or build it differently.
We wanted to make Backstage much better and more efficient. This is also why PMs need to understand how users are using the features today because it isn’t as efficient as it was yesterday. And in such cases, it’s okay to not have the feature parity.
Comet was built seven years ago and seven years is a long time for the user to change. This happened in our case. During our research, we found out that there were use-cases that the users didn’t use at all.
Hence it was important to understand if it’s important to work on these features or not. After careful consideration, we decided not to build those features at all.
In one instance two of our backend engineers decided to leave the team. This was a blow since it was more of a spontaneous decision from their side. As a result, we had to cut down the features that we were building as feature parity.
Resource availability and allocation is an important factor when deciding the features. As a PM you’ll have to carefully understand the resource allocation versus which features to build as a part of feature parity.
Now that you have a sense of why feature parity is important and some of the cases when it isn’t necessary, let’s take a look at how you can avoid falling into a feature parity trap.
As shared above, we did extensive user research before deciding which feature to build. This included user interviews, looking at the data, and surveys.
User research will give you a better idea about the usage of features which can help you decide which features should be built. It’ll also help you to understand which features to build first.
It’s very difficult to build all the features in the new version of the product especially when it’s a migration project. Because of this, it’s useful to have a plan with an iterative approach and communicate it accordingly to the stakeholders. Iterative development helps to achieve feature parity without messing up with resource and time allocation.
We had a retrospective every month and it helped us gain insights on what the user feedback was and what the team felt about it. It was a space to share thoughts, and ideas and evaluate the progress.
Achieving feature parity requires a systemic approach and there’s no one size fits all. You’ll have to understand the product, its past, and the plans for the future. In fact, even before feature parity, you’ll have to understand if it’s even required. Either way, the following are ways to approach feature parity:
Talk to as many users as you can. If your users are internal users like I had while working at Backstage, talk to the power users (users who have worked on the product for a while). Talking to users will help you understand which features to build which in turn will help you understand more about feature parity. Also, gather past data and understand which features are actively used and which aren’t.
Once you figure out the features and which ones to build, make sure you prioritize based on the impact and the resources available. As shared in one of the sections above, it’s not a good approach to build all the features that are already there in the current version. Instead, you need to understand the impact of each feature and then determine where to allocate resources accordingly.
This brings us to the next point, the iterative approach. At Zalando, we made a yearly plan that was divided quarterly. We had a clear goal for every quarter. We knew that at the end of the year, we would be able to reach feature parity.
One important point here is to also include the testing time in addition to the obvious development time. This is a mistake I made. Also, always include a buffer in the plan to make it foolproof since it’s not always possible to stick to the timeline.
Lastly, documentation. This forms the backbone of feature parity. Having a strong document that has all the decisions listed and the reasons behind them make it easier to create transparency and consistency in communication not only with the users, but also within the team. In my experience, strong, easily accessible documentation can be a big difference.
As a PM, it’s very easy to be lured to build features/solutions in a new version of the product just because they exist in the current version. But since software development has a lot of constraints and also requires continuous customer satisfaction, it’s important to be cautious about what to build and what to skip.
With the addition of AI, there can be some smaller tasks that can be automated resulting in easier ways to reach feature parity, but as a product manager, it’s still important to make sure you are building the right features. What has been your experience with feature parity? Please let me know in the comments.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
Learn more →
