Q&A: How and When to Add a New Feature to Your App

Keeping your app fresh means constantly iterating and adding new features to meet user expectations. But if you don’t want to waste your team’s time, there are many things to consider before designing a new feature and rolling it out to the masses. Andrius Baranauskas is Director of Product, Pricing and Programs at Booking.com and MGS caught up with him to talk about the path you must follow to successfully add a new feature to your app. Andrius will be exploring this topic more at MGS20 in San Francisco, don’t miss it.

{{cta(‘7f90b853-53cb-4286-a45a-cb093a2603bb’,’justifycenter’)}}

 

Q: Adding new features to an app can be fraught with potential pitfalls, but can pay big rewards if you get it right. When should publishers consider adding a new feature to an app?

A: I don’t think anyone who has a working product has a choice to stop changing it. Products and their features solve users’ problems for only a limited amount of time – sooner or later a new approach is needed, a new offering comes along in the market that does it better, and the needs of the user evolve. It is a never-ending struggle of relevance, and time windows of relevance are decreasing fast.

However, new features need to be added in a thoughtful manner to add value to the business. I believe the very start of the discussion about a feature is quite often a signal of things already going wrong – whenever possible, you should start with a customer problem, understanding the various alternatives to solve it, choosing one, validating it and only then proceeding with execution.

Usually, there are a ton of ideas for new features, and it may be very hard to choose what to build next. It does help to have shared perspective on how you are evolving your product. First, what problem does it solve in the first place, what is the mission of your product or – in case of bigger organizations – your team? Second, establishing a shared vision in terms of what the overall solution looks like in a longer-time horizon – at least 18 months, the further the better. And third, making strategic choices in terms of what are the paths you are willing to take, and whatnot. Establishing how you measure progress towards realizing your mission is important too, as this will help to evaluate different ideas for impact in that direction.

 

Andrius HeadshotQ: What are some of the early questions you can ask to make sure a new feature is warranted?

A: The first question to answer is whether the new feature will make an impact towards solving the problem the product or the team is tasked to solve, and how much it will move the metric that measures the progress towards the mission. It also needs to be clear why it will happen – what are the assumptions behind, and how they related to each other. Stating and documenting them upfront is important, as later it is possible to look back, learn and improve.

Usually, there is a ton of ideas on how to improve your product. That brings us to the next questions – how to prioritize, how to choose what to build next. If you have done your homework and understand what impact you expect from each change, you can combine it with a rough estimated effort. Things that have the most impact and are easy to build go first. The choice between high impact high effort and low impact low effort is harder – it may make sense to go for low impact first, as it helps to build momentum in the team, and then balance between the two. Different ideas often carry different levels of risk, and it may be wise to include it in the equation as well – using risk as a modifier of the impact, discounting it if the risk is very high.

Lastly, it’s best to validate the prioritized ideas before you start building them. There are multiple methods to do that, and it’s rare to find anything better than finding a few users who have a problem you are solving, providing them a prototype of your potential solution, and seeing if it works. A word of warning though – it’s a good way to spot a lemon, but no guarantee of success. Still, it’s worth it, as a lot of time can be saved that would otherwise be used to build a feature that fails.

 

Q: Once you’ve made the decision and are ready to roll out a new feature, what do you need to consider to make sure the rollout is successful?

A: One often undervalued aspect of rolling product changes out is internal awareness of what you are doing inside your organization. The success of the features you build depends not only on design and engineering excellence but on operational support as well. Even more important, securing buy-in from a broad group of people becomes handy to secure the possibility to iterate – it’s not rare that product changes are not an overnight success and take a few versions to finally hit a great result.

Setting up appropriate measurement is an extremely important piece to even know if your feature is a success. This is where the initial assumptions you have documented become handy – you need to make sure that the product change you are making is moving all the levers you thought it would. This will help you understand how you are doing faster by leveraging leading indicators before things are seen in the lagging ones.

And last, but not least, you need to make sure you market your feature so your users are aware and adopt it. This cannot be an afterthought, as slap-on solutions like push notifications or emails are often the least effective ones – you need to build your marketing into your product, making sure users discover the feature in the most relevant flows of their journey.

 

Q: Can you give us an example of a new feature that failed and tell us why?

A: In one of my previous companies, we were exploring a feature that recommends prices to sellers in the marketplace. We came at it from a right angle – trying to ensure the success of new sellers, we saw them overpricing goods compared to experienced participants of the marketplace, and then not being able to sell. We designed a prototype of showing a simple price recommendation and shared it with a small set of users. It failed miserably, as it was clear they did not trust our recommendation. We tried to add more complex data to the recommendation, yet it did not change the seller’s perception. And only when we observed the user behavior deeper did we come up with a solution that was displaying similar sold items and their prices, sellers started to be more receptive to recommendations.

Nevertheless, we still failed. The thing that we missed was whether we actually have a reliable and extensive data model to provide the recommendation itself. We did not, and after a while it was clear that it would take some time to build it. Luckily, we avoided wasting precious engineering time building the solution that would have failed – either because the initial way we designed it was wrong, or the recommendation we were providing were not reliable.

 

Q: Can you give us an example of a new feature that was a hit and tell us why?

A: Here is the price recommendation example again, just a couple of years later. The initial tests and findings were still very useful. When our data solution was finally ready, we were able to ship a feature that affected seller behavior significantly. New participants of the marketplaces have actually started to set lower prices, they received more inquiries and were more successful in selling. This, in turn, helped the product grow and progress towards its mission in helping people sell stuff they no longer need.

 

Q: What can MGS 20 attendees expect from your session?

A: Selecting and prioritizing product ideas is still one of the biggest challenges in Product Management, from junior product managers to product leaders responsible for the whole offering. Although multiple prioritization frameworks exist, they often only help in the short-term.

Having taken over product leadership from CEOs in fast-growing companies, I have naturally gravitated to a framework of establishing a clear structure that helps to select and prioritize ideas by first agreeing why the company (group, team) exists, how the future looks, what are the key strategic strengths we can rely on, and how we measure progress. This, I strongly believe, can ease the life of other product leaders, as well as senior product managers guiding their teams and evangelizing their product decisions in front of executives leaders.

Attendees of this talk will learn how to establish key artifacts behind a strong product team: mission, vision, strategy, user understanding, roadmap and operational compass – as well as how to work with ideas they chose to proceed with, through validation, testing and marketing them to increase their chances of success.

{{cta(‘7f90b853-53cb-4286-a45a-cb093a2603bb’,’justifycenter’)}}