You can never quite be sure how users will react to new features… it’s a fear we’ve felt in the past, and something we’ve heard from various app owners over the years.
You’ve invested time into something new, whether it’s a seasonal feature or something you’d like to see stick around. Building features is costly. It takes time, resources and money - you want it to work. And, maybe it does! It could be super slick, free of bugs and easy to implement, but your users might still prefer things ‘the old way’.
So, can you actually release a new feature without risking user backlash?
In many cases, the safest option feels like holding it back or soft-launching with minimal visibility. Especially if it’s something slightly different to what your users expect. But honestly, that’s a waste. Of your time, of your investment, and of the hard work of your engineering team.
Alternatively - you can launch with a bang! But then, if the new features land badly, the effects are far more visible and immediate. The last thing you want to see are user ratings drop, reviews getting critical, or dips in engagement. This does happen though, and fairly often.
Of course, poor user experiences can be remedied, but it’s very hard to do so when that feedback loop is unclear. When there’s big noise around a new feature and that feature lands badly, you can’t always know whether the issue was the feature itself, how it was introduced, or how well users understood it.
We recently worked with a client in the gaming space who had concerns about a scenario like this. Together, we approached this problem a little differently.
They had a set of prototype games that, on their own, didn’t have a clear commercial path. They weren’t strong enough to release as standalone products, and there wasn’t an obvious next step for them. But, they were good! Well made, intuitive to use, the product of a really great development team who’d worked hard on their craft.
They wanted to use them, but the big question was whether they could create value - without jarring users who’d gotten used to things a certain way.
Working together, we embedded these prototypes directly into their existing app. But, rather than treating them as finished features, we positioned them very clearly as trials.
That decision shaped everything that followed.
We took the original, basic versions of the games and brought them into full creative production. More importantly, we added structured tutorials so users could quickly understand how to play. The goal wasn’t just to release the games, but to make them accessible enough to generate meaningful feedback.
Alongside this, we introduced lightweight surveys and feedback mechanisms to capture user response in the moment, rather than waiting for them to feedback of their own accord.
Before launch, expectations were modest. The assumption was that we might gather around 1,000 pieces of feedback over the course of a month.
In reality, we reached that number over a single weekend!
We feel this approach landed well largely because of how we managed and communicated the feature releases. Users weren’t presented with a fully formed feature and asked to accept it, we invited them into the process.
By being clear that these were prototypes, the client avoided the usual friction that comes with unexpected changes. Instead of feeling disrupted, users felt involved. And the feedback was reflective of this!
Feedback volumes were significantly higher than expected. Sentiment was overwhelmingly positive, with average ratings sitting at four stars. Commercially, the games performed strongly enough to open up further opportunities.
But, just as importantly, our client gained clarity. They gained direct, structured insight into how their users engaged with the games, and now have a solid understanding of how they can release features like this in future and maintain (or even improve, as in this case) their ratings.
New features often struggle not because of what they are, but because of how they’re introduced. When users understand context and feel included, their response tends to be more constructive. It’s all about relationships. Similarly, on our side, this experience opened up more opportunities for us with that client. We were able to demonstrate that, not only can we provide technical expertise, we can also guide them into making stronger commercial decisions. This opened up further opportunities for us with that client, and our partnership continues to grow.
A good result all round!
If you’re holding back new features because you’re unsure how they’ll land, it’s worth asking a different question:
Is the risk in releasing something new, or in how you release it?
If you were to test something more openly, with the right framing and support around it, what clarity might that give you and your users?
This is exactly the kind of scenario we can explore through our discovery work. Not just how to build or release features, but how to do it in a way that gives you confidence in the outcome.
Get in touch with us ++[here](https://indiespring.com/contact)++ to learn more, we’ll be happy to talk it through.