How to nail your next big product launch
When building products, you need to work with laser focus on the problem you’re trying to solve for the target customer you want to capture next. What often gets forgotten in this process is that you run at risk of harming the experience of previous early adopters.
The importance of power users
At Freeletics one of our hardest challenges is: If we build a great product, the product that served the user’s needs 6 months ago might not do the trick for them anymore today. Why? Because our goal is to help people build and maintain a healthy, active lifestyle — so the problems they’re facing are ever-evolving and changing, and we need to build a product that supports this complex, nuanced journey.
But — we were not always aware of this challenge.
In the early days of Freeletics we built a very tough product that addressed a very tough target audience. According to our mission, we wanted to do more — to help more people — which is why we decided to focus on helping users who don’t have a training routine yet. Going down this path, achieving great outcomes for these newcomers, we realized too late that the changes we were making were actually harming the experience of the very tough early adopters.
We had people being outraged on facebook as to why their favorite workout was removed or sending us multi-page letters explaining why they would stop training with. They were disappointed that the Coach didn’t assign them workouts anymore that made them unable to walk for three days. Even if this sounds crazy, Freeletics is an extremely emotional product. It changes people’s lives. And these people felt like we were betraying them and not at all getting what Freeletics is all about.
You may think that these power-users form only a fraction of the total user base and therefore it is possible to have much greater impact when addressing the bigger share. The problem however is that those users are the advocates that others follow to the product, the multipliers — and you have to meet their needs to keep them engaged. Otherwise you’ll harm organic growth.
Your organic growth will suffer if you lose momentum with people that were once excited about your product.
Understanding the changing user needs
To address this problem, we needed to re-learn how to do user research and product experimentation to make sure we build the right product for the right audience. Working on the core product experience, we had to ask ourselves these questions:
- What are the needs of people that get started and how can we help them to do so?
- What are the needs of people that created their own and unique routines with our product?
- And most importantly: how can we make sure that new users have a great experience while the early adopters are not dissatisfied at a minimum and excited at best?
Some of you might now think “you need to decide which user group to focus on!” — but that was our mistake in the first place. Most product advice goes exactly in the direction of focus-focus-focus and I believe this is right and we need to focus on the problem we want to solve. However — this should never lead to accidentally excluding an important user group. And sometimes this just means you have to consider and balance different needs to be successful in the long run.
Our reality at Freeletics is, that, if we do our job right, the needs of our users will fundamentally change over their journey. They will use the same product they grew close to for different purposes. What we did in the beginning was to focus on new users while neglecting the early adopters. We wanted to do better.
Creating a suitable validation process
In order to achieve better, we needed to get creative in our validation to answer the questions above. Before, we were doing a lot of tests with beginner users because that was the audience that we targeted with our changes.
But now we knew that we needed to go one step further and include people that have very strong opinions — therefore we adjusted our process from only the first step to span over the following four steps:
- New users — people who have never been in touch with the product since this is our main target audience for the change
- Our own employees — many training actively, easy to access. They will bring the biggest concerns out directly, however, they are close to our vision & mission and potentially not as sceptical.
- Our ambassadors — the users that are the closest to us as a company. They are with us for a long time and are the most active users. We received invaluable feedback from them. However, we were still not satisfied and went on to stage three
- Our very vocal power users on Social Media — we have a lot of groups on facebook with very active, very critical members. So we thought: It doesn’t get worse than their feedback, so let’s give it a try!
And what can I say.
The feedback, especially of that last group, is disillusioning and scatters your hopes and dreams as a product person.
Which is exactly why you need to hear it. These people will tell you the ruthless truth about all the things that are wrong with what you’re trying to build. And you need to be the person to know.
Reflect learnings in your product decisions
This doesn’t mean that you should now throw all the newly built ideas away but rather that you can now be fully prepared.
When doing new product iterations, we follow exactly this process. With the insights we receive through all of the user feedback rounds, we are able to reprioritise the work we’re doing. We make sure to mitigate parts of the risk through including features that we found are very crucial to power users (but not necessarily new users) in the release.
Of course you can’t include all of the things into the releases — you still need to be fast. And you also don’t want to stop after your first wave of gathering qualitative feedback — you want to continue validating on the way.
A case study
This validation of course doesn’t always look the same, is extremely messy and for sure not linear. It’s essential to get creative — which is why I want to bring an example of how we successfully went from first validation to launch on a recent very big product change with a lot of risk.
After gathering the bulk of learnings through the first clickdummy tests (with the different user groups as described before) we had a good idea of the general direction. We then actually built a very, very rough live-data prototype that was usable and then shipped it to our internal users. We then gathered feedback on how it feels like when using it day to day while continuing to build the experience.
Once we had enough insights from them, we continued bringing an improved version of this to our ambassadors. We later sent them a survey including questions based on assumptions and hypothesis we had around them liking or disliking certain features. One of our core assumptions was that they would have a fundamental problem with the general strategic direction that we wanted to go towards — and we wanted to find out if this was true or how we could build our way towards our vision without harming their experience.
After having gathered enough input there, continuing to bring the experience to a presentable state, we launched an early access program to a share of our early adopter users. They were given the option to try the new experience and share their opinions afterwards in another survey.
And last but not least, we also launched an A/B test to completely new users to ensure that the changes we were making wouldn’t have a negative impact on our key metric.
After gathering all of this feedback and validation, we knew perfectly well what we were up for. We knew exactly what the issues with the experience were and had to make a call: would we launch knowing that some things wouldn’t be ideal?
We decided to go with the launch but building in some safety nets. The first one was to allow users to opt out of the experience. For a limited amount of time, we would give them the option to still use the old experience instead of the new (of course, we ask people who opt out for feedback!). A second one was to plan for an extensive launch communication to really make sure we informed our users of these changes. In this we put the spotlight on features we knew would be important to them. We went out of our way to make sure that these users feel we understand them, that we provide them options and that we work hard to address their issues so that they feel heard.
With this approach, we were able to launch this huge product change very successfully. Of course not all people loved everything about it — but we were prepared for the feedback to come, to channel it properly and to react quickly.
The process in short
To sum it up, if you have a big product change upcoming, this is how I recommend to appraoch it:
- Be focused on your target user and the problem you want to solve for them
- Identify user groups affected by the changes you’re planning to do
- Plan different stages of user testing including users from all groups (and be creative!)
- Consciously decide what to mitigate in the product and what not
- Build a launch communication strategy that addresses the remaining negative points
.. and finally, launch successfully and without any surprises.