The Hotjar story (part 1) – from idea to 60,000 beta signups in 6 months

We were completely wrong.

With Hotjar we did things differently. Especially since the toolset was more complex than any other tool we had built before. Hotjar is a solution that allows marketers and designers to see how visitors are using their site pages by connecting the dots between analytics and feedback. Think Clicktale meets Qualaroo. It includes heatmaps, session replays, feedback and surveys.

My domain expertise in this area (I worked with and consulted startups and global brands for 10+ years) was a huge advantage, as it gave me a very clear vision of what Hotjar would do, how it would be different, and the value it would generate to specific personas (I am the typical Hotjar user!).

From day one we planned to release the smallest and simplest viable version of the tool, collect feedback in a private beta, while quickly improving it with small continuous changes. Here is part 1 of the journey on how we made that happen...

In this article I will share how we:

• Prepared for the Hotjar Beta and validated feasibility in just 2 months

• Spread the word about Hotjar and reached 60,000 signups

• What we achieved and learnt during the beta

1. Preparing for the Hotjar Beta:

A. We checked ‘team fit’.

To build Hotjar I reached out to the best people I had (already) worked with in my career. I figured the founding team had to be ‘best in class’ and ideally would have worked together before. However, to make sure there was good fit between us, we decided to build a simple tool called ‘Prioritizr’ – a team-based brainstorming and prioritization tool.

In 2 weeks we built a fully functioning tool that we could use ourselves. This allowed us to quickly verify that the team would work well together. This ‘test run’ also allowed us identify any changes we needed to make in the way we worked by starting and completing an entire project (even if a tiny one) in a short time frame.

B. We made sure the idea was viable.

Once we had defined the vision and feature-set of the tool, our engineers Erik (backend) and Marc (frontend) set off working on the ‘base technology’ – in other words the core functionality required to make Hotjar work. This meant building the ability to record visitor activity (visits, clicks, scrolls, keystrokes) on a page and visualizing it in different ways.

We made a decision to not be too concerned about company name or incorporation at this point. To us these were just distractions that could be tackled at a later stage.

We also wanted to make sure that this could be achieved at very high scale and at a cost that could support free / low pricing. The reason for this is that our vision is to “change the way the web is built and improved by democratizing user analytics and feedback.” So doing it cheaply was a big requirement for us.

Within 4 weeks our team established that the concept was technically viable. At this stage Jonathan (Product & UX) started working on the user experience of the admin and visitor facing widgets. One of the main reasons of doing this was to be able to visualize the end product as well as start showing it on our site as quickly as possible.

C. We defined the ‘bare minimum’ needed to collect feedback.

Knowing that our vision of Hotjar was possible we realized we had to clearly define the minimum requirements for each feature. Since Hotjar is a complex toolset we focused on building only an MVP – a ‘Minimum Viable Product’. In other words the bare minimum required for someone to use it and get value out of it. Jonathan used his Product Management skills to put together a detailed outline document of what each feature would do and the acceptance tests each had to fulfil before it would be released.

We reviewed this outline document multiple times – at each review thinking of how we could simplify the functionality further. Once this process was complete we set some high level estimates of how long it would take to build and test the entire MVP. We decided on a 6 month period for the beta program.

D. We set up the basic tools and processes needed.

At this point we knew we had to get organized. We chose Hotjar as a name, incorporated and personally funded the company. Our first expenses were the tools required to get organized – Jira, Hipchat and Google Apps (for Business).

It’s interesting to point out that it was only at this point that we chose the product and company name, purchased a domain and setup a legal entity. From our previous experience we realized it was easy to lose focus and waste time by working on these things too early on.

Using an agile project management approach, the MVP document was then translated into separate ‘stories’ or small units of work which were added and prioritized in Jira. We then decided to break down work into weekly ‘sprints’. This means that at the beginning of each week we prioritized and estimated what we could complete in the upcoming days. Once the week ended we would stop to reprioritize, estimate and start another weekly ‘sprint’. As soon as anything was completed, we released the update. This simple and iterative approach to building Hotjar allowed us to be very fast and responsive to changing needs or issues.

2. Spreading the word about Hotjar:

A. Sell it while you build it!

While Hotjar was being built, Johan and I got busy working on the Hotjar home page. Our plan was to give visitors a ‘preview’ of Hotjar and offer visitors the ability to signup for early access to the beta version. We figured that since it would take weeks and months to build and perfect Hotjar we had to involve users early on to get feedback and spread the word. From previous projects we had learnt that waiting to finish the product and then releasing was a bad idea. Collecting feedback so late would lead to big changes or potentially spending a long time moving in the completely wrong direction.

• 6 months of Hotjar free when referring 5 friends

• A Hotjar t-shirt to the top 200 positions

• A free lifetime Hotjar account to the top 20 positions

We saw this challenge as an opportunity. To give us control and create more demand for Hotjar we created an early access ‘waiting list’. As soon as someone requested access to Hotjar (entering an email on the site) we would put them at the last position in the list e.g. position #900. We would then ask users to refer Hotjar to their friends using a unique signup url. The more friends you refer the higher up they would move in the list. We also offered several other incentives:

Since we decided to build an MVP, one of our biggest challenges was to build a system that would work for a handful of sites and then slowly scale up the infrastructure as we onboarded new users. For this reason, it was clear that we had to control the rate at which new users joined Hotjar.

We also made it very easy for visitors to share Hotjar with their friends by adding links to automatically share on Facebook, Twitter, LinkedIn or simply send their link via email.

This had a twofold impact:

1. It generated scarcity and demand since Hotjar was not yet available.

2. It created a fun and competitive environment for early adopters that were eager to get early access to Hotjar (and our awesome gifts).

This fuelled word of mouth, which in the end was responsible for 60% of the signups we received throughout the entire beta phase.

At the same time we also took the opportunity to use the Hotjar toolset on our own pages:

• We used polls to discover where our visitors had heard about us – allowing us to uncover numerous new channels to promote Hotjar.

• We used heatmaps to see how our site was being used. We tweaked copy and functionality to address UX issues.

• We used recruiters (a feature we have since discontinued) to bring users onto Skype for remote users tests (the team would watch them sign up to Hotjar or use a feature).

• We used surveys to collect feedback from users while they were still waiting in the free access queue – addressing key needs and learning more about their backgrounds.

B. Getting the word out.

Step one of validating an idea is reaching out to your personal networks and gauge response. This is different from approaching friends and family – they will always want to be nice to you! Being 5 co-founders we were lucky to have a big enough network of contacts in the industry to quickly realize the idea was interesting.

So our next step was to approach sites and communities focused around testing betas. These included sites like Erlibird.com and Betalist.com. We were also very excited to hit a top daily spot on ProductHunt.com.

We also reached out to relevant blogs and news sites offering them a free Hotjar account (no strings attached) so they could see how easy it was to use.

Finally, we contacted several relevant community sites asking about opportunities to announce Hotjar to their users. Many sites were willing to spread the word for free, but in other cases we ended up investing into sponsored email announcements or articles.

Having tested Facebook advertising in the past on other projects, we decided to also test Hotjar announcements in the news feed of users that were interested in areas of design and marketing. This seemed to work well so we scaled it up.

C. Anatomy of a beta referral program.

The key to running a successful beta program is having structured processes and open lines of communication. In fact we wanted to be communicating as often as possible with our users throughout the entire process so we could maximize our learnings.

However, with thousands of users joining Hotjar it was clear that we needed to very organized about how we would do this. For this reason we set up:

1. Intercom to chat with our users within the tool.

2. A forum to discuss ideas, collect feedback, and empower our users to share stories.

3. A process and flow chart which explains how to move messages around the team.

4. Trello boards to tag and measure conversations about common issues, bugs and requests (a board was created for each topic).

5. A public roadmap of what we were planning to work on next (we still have a public roadmap today)!

6. We even developed an ‘ethos’ of how to communicate with all our users.

Finally we also conducted frequent surveys with our users asking about their opinion of Hotjar; what they would change or improve as well as how likely they were to recommend or pay for the solution. The mix of inbound and outbound feedback allowed us to quickly change and improve the tool over time.

D. Communicating updates and building demand.

During the beta I made myself accountable as CEO by sending weekly updates to all of our users explaining what we were up to and what had been achieved during that week. These progress updates were sent to actual beta users as well as anyone waiting for access.

Because we kept track of what everyone said we were in a position to take the time to reach out to each user personally when an update, bug or change they had reported or requested was addressed.

This overall ‘personal’ approach to communicating with our users allowed us to create an active and loyal community and fanbase. It led to happier users as well as more organic referrals and growth.

3. What we achieved and learned.

A. The Beta in numbers.

By listening to our users, making small continuous changes and communicating openly and frequently, we made great progress in 7 months. Hotjar was tested on 22,803 sites. During the same time we engaged with users on 6,646 conversations allowing us to ship 69 new features and changes while also addressing 231 bugs.

B. The 8 main takeaways

Looking back at our experience we have identified 8 main takeaways:

• Domain expertise is critical if you are kicking off a startup. It will allow you to have a strong vision for the product.

• Get organized very early on. Define your objective and build iteratively using the right tools.

• Learn quickly about your market and your product appeal by selling while you build. Waiting months until you go to market is just too late.

• Start by defining your MVP and skin it down multiple times. If you are not ashamed of what you ship in version 1 then you’ve waited too long!

• Use giveaways! Incentivize early adopters with prizes – and don’t be cheap. You only get one shot to do it right.

• Attribution is a bitch. It’s really difficult to tell what is a good opportunity or not. Early on, just take every opportunity that comes your way. We were surprised how every little thing can make a difference.

• Invest in great tools to collect feedback and communicate with your users.

• Communicate openly and often. When working with early adopters you need to keep up enthusiasm and momentum. It will lead to strong word of mouth and growth.

Check out part 2 of the series, where I discuss how we finally ended the beta and transformed Hotjar into a viable business.

Check out part 3 of the series, where I share the lessons learned and mistakes made growing from €1 to €3M in ARR.

I'd love to hear about your own experiences - simply comment below if you have any stories to share.