Once your product is available on the market, things are going to get interesting. You’re going to be getting requests from:
- Your users and customer support team who will report bugs and absolutely need them fixed this minute.
- Your users who won’t use your product any more if you don’t build a feature in the next week.
- Your CEO who wants you to build something because a friend of his suggested it would be cool over dinner.
- Your sales team (for B2B software), asking you to build a feature in order for them to make their quarterly sales objective.
Combine that with the features you think are important and need to be added, whether you’re trying to match a competitor or build something new and exciting, and suddenly it will seem impossible to do everything you and your users would like. In this situation, you need to take a step back, remember your product vision and try to clearly identify what is most important to the future of your product. Obviously, it’s a lot harder to do than to write about!
A big part of the internal struggle (that’s a big part of being a product owner) is prioritising new feature development and more optimisation and maintenance based development.
Here are some tips and strategies that we hope will help you make these tough decisions.
Don’t let your users boss you around
The wave of customer-driven product development has truly arrived. From sneaker brands to Doritos chips, companies large and small are using their customers’ input to develop new products. The idea behind user-driven product development is great, because after all, a product is built to serve fill its users needs. However there’s a difference between user-driven development and user-centric development.
As you continue to build your product post-release, you’ll hear from users who are:
- Pleading for a new feature to be added, stating they’d be ready to pay the necessary price to have it included in the product – but there’s nothing to back up their claims.
- Complaining incessantly about an issue they’re having with your product, but who’ll nevertheless keep using it and paying for it.
- Generally expressing frustration and requirements that might be totally unrelated to the product and its uses.
Listening to your users is great, and an important part of being a product owner, but do not put too much faith in your users’ requests and demands, as they might lead you astray.
In his book Rework, Jason Fried from Basecamp explains how they avoid letting users drive their product development. He goes as far as to say that he doesn’t really pay that much attention to user feedback, and that the ideal way to build a haphazard collection of features, rather than a product, is to let your users drive your team’s work. Here’s a quote from the chapter, adequately named “say no by default”:
“Don’t believe that ‘customer is always right’ stuff. Let’s say you’re a chef. If enough of your customers say your food is too salty or too hot, you change it. But if a few persnickety patrons tell you to add bananas to your lasagna, you’re going to turn them down, and that’s OK. Making a few vocal customers happy isn’t worth it if it ruins the product for everyone else.”
His vision may seem a bit extreme, but Basecamp has proven that this way of working can be effective. Being user centric isn’t about fulfilling all your users’ wildest requests, but moreso about listening to the problems they’re expressing and finding solutions to them – with your team. User feedback is a great source of insight, but it shouldn’t become more than that.
Understand a feature’s impact before building another
When you release a new feature, it’s rarely a perfect solution to your users’ problems, even if you tested it adequately before releasing it. You’ll probably hear back from your users about it, and you should take the time necessary to understand a feature’s impact – both qualitatively, by interviewing users, and quantitatively, by using analytics. Beginning to work on a new feature before the previous one has proven a success means you’re not learning from each iteration of your product, so we recommend adding this feature-feedback phase to your workflow.
If you’re working in Kanban, adding an “Impact Achieved” column is a great way to avoid forgetting to follow up on a feature’s success post-release. If you’re working in Scrum, keep a list of your recently released features in a dedicated software dashboard or in your visual management board.
Let Quantitative Objectives Guide You
Still unable to decide whether you should be concentrating on optimisation or building new features? Let quantitative KPIs guide you – every decision you make should be in the objective of improving them.
You can start by using traditional business metrics, such as revenue and profits, to guide your decisions. However, to take your quantitative analysis to the next level, we recommend taking a hard look at the pirate metric framework called AARRR. AARRR is based around measuring five indicators using a variety of metrics:
- Acquisition: Amount of new users you acquire.
- Activation: Amount of users that are onboarded properly and begin using the product.
- Retention: Percentage or quantity of users who are coming back and using your product repeatedly.
- Revenue: Quantity of revenue generated from X amount of paying customers.
- Referral: How many users your current users bringing into the fold.
Keep in mind that every time you decide to either optimise an existing feature, or add another, it needs to have significant impact and move the needle on one or more of these indicators.
We also recommend that you try to understand your user satisfaction qualitatively. There are lots of ways to go about this (for example using Net Promoter Score), but the general idea is to understand if users appreciate your product, and which features they enjoy the most. If you find some features are disliked by a majority of users, it may be well worth considering removing it. Having features in your product that few people use or enjoy can add clutter to your product, making it less enjoyable and easy to use.