Here is a comprehensive re-launch strategy of Everhour. Mike and his team re-built a new version of the product after getting sufficient feedback about the first version. These are strategies and ideas they used for their epic relaunch.
Hi there! Let me start by introducing myself. My name is Mike (LinkedIn). I am a co-founder of Weavora company, which was opened as a web development /consulting agency in 2010.
Although outsourcing was our core area all the time, we also tried to launch some own projects, but unfortunately they got neither big success, nor we were passionate about them.
Last year (2015-2016) we started active promotion of our new product – Everhour. Just a few words on it so you better understand the core of next paragraphs.
Everhour is a time tracking system distributed by a SaaS model. If you use Basecamp or Asana in your team, you can integrate timer into your already existing projects. The time tracking button will appear on each of your tasks, you will also get the opportunity to set up estimates and track progress of each team member. Besides, Everhour lets generating highly flexible reports.
We launched the first paid version (as an MVP) in September 2015. After the sufficient amount of users’ feedback had been collected, we started the work on an absolutely new version, which was launched a month ago (Sep, 2016).
In this article I wanted to share our experience of re-launching the product, tell about its stages, ideas, results and mistakes, of course.
1 – “Insights” blog series
Throughout the entire re-launch process, we wrote in public about how we were working on our layouts, architecture and design of the new version. We explained how we want to change the system and why, what new features to add and what old stuff was to be removed. In a very detailed, opened and honest manner.
Why did we do that?
a. We showed the audience that the product underwent constant improvement. So if somebody lacks some feature now, he could suggest it and wait for a new version (in case that we agree with the reason to implement this feature);
b. We were able to validate new ideas on paying users to see the reaction before major engineering expenses;
c. We were able to taught users about new features and concepts in advance;
d. We want to be fully transparent and make our users know that their opinion is really important for us;
e. We get some interesting ideas, which we could never thought by ourselves;
It worked out really well! With each new article we received new emails with questions, suggestions, mock-ups and words of gratitude.
Users left comments in our blog and communicated with each other. We gave them more detailed explanations of concepts and nuances in our support emails.
2 – Early adopters
We suggested our existing users to become Beta testers long before we had it already. We simply placed a sign-up link in one of our blog posts. With a simple step like that, we had more than 100+ loyal companies by the start date.
They helped us a lot. They found some unpleasant moments in the first couple of days, which we unfortunately didn’t catch on our side. And there was no negative at all, even more, they were glad to contribute into the project. It’s likely that we could have another situation showcasing to new users right away.
We simply used Mailchimp to collect subscriptions. We also asked the user to specify the type of integration they currently use during signing-up (Asana, Basecamp, or other). So we built a roadmap and planned releases according to the integration’s popularity.
At first we launched a standalone version on the different domain. And it was mentioned several times in invitation emails and other materials, that the new Everhour version had no connection with the old one. Despite this fact, users tried to login with their old credentials anyway and were confused when didn’t see their data in the new version.
Conclusion: Divide invitees into small groups, consider their first feedback and questions, include into the emails mini-instructions for successful registration. Use Bold for important moments.
3 – Webinars
Soon after beta release we organized a wave of webinars to help early adopters to embrace the essence of the new system and its set-up details quickly.
The registration form was included into invitation emails. The percentage of applications was quite large. But, unfortunately, the number of real webinar members was very low.
Of course we were a little bit upset. Lots of time was spent on its preparation. We stayed till late in the office to adjust to the appropriate time zone, to prepare scripts, demo accounts and email reminders. But it doesn’t pay off to run a webinar for a few people.
That’s why just keep in mind that the number of real comers could be 10 times lower than subscribers. And it is better to think about some additional motivation for listeners at the beginning.
Check how intercom does it. They offer 50% discount for the first month of service.
But that is a good experience anyway. For example we thought that we found a suitable tool for webinars – YouTube Live – but, honestly speaking, we were not satisfied with the sound quality. On our first webinar it was just terrible :( Next time we will try something else. BTW, if you have any advice on it please share it in the comments below.
Besides, we learned that it is great to engage at least 2 coworkers in the webinar. One will show a demo, another one will answer the questions in live chat or social media.
4 – Staying in touch
Beta version was launched with limited functionality. That’s why we wanted to keep in touch with our users in real-time mode, because we were in doubt of its plainness and possible bugs. Also we didn’t want our users to lose their enthusiasm because of communication delays.
So we decided to try Intercom from the very beginning.
We pushed in-app message after each bug fix and new feature launch. Also we set up some automatic messages for user retention.
It was WAY easier to get the right feedback from users when they feel like chatting with a friend in a messenger. We had dramatically higher open rate of in-app messages in comparison to the emails.
5 – Attracting new users
It may be quite interesting to engage old users with the upgraded product. But we obviously wanted to test the system with absolutely new users ASAP: to check onboarding, compare conversion rates and etc.
On the other hand, we were not ready to invite everyone. There were still could be bugs, not all features were ready, plus on the early stage we wanted a limited number of new users, so we could communicate personally with each of them.
Therefore, we created a special banner on our old promo site to engage a limited amount of viewers in New Beta Version. We selected first one integration, and one browser – Chrome. Thus we showed a banner for a specific group who used that type of integration and browser.
We tried to use HelloBar and SumoMe. There was some technical problem during HelloBar installation, so we just switched to Sumome. The conversion rate was quite good. About 8% of impressions were converted into new leads.
6 – Inviting churned users
On the next step we decided to invite churned users, who signed up into Everhour long ago, but for some reasons moved away. We thought if they had not yet found something suitable, potentially v2 could be the right tool.
We segmented our old leads by the company size, roles, registration dates, type of integration, paid/ or not paid. Then we created special type of email campaign for each segment.
As additional motivation we offered them an extended trial (30 days instead of 14).
Of course we were a little bit afraid of being marked as spam, or receiving any kind of “Red Cards”, because those users had already rejected us one day.
We sent emails in small portions, tried different subjects and texts, analyzing the results.
Open rate was quite high 25-30%, but it is difficult to say something specific about conversions yet. Surprisingly unsubscribe rate was under 1%.
Interesting note we made: after using the name of recipient in email subject, the open rate significantly increased.
7 – Migrating existing customers
The new version promised to be in many ways better than the old one. So our ultimate plan was to stop any further development on the first version and do our best to encourage old users’ transition to the new version.
But at the same time we couldn’t migrate old users’ data because of absolutely new product structure (not really good news for them!). We didn’t know how thrilled our customers would be, so we decided to start by writing about it all in honest and detailed manner in our blog and Knowledge Base.
Our proposal was:
a. We offered our users to start utilizing the new version while they reserve free of charge access to all their historical data in the old version.
b. We left the opportunity to save the old pricing for our old-timers. But they can change it in any moment, if new package will be more profitable for them.
c. If somebody don’t want to change the old version for a new one, they could simply continue using it. But they should keep in mind that there will be no new features at all. Just maintenance.
To cut it short, we made a useful conclusion: don’t be afraid of not letting users to migrate the data. In our case, we had no troubles with it.
Just to sum up, we advise you make a transition as transparent as possible for old and new users. Set up trustful communication, collect a base of loyal customers, make experiments by tiny steps and don’t be afraid of anything.
We really hope that our experience will be the cause of your new ideas and might prevent from possible mistakes in the future.
If you have an interesting experience of relaunching the product, or re-engaging churned customers, please share it in the comments below. It could be very interesting.
