Feature Parity: How to Ruthlessly Prioritise Your Backlog
5 questions product managers should ask when shipping for feature parity
It’s common for startups to launch their product on one platform before expanding to another. For example a company could choose to launch their IOS app before an Android one or vice versa. Whichever platform comes first, product managers are then tasked with ensuring platforms reach feature parity before early adopters churn. Here are 5 questions PMs can ask to ruthlessly prioritise the parity backlog.
Are users asking for it? Why?
Once the product is live on your second platform product managers should be regularly speaking to this new segment of users. Surveys, interviews, and posts on online communities will give a good indication of how the product is doing and the features new users feel they are missing. When users ask for certain features, PMs need to dig deeper to understand the reason why they want that feature. Is it simply because it exists on another platform, or is there a missing feature that is preventing them from getting a job done? By understanding the why behind specific feature demands PMs can shortlist those that will deliver the highest value to the end user and reduce the risk of these early adopters churning.
What does the data say?
Whilst your qualitative data will help you pinpoint key parity themes, the quantitative data will allow product managers to quantify the impact of prioritising specific parity features over others. Product managers can analyse the usage and ROI of these features on their existing platform to help them understand whether it’s worth shipping in the second. For example, if a number of users feel they need a specific feature, but you analyse the data and realise it gets less engagement than another, which one should you prioritise? Similarly, if one feature directly impacts an existing business OKR compared to another, which should you ship first? Analysing the data allows PMs to prioritise features that will deliver the highest business impact. Additionally, this also exposes any features that get low engagement and should instead be removed from the original platform — a simpler (but not always risk averse) route to parity that reduces feature debt.
Do these platform users behave differently?
One caveat to looking at the data available for one platform to help prioritise the features you ship in the next is to be cognisant of the differences between the two platforms and how this can influence changes in user behaviour. For example Apple phones and Android phones are very different and this could influence how users interact with certain features on your product. Product managers should be regularly using the latest product on the latest platform so that they become embedded in the user journey and understand how this could influence differences in behaviour between platforms. Whether it highlights platform specific limitations or benefits, keeping this question and information top of mind will further inform the decision making and prioritisation of the next parity features.
What’s the MVP?
Time is of the essence when you’re trying to get platforms to feature parity which is why it’s useful to break down specific parity features into smaller, shippable increments of work. By working directly with designers and engineers and challenging them to think about what the MVP of larger features looks like, product managers can begin to break down bigger features into smaller iterations that can get prioritised for upcoming sprints and delivered to users much sooner. This approach also gives PMs the opportunity to get further validation to build out the feature fully at a time when they still have little data to lean on.
Does it make sense to build this now or later?
You also need to consider parity features alongside other development work that might be going on. The final question for PMs to consider is whether there is a better time for your engineers to work on this feature. What else is your team currently working on? What area of the code does this feature touch? Does it make sense to work on this now or later when there is more resource? Bringing engineers into this conversation and being willing to question the most pragmatic time for engineers to work on a specific parity feature is the final important piece when prioritising for feature parity and could save valuable development time in the future.
There can be a lot of pressure to get platforms to feature parity before early users churn with the best approach to prioritisation being multifaceted. Questioning the why, the data, the timing and adopting an iterative mindset allows product managers to ruthlessly prioritise the parity backlog and focus the team on delivering the features that deliver the highest value first.
