Donald Knuth, dubbed the “father of algorithm analysis”, famously said that premature optimization is the root of all evil: programmers can waste huge amounts of time on unnecessary product features. Feature parity is a situation where this statement typically comes true when product decisions aren’t backed by user data extracted from tools like June.
But feature parity is a concept you’re bound to encounter as a product manager over time. New frameworks, platforms, and services appear every day―it’s only natural for better ways to do things to emerge. In the following article, you are going to learn how to go about feature parity as smoothly as possible, when it makes sense and when it doesn’t, and how you can use it to drive growth―all of it using tangible data and smart mental frameworks.
What Is Feature Parity
Feature parity is used in the context of recreating an existing product offering the same features with more modern tools―programming languages, frameworks, and third-party software vendors.
Say you have an old web application running on PHP with a JQuery frontend, feature parity could consist in rewriting this web application in NodeJS and React to conform to modern UX expectations. The concept applies to legacy software in general, rewritten with a more suitable tech stack or copy-pasted to a new ecosystem (e.g mobile to web).
Why Feature Parity
Feature parity is vital for several good reasons. First, it’s difficult to hire quality developers with aging technologies: in a rapidly-changing industry, nobody wants to feel left behind. Higher salaries is only one of the many job characteristics pushing engineers to hop from one position to another―the prospect of working with newer technologies making your daily work less stressful and more fun is an advantage!
Other benefits of switching tech stacks might be overcoming vendor lock-in or opening your business to new distribution channels. If your power users are avid iPhone users, it makes sense to replicate your web-based product on iOS with technologies like Swift, Flutter, or React Native.
Ditching old ways of thinking brought by legacy software also leads to an increased quality of service. Competition is fiercer than ever: only those who win the hearts of their customers remain. Take frontend development as an example. If your software is designed like some old Windows 95’s user interface with all its flaws and bugs, people are going to flock to your competitors. Customers expect snappy designs built with reactivity and quick loading speed in mind only modern frontend frameworks can bring, released at the speed of light to keep up with new trends and desires.
How To Plan Product Parity
We propose the following 8 steps to reach feature parity:
- Business goals - Assess whether feature parity makes sense for your business.
- Feature audit - Identify your product’s feature profile.
- Removing feature bloat - Simplify your codebase by removing unused features.
- Function & unit testing - Write tests to keep track of your roadmap.
- Product refactoring & rewriting - Pros & cons of cleaning already-existing code vs programming from scratch.
- Production-ready vs feature-complete - Why you can’t wait for total feature parity to launch.
- Development lifecycle prioritization - How to prioritize web and mobile development efforts to reach parity.
- Product release strategy - How to keep backward compatibility with legacy products and onboard customers in the process as early as possible.
Without further ado, let’s dive into each part in detail.
1. Business Goals
Feature parity is great for many reasons, but it can also kill your startup if it’s done prematurely or incorrectly. Before considering how to go about feature parity, you need to have your business goals figured out:
- What are your KPIs? Pick one main KPI and two or free supporting KPIs.
- Will feature parity support your main KPI? The expected impact of feature parity on your business strategy.
Do you even need feature parity at this point in time? A study by Failory indicates that 90% of startups fail, with absence of product-market fit representing 56% of all failures. If retention is your main KPI, you need to work on finding a scalable business model first―spending resources on optimizing the same product is a luxury you probably cannot afford and feature parity becomes an enemy.
If your retention looks good and you consider yourself past P/M fit, feature parity is worth considering and you should keep reading. If you don’t know where your business is on the spectrum, consider using June to calculate your DAU/MAU ratio or your churn rate, both acting as useful indicators of retention.
2. Feature Audit
Feature parity implies performing a feature audit―listing down the software features you need to recreate as user stories. Three important items to add to your to-do list:
- Identify your features using a product analytics tool
- Assess feature usage by customer segment using feature audit reports
- Talk to your users to better understand their needs
A feature can be defined as a series of in-app events: the click of a button, hovering a cursor over an image, etc. Let’s say you have a feature consisting in exporting data stored in a web app to Excel―you could measure this feature’s usage by tracking each click event on the Export button. SaaS product analytics tools like June.so help you do exactly that in an automated fashion:
You can then track how features are used by your customers using retention reports. With this tool, it’s easy to understand how well your users are engaging with existing features. Try to reach feature parity only for the features with a high retention
Finally, you can look at your daily active user count per feature to identify which users are more likely to help you better understand how to correctly port your feature to your new stack.
3. Removing Feature Bloat
You now have a list of features you can re-create, but what if you don’t actually need all of them? Feature parity doesn’t have to be a copy and paste of your previous product: new technologies bring new opportunities―it’s a chance to start again from a clean state.
Consider removing features you don’t need from your list. Feature creep is the result of past product management mistakes making your product too complex and heavy to use. Bloated software not only takes more resources to develop, but also leads to lower quality of service.
In summary:
- Perform a feature adoption audit
- Rank your features by usage
- Prioritize core features and consider removing unused features
4. Functional & Unit Testing
Now that you have a fixed set of features you need to build, it’s time to write a series of tests to make sure you’ll reach your development goals on time and on budget without losing track of what matters:
- Write unit tests
- Follow up with functional tests
- Monitor the adoption of the reworked feature with June's Feature Release template
- Monitor your features in production with a regular feature audit check
As in a regular development lifecycle, you should start with simple unit tests before jumping into functional ones. Unit tests will make sure the smallest pieces of your code work as intended, while functional tests validate desired feature milestones.
By following a test-driven development methodology you can set clear expectations on the project and its deliverables. As soon as your code hits production, you can run your product through another feature audit to monitor adoption as well as measuring the adoption after the release. Low adoption can mean something is wrong with your feature―a bug might prevent users from accessing the feature.
5. Product Refactoring vs Rewriting
Re-organizing your current codebase can make it easier for developers to build on top of the original code or fork it to another tech stack. If refactoring your code can remove the need to have two different codebases to reach feature parity, you’ll save a lot of costs down the road.
For example, let’s say we are moving a dynamic website using PHP and JQuery to a modern NodeJS and React codebase. Typically, JQuery calls PHP functions through an API call and updates the website accordingly. Instead of rewriting the whole website in one-go, you could:
1. Refactor your PHP code into backend and frontend parts - the backend part is responsible for API calls, while the frontend part renders HTML documents
2. Replace JQuery with React and tell your reverse proxy server to only use PHP as an API server. A NodeJS program will output HTML from a server-side rendered React app.
3. Replace PHP with NodeJS entirely
By re-architecturing your codebase to find platform-agnostic parts, you can make the process of reaching feature parity smoother. Refactoring is generally quicker than complete rewrites because the scope is smaller, so it will allow you to produce user-facing code sooner to receive feedback on your work.
If you have the resources, performing a full rewrite from scratch can be simpler, cheaper, and more performant to use in the long run than a Frankenstein product―but once again you need to take into account that it will take more time to reach the market and you will eventually run into a new set of bugs. You’ll still need to maintain your legacy product as well.
6. Production-Ready vs Feature-Complete
Even though you already have the end-product in mind, it’s always safer to use a rapid experimentation approach, so find a way to focus on production-ready software rather than feature-completeness. Ship a minimum viable product as fast as possible to test your hypothesis and reassess your plan.
- Better done than perfect, don’t obsess over feature-completeness
- Consider whether feature parity will hurt your engagement or not―if you want your users to prefer a version of your product over another, make your favorite version more feature-complete
- Use cohort retention analysis to drive product decisions
Pure feature parity is overrated. In fact, some apps offer varying user experiences from one platform to another. Take Instagram for example. The web version is obviously inferior to the mobile app in terms of features, because even though users want to use Instagram on the web, Meta’s strategy is to keep users on their phones to keep engagement KPIs higher―feature parity would prevent that!
You also want to take into account your customer segments in your roadmap strategy. Your product is production-ready when your expected audience has all the features it needs. If you are moving from a mobile-oriented tech stack to a web-oriented tech stack, you’ll want to cater to the usage and needs of your web users. You can do this by analyzing your acquisition cohort by device usage for example, or any other type of cohort that fits your target audience.
7. Development Lifecycle Prioritization
Whether we are talking about a web, desktop, or mobile apps, command line interfaces, or IoT hardware systems, modern tech products can be divided into 3 main components:
- Start with Databases - Where you store data.
- Move on to the Back-end application - Server programs to manage the data.
- FInish with the Front-end application - Web pages and scripts running in client terminals to interact with the data.
Everything starts with a data schema: choosing a database system heavily impacts both front-end and back-end development. If you transition from SQL (sqlite, MySQL, Postgres) to NoSQL (MongoDB) or vice-versa, you’ll need to think differently about data and adapt your ORM / ODM library to access it. Nowadays, databases aren’t limited to web servers and also live within end-users terminals, like IndexedDB in web browsers or sqlite on mobile. If your feature parity efforts involve a database change, you’ll need to think of a data migration plan for a seamless integration in your new tech stack.
You can then proceed to back-end development―writing web services accessed over APIs, rendering engines, and coding the data access logic. If your web app or website is server-side rendered, you’ll need a templating engine. If you prefer a JAMstack architecture, you’ll need a static site generator. How you render the data and serve it impact the way the front-end is built, so start with the back-end before going into the front-end.
Once you know your API endpoints and your rendering method (SSR, SPA, hybrid rendering, etc.), you have all you need to finish the front-end side of product building. For web developers, Storybook is great to build UI components and pages in isolation for easier development, testing, and documentation. A tool like Storybook is a good compromise between a mockup and a full-blown SPA that will allow you to focus on design and your product’s micro-copy without waiting for backend developers to finish their part.
8. Product Release Strategy
How you release your product can make or break your feature parity efforts:
- Aim for backward compatibility - provide a seamless transition to your new tech stack to your end-users
- Provide beta access - don’t wait for full feature parity to get feedback from your power users
Your legacy product doesn’t have to disappear completely: when it makes sense, you can ensure backward compatibility with previous versions. Take Twitter’s API product for example. You can use the first and second version of the API freely without having to worry about future product rewrites. Versioning is a powerful tool to make feature parity smoother for your end-users.
Before launch, you can also use feature parity as a marketing tool to better understand your users’ needs. Beta access is a great way to reward power users while receiving early feedback―again, you don’t have to reach full feature parity to release your new product. Superhuman did a stellar job at onboarding customers before even finishing a first version of their product, and the hype generated by their marketing campaign is largely recognized as one of their main success factors. Apply the same techniques and you’ll reach a production-ready state sooner at lower costs.
Use June For Feature Audits
Understanding how your users interact with your product’s features is vital for successful feature parity development. And for a complete feature audit you’ll need a quality product analytics tool that can collect data on a variety of metrics like feature adoption, engagement, and retention that are hard to put together otherwise.
June.so can automate this process to find your most valuable features, reduce feature bloat, and understand who your power users are.You can enable these tools by connecting your Segment account to June. Segment by Twilio is a platform for aggregating your product usage data in a single intuitive dashboard. With Segment, you can integrate user metrics from hundreds of software tools like Google Analytics or Stripe with the push of a button. Combined with June, you can generate beautiful actionable reports on your feature usage. Get started today with accessible product reports at June.so.
