How and When to Add a New Feature to Your App?

How and When to Add a New Feature to Your App? (Q&A Article)

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 and MGS caught up with him to talk about the path you must follow to successfully add a new feature to your app.  We have done our research on this talk session and share it here, and we hope you find it useful for your business.

Table of Contents

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 consider adding a new feature?

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.

Q: 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 behaviour 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 of helping people sell stuff they no longer need.

We Hope You Find This Post Useful

If you need further assistance, use the free consultation button below to book a 60-min free professional consultation or reach us out with one of our social media.

Leave a comment

error: Content is protected !!