The Hotjar story (part 2) – from beta to €1 million ARR in 6 months
Last year we wrote about how Hotjar went from idea to 60,000 beta signups in 6 months. As we inched closer to the end of the 6-month Hotjar beta phase, we had no idea what would happen once we started asking for payment.
We had just over €100,000 left in the bank after paying salaries for 9 months. I had worked as a consultant during this time, billing clients from the company and not taking a salary myself. I had planned to keep these funds available so we could weather a storm should Hotjar not take off.
Luckily, we were covering our operational costs within two months of stopping the beta. Having seen this result, we had the confidence to invest more personal funds into Hotjar and have a small treasure chest to build the team from. This allowed us to continue building on the success of our beta and ultimately reach €1 million in ARR in just 6 months.
In this article, I will share how the Hotjar founding team:
1. Preparing for Commercial Release
A. Transparency and communication
At the end of the 6-month beta it was clear that we had some very engaged fans using the product. Within the team there was apprehension about what would happen once we ended the beta and started asking for money. For this reason, we decided to be as transparent as possible and communicate the next steps clearly and regularly.
I took responsibility and ownership for the release by planning the stages in detail. We took it upon ourselves to email our users every week, mentioning the end of beta deadline and visually showing what would happen using a timeline.It’s very easy to see things from an internal perspective, so we took the time to stop and think about how our users would perceive the change.
B. One free month
As I started to plan the transition from beta to commercial release, I realized that having a hard stop transition out of beta was not going to work out well. That would mean we'd reach a specific day and start asking for payment.
A lot of our beta testers had helped shape Hotjar and were strong advocates. We did not feel comfortable suddenly asking for payment. For this reason, we took the decision to give all our beta users one free month of usage after the beta ended. In this way, our users would have one month to experience the final product they would be deciding to pay for (or not).
This also allowed us to postpone building our payment gateway by another month (or so we thought — more on this below). At this stage, any extra time we could gain to iron out final bugs was critical.
C. Decision to go freemium
The next challenge we faced was how we would go about charging our users. The original vision for Hotjar was to have an entry plan at $29. We would then offer higher data collection rates to sites with more traffic. Why did we choose $29? We didn’t put much thought into it – we just chose a cheap ‘no brainer’ entry price.
However, the 6-month beta phase had showed us that offering free access to a tool was extremely powerful. It eliminated barriers to entry and helped us spread extremely fast. In surveys we were running, many users told us that Hotjar was way under-priced. But we also had many other users who shared that they had no budget to continue using Hotjar after the beta. During that time, I also read Free by Chris Anderson and Hooked by Nir Eyal.
Given our bold vision—changing the way the web is built and improved by bringing Analytics and Feedback together—we felt that the ‘freemium’ route was the way to go. We got excited about the idea of empowering students, early-stage startups or smaller organizations by giving them access to a solution like Hotjar.
Like many other big decisions we’ve taken at Hotjar, we decided to go with freemium because it was in sync with our long-term vision and our gut told us it was the right way to go. Looking back, it was one of the best decisions we made. The challenge we faced was how to communicate this to all our beta users (who until this point assumed they were using a $29 /month product).
The solution was to create a distinct free plan called ‘Basic’. We decided that everyone on the beta would be placed on our $29 package called ‘Pro’ (later renamed to Plus). This meant that once the beta ended, all our users had one month of free Pro usage, after which they would have to enter a payment method to continue using Pro or downgrade to Basic to continue using Hotjar at no cost.
We made it a point to make this choice very clear to our users. We did not want to upset any fans and early adopters by being unclear. We decided that transparency and regular communication would be key values to us going forward. During this time, we sent weekly email updates and included timeline diagrams showing the steps and timings.
D. Preparing for new users / customers
Ending the beta also meant we had to prepare our site for onboarding new users and customers. However, we were completely focused on ending the beta on the best note possible – so we made the smallest of changes to the homepage and released a super-simple pricing page where our users could signup for the paid Hotjar PRO.
E. Planning and execution
There were also several changes that had to be made to the app. We had to create:
- A new settings page where the plan could be changed, billing method set and billing history accessed.
- An upgrade and payment flow for existing and new users.
- An internal admin page where we could make changes to accounts and plans on behalf of our users.
- In-app and email notifications and a grace period in case of non-payment.
In all these cases, we kept to the spirit of MVP (Minimum Viable Product) – limiting build to the bare minimum, knowing we could always add to and improve once we were live.
Because there was so much to prepare for, we held a team brainstorm that led to the creation of a release plan in Trello. This included all the required steps and assigned responsibility to owners. We then created detailed user stories in JIRA.
F. Shit will always hit the fan
Naturally, not everything went well. A few days before the beta period ended, we realized that the law had recently changed in Europe, requiring us to charge Value Added Tax (VAT) based on the customer’s location.
That’s 28 different VAT rates for each country in Europe!
We knew we could not delay the switch from beta to commercial, so after some quick and crazy meetings with our lawyers and accountants, we compromised by absorbing the VAT charges ourselves until we could collect details and adjust pricing for those who had not supplied us with a VAT number. It was far from ideal, but solving this in a quick and dirty way probably saved us weeks of planning and execution. The transition out of beta was our top priority.
To save time during the last days of the beta, I also decided to simplify our billing by placing customers’ orders as soon as a payment method was entered. I assumed everyone would wait until the end of the month and be prompted for payment.
I was wrong.
Many loyal and happy prospective customers entered their payment details very early on. We were thrilled… but our new paying customers were less elated. They were shocked that we had just charged them there and then.
I quickly took ownership of the issue by owning up to the mistake, addressing it and giving affected customers an extra month of free usage. Our concern for our customers paid off, though. They were delighted by how transparent and accountable we were.
G. Founding members
As we exited the 6-month beta, we also wanted to incentivize and reward beta users who stuck with us and chose to become customers. This led to the creation of the Founding Members page. All beta users who chose to add a payment method and subscribe to Hotjar are recognized on hotjar.com as Founding Members. They also received a badge to display on their sites.
H. Friend referral program
With the beta now over, we did not want to lose the viral momentum we had created with the waiting list. During the beta, a good amount of signups had actually come from referrals, so we figured we had to retain some kind of viral effect.
The beta had also allowed us to learn that there seemed to be two types of people referring friends:
1. Competitive. They were interested in the big prize they had to compete for.
2. Achievers. They were interested in a smaller but safer prize they could get by reaching a set goal.
We decided to repurpose the beta referral engine into our own custom-built referral program, and to have an ongoing public leaderboard based on total referrals. Anyone hitting five referrals over any period of time gets a Hotjar t-shirt, and every month the top referrer receives a lifetime account. This allowed us to appeal to both the competitive and achievers.
I. Financials and run rate
With the first money coming through the door, I wanted to make sure we had a simple but structured model to monitor income and our burn rate. Being only a team of five, I really wanted to keep things simple. I created a Google spreadsheet that showed critical numbers per month: cash balance, turnover by source, categorized expenses and, finally, burn rate and cash runway.
We also set a recurring monthly founders meeting to review the spreadsheet and each line item collectively, to keep an eye on spend, remaining cash, and targets. We found this exercise to be very effective at uncovering key costs (such as hosting), and mistakes in our accounting very early on.
2. Optimizing for Usage
A. Guides and content
As many new users and organizations started to sign up on hotjar.com, we wanted to share our vision of how Hotjar was meant to be used. Since I had extensive experience in design, marketing, and growth (both in-house and consulting), I used my knowledge to create an ‘action plan’ of how teams could get the most value out of Hotjar:
I then converted the plan into a 9-step email sequence, which new users would receive after signing up.
We analyzed usage patterns during the beta to determine the timing and frequency of emails. We ended up sending nine emails roughly every three days over a period of three weeks. While this sounds intense, we knew we had to get new users engaged with Hotjar very quickly in order for them to become active users.
Using the action plan as a basis for all our emails proved to be an effective way to establish thought leadership very early on. Sharing this knowledge also helped our users get a better idea of the value of our ‘all-in-one’ positioning, as we explained how all the elements of Hotjar work together to drive more results.
B. Pricing page
We didn’t have much time to think about pricing at this point: all our efforts were focused on building a great product that our users would love. But now that we were no longer in beta, we had to have a pricing page to explain the plans we offered.
I quickly put together a simple pricing page that focused on the differences between Basic (the free plan), Pro (renamed later to Plus) and Business.
Looking back, we made many mistakes on this page. The terms we used were confusing, prices were probably way too low, and the complex structure of pricing-per-organization made the page difficult to understand.
It also didn’t look particularly good.
This did not worry us, though. We were not prioritizing monetization and revenue. Improvement and usage of Hotjar was our complete focus.
C. Building our ethos
Since the Hotjar founders were still replying to all 27,562 users (including customers), we knew we had to recruit new team members to help, especially since our user base was growing at a steady 10% per month. As we brought on help, we wanted to make sure we kept the same quality, tone, and mindset when interacting with our users.
I put some thought into our mindset and wrote what we call the ‘Hotjar Ethos’ for communicating with users.
It starts by stating that our users are our gods.
This might sound extreme, but our way of thinking was that our users risked their business, job and reputation to use a new tool – so we owed our existence to them. It’s a bold statement that many might not understand, but we believe in a future where businesses will win or lose based on how awesome their experience is – and whether they can truly WOW their customers with their service and attitude.
D. Public Roadmap
We decided to retain the public roadmap we had created for our beta. In the spirit of transparency, we felt that telling our users and customers what we were planning to work on would show that we had a vision, ambition, and will to constantly reinvest into Hotjar.
At first we were worried about giving away too much information, but the decision quickly paid off. Many of our customers told us that the public roadmap had influenced their decision to go with Hotjar. Our planned vision made them feel like they were buying into a solution with future and promise.
E. Money Back Guarantee
A few weeks after the commercial release, we also instituted a Money Back Guarantee. We wanted a complete ‘risk reversal’ for our users, giving them the peace of mind that any decision to upgrade to a paid plan could easily be reversed.
Many businesses would want to quantify the consequences of this decision first. But we had seen this work with so many clients in the past that we decided to just put it in place with a quick change in design and policy.
We also think it’s great business practice as it keeps us on our toes in terms of eliminating issues, and puts more value behind constantly improving the service.
F. Interviews and events
Towards the end of the beta we started receiving requests for interviews and speaking engagements. I had read Delivering Happiness by Zappos CEO Tony Hsieh just a few weeks earlier and was struck by his observation that truly connecting with other humans (whoever they were) had had a big positive impact on his life. He reasoned that you can never know how you will end up ‘benefiting’ from these connections and relationships.
Hotjar was my first experience as a CEO and I felt I should embrace this way of thinking.
I decided to accept every interview request (no matter who it was with or the size of the audience). I also accepted speaking engagements in cities including Tel Aviv and Amsterdam. Most of these interviews and events were being held by our early fans. I felt it was my duty to reciprocate their loyalty and the risk they had taken in supporting Hotjar.
Looking back, this was one of the best decisions I could have taken. Each event led to another invitation, new customers and more fans. Taking dozens of ‘smaller’ interviews was far more powerful than chasing a big-name publication. It allowed me to connect with our fans, users and customers, and build real relationships with many passionate marketers and designers. Today, some of these people are friends, customers and even team members at Hotjar.
Do not underestimate the power of connecting with others. Do this selflessly and you will be rewarded more than you can imagine.
3. Operations and Culture
A. Operations is your backbone
I consider myself very lucky to have worked with Conversion Rate Experts before founding Hotjar. Not only did I become a much better professional, I also had the opportunity to observe and experience how a great company should be run. Ben and Karl taught me the importance of having structure and process.
I also realized how little I had read about running a business. This led me to books like The Personal MBA, Built to Sell and The E-Myth Revisited, as well as other opinion pieces from successful entrepreneurs. As I read, I started to see a consistent theme – investing in documented processes, manuals and training materials was the backbone for building and growing a successful business.
B. Being remote
Having worked remotely for two years, I had fallen in love with the freedom and flexibility of working from home, planning my own days and weeks, and the ability to travel while I worked. I also realized how much more powerful it was to hire the best people in the world as opposed to being limited by location.
With Hotjar, I wanted to share the remote lifestyle with everyone in the company. However, I had seen organizations where remote culture had failed, mainly due to what I call the ‘us and them’ syndrome. In many companies, remote work is introduced at a later stage due to growth challenges, so you have a team based in one location and additional satellite team members working remotely.
To avoid this happening to Hotjar, we created a remote framework very early on. We did it despite being only four team members based in Malta, living a few kilometers from each other.
Looking back, this was one of the best decisions we could have made. We used tools, systems and processes as if we were living in different countries. This prepared us as a team to onboard new team members no matter where they were based – whether it was Malta or New York.
C. The birth of ‘Operations’
i. Team Manual
In preparation for hiring new team members, we decided to create a ‘Team Manual’. This document still exists today and covers everything from the tools we use to how to book time off and how the average Hotjar week is structured. The Hotjar Team Manual will always be ‘in progress’ – it’s an ever-changing document that evolves as the organization does.
ii. Vision & Values
Besides the everyday processes, we also wanted to document why we are building Hotjar (the product and the organization), what our purpose is and where we are headed.
There are two driving forces that led us to create Hotjar.
Firstly, we believe that all organizations should ruthlessly prioritize their users and the experience they are given. Being too focused on optimizing for revenue or aesthetics is not the way to build a long-lasting company. With Hotjar, we want to connect the dots between seeing what your users do (the analytics side) and why they behave the way they do (by gathering feedback).
Secondly, we want to ‘democratize’ the technology behind Hotjar. For many years, we were frustrated by the need to use multiple existing tools that were expensive, complicated and disjointed. With Hotjar, we wanted to create a free tool you could access in minutes – without the need to speak to a sales team.
For this reason, we put a lot of time and thought into formulating the exact wording to use to describe our vision:
“Change the way digital experiences are built and improved by democratizing user analytics and feedback”.
D. First hires
With steady user and revenue growth, it was clear that we had to start thinking about growing the Hotjar team.
I already had some experience interviewing and recruiting team members in a previous role. With Hotjar, however, I really wanted to make sure we built the team the right way early on. I researched and read everything I could find about company culture and building awesome teams.
The book Delivering Happiness had also made it clear to me that we needed to ruthlessly focus on recruiting for culture fit. Having defined our values, we now had to find similar-minded individuals – team members who could be self-driven enough to work remotely without being managed, who were willing to learn, move fast, have a great work ethic and yet still be humble.
To achieve this, we used two tactics: surveys and performance hiring.
At Conversion Rate Experts, I had been hired after completing a long survey. It was an effective way for them to screen applicants. We used this same approach and introduced questions such as ‘What did you learn over the last year?’, ‘What’s the one book you would you recommend to your team?’ and ‘What are your strengths and weaknesses?’.
Asking several questions allowed us to quickly filter out anyone who did not have the drive and patience to fill out a survey (many did not!) as well as quickly identify ‘red flags’ where the applicant had a different way of thinking than we did.
CHECK OUT THE FULL FORM
Secondly, we adopted an approach called ‘Performance Hiring’ (see chapter 8 in Josh Kaufman's The Personal MBA). Rather than just relying on our gut feeling about an applicant during an interview, we paid them to do 2 to 3 days of work for us. We invited them to join us on Hipchat so they could communicate with the team and see how we worked, and we could see their style and quality of work too.
Despite all this, we still managed to make a few mistakes in our first hires. However, having these processes in place allowed us to change the questions we asked and fine-tune the performance task and how applicants worked on it. After a few of these changes, we started to have extremely positive results and the team nearly doubled in size within 6 months.
As new team members joined Hotjar, we wanted to ensure we were transparent and open about how the company was being run. We decided to make our financial overview open to the whole team. We introduced monthly company meetings to report results and financials to everybody in the team.
We felt that, as a startup, we owed it to the team to keep them in the loop about how things were going. They had taken a risk to join Hotjar early on – the least we could do was allow them to participate in the experience.
The decision paid off, as it built trust and allowed the team to better understand and question decisions and leadership.
Since so much was happening and changing with the product and organization, we also introduced a weekly ‘Friday Demo’ session. During this one-hour call, the entire Hotjar team has the opportunity to present everything that has been shipped or released in that week—from a change in product functionality, to a team manual update. This allowed us to all stay in sync, as well as end the week on a positive note.
F. Malta Lounge & company retreat
Although Hotjar had chosen the remote way of working, we still felt the need to have a space the team could call ‘home’.
We rented a 150 square meter office in Malta, and converted it into an open-space lounge by removing the internal walls. We introduced open desks for anyone to use, a lounge, a small bar, a space for video interviews and other startup cliches such as a custom-built wooden table tennis and foosball.
We even added a custom-made Smiirl counter to display the current number of Hotjar customers – updated in real time. We still use this today to celebrate big milestones.
We then invited all Hotjar team members for our first company retreat in Malta, where we spent three days working, bonding and just having fun together.
For this meetup, we had several Hotjar users around the world interviewed about how they used Hotjar and why they loved it. We hired video crews in seven cities and three continents to meet our users and record interviews. I took it upon myself to create a mini-documentary for the team to see what our users had to say (it had been some time since I did video editing so the video was quite raw to say the least).
We realized that by being frugal and efficient in the way we ran the business remotely, we could host a company retreat twice a year and focus more on team building and just having fun.
The 8 Main Takeaways
Looking back at our experience, we have identified 8 main takeaways:
- Be transparent with your users and communicate as much as possible around pricing – especially if you’re exiting a free beta stage.
- If you are targeting a large market, a free offering can be a powerful way to create word-of-mouth and traction.
- If you create a great product, you should ask your users to help spread the word! More importantly: incentivize it.
- Follow your financials from day one. You can keep track of income and expenditure on a monthly basis with a simple sheet.
- Don’t let communication with your customers just happen by chance. Create a guide of how your team should communicate and behave with your users.
- Take every opportunity to talk to your fans and supporters early on – whether it’s an interview or traveling to speak at an event.
- Operations truly is the backbone of your business. Make sure you read about how other businesses have succeeded or failed at it.
- If you want your team to trust you, be transparent with them. Show them how the business is really doing.
Check out part 3 of the series, where I share the lessons learned and mistakes made growing from €1 to €3M in ARR.
In the meantime, I'd love to answer any questions or hear about your own experiences - simply comment below if you have anything to share.