The Hotjar story (part 3) - growing our team & product while going from €1 to €3 million ARR

1. Start to grow Hotjar’s remote team

2. Structure our business for growth

3. Scale the product’s architecture and features

1. Starting to grow our remote team

A. We put a structure in place with an accountability chart

In the initial stages of growing Hotjar, we were all wearing a bunch of different hats. I was the CEO, but I still handled customer support and marketing. We were small and scrappy: if we saw something that needed doing, we did it regardless of our job title.

As our team grew beyond the founders and then past ten people, we started thinking about leadership, ownership, and accountability, and about how we were going to organize ourselves: who will report to whom? Who will be accountable for what? Whom are we going to hire next?

We didn’t have established departments yet, but we still needed a clear understanding of how we were going to work together and handle our day-to-day operations. That’s why we built our first accountability chart:

As a first version it was basic, but to me, it was a useful step to see how everybody was starting to fit into the Hotjar picture. We believed in transparency, so we made this available to the rest of the team: now everybody was able to see who owned our major functions, and we didn’t need to waste time trying to figure out who was supposed to do what.

B. We continued to build a shared culture around openness, individual strengths, and trust

Transparency was not the only thing we wanted Hotjar to stand for. We were determined to create a culture of trust, collaboration, and honest communication (put simply, ‘no bullshit’) for the entire team. These are some of the measures we put in place as our team grew past ten members:

• We chose to focus on our strengths and empower our employees to develop their talents. To get the best out of each other, we gave everyone a Kindle and a copy of the book StrengthsFinder 2.0, which I had previously used and could vouch for. We all took the StrengthsFinder assessment and listed our strengths in a shared spreadsheet that we could refer back to.

• Just like with customers, we wanted to understand and measure the experience of team members over time, especially as a remote company spread out across the globe.

   If we needed to make changes, we could only know by getting regular feedback from our team. So we introduced an employee feedback tool, TINYpulse, to understand what everyone was thinking and how satisfied they were in their role and with our leadership (we later switched to 15five).

• We also felt the urge to involve the team in wider discussions, so we started organizing team-wide sessions to brainstorm solutions to the challenges we faced: “How do we create a more engaging user experience?” “How do we hire top talent?” “Where do we see us going?”

We’d present the data and the challenge, and then take some quiet time where everyone would write down their ideas on a Trello board, then vote on the ones they wanted to discuss the most. We would then do a round reading of our most voted cards out loud to get everyone’s input, give feedback on each other’s ideas, and discuss.

These collaborative sessions were very important in the early stages of Hotjar, and we’re still using the format in 2018 with a team of over 70 people across almost 20 countries.

C. We made our first big hire, and I made a mistake

By this point, we were ready for our first big hire: the VP of Marketing. We didn’t have the time and expertise to develop the long-term content and marketing strategy we needed, and we were excited to bring somebody onboard who could build it for us.

We followed the same hiring process that we’d use for any other role: we started from a long survey built with Hotjar to screen the applicants, interviewed the successful ones, and paid the most promising candidates to do 2-3 days of work for us to see if our work styles and quality matched.

We were getting enough attention that we found ourselves sorting through more than 300 applications. With the initial survey step, we were seeing that, despite the enthusiasm, many people did not fit our culture and our drive to put people first and/or had no experience scaling a business as we needed—so we ruled them out.

In the end, we picked a driven and enthusiastic candidate who had a great customer-centric mindset, matched our values well, and was focused on getting a lot of things done. After being appointed, the VP of Marketing quickly brought on two new hires, and within a couple of months, our first Marketing Team was in place.

This is where I confess that I made a mistake. My gut had been telling me something was not right, but I chose not to listen.

This is what we overlooked: although the VP of Marketing did a tremendous amount of work growing and leading Marketing and Support/Success, the new team didn’t have practical experience thinking in terms of scale and growth.

In retrospect, I should have doubled down on the vision and spent more time with the VP to make sure we were building the right team with the right expertise. Also, I should have listened to my intuition and kept looking to find a VP that matched all our requirements in the first place.

The key takeaway is: when you make hiring decisions, follow a process but don’t stop listening to your gut. Hire for strength, not lack of weaknesses. And if you have doubts, listen to them.

D. We introduced the concept of hiring managers

Once we hit €1 million, we needed to bring more help on board—for example: the new VP of Marketing needed a Marketing Team. The problem was that it was still us founders who did all the hiring, from reviewing applications to interviewing people; this was quickly becoming unsustainable, as it ate into the time we really needed to spend on vision and strategy.

We saw a growth opportunity for the team and agreed that it was time to start delegating the hiring process. We introduced the concept of an internal hiring ‘manager’ or owner, and gave our new hiring managers dedicated training so they felt empowered to own the whole process.

I was still personally involved in all the interviews; with the other founders, I was also still responsible for deciding what roles to bring onboard and for all final hiring decisions. That said, delegating the entire process meant that for the first time since releasing the beta six months earlier, I gained some time back to focus on strategy (I’ll say more about that later).

2 . Structuring the business for growth

A. Why we started our VP roles from marketing

From day one, we had a bold vision—changing the way the web is built and improved by bringing Analytics and Feedback together—and we needed to bring in a lot of leads to achieve it. We’d also read a lot on SaaStr about how critical it is to hire a VP of Marketing very, very early on. We had just hit €1 million ARR, so the time seemed right.

In retrospect, we probably made the mistake of hiring for a single leadership position. Hiring multiple leadership roles at once would have made for a stronger leadership team and added a lot of structure to Hotjar moving forward.

But that’s part of the challenge that comes with being a bootstrapped business: without a lot of capital, it’s difficult to go all-in when hiring leadership. We could have afforded to move faster, but we played it safe and accumulated some capital instead.

B. Investing heavily in (the wrong) systems

As soon as our new Marketing Team was in place, the VP chose to use HubSpot as our CRM. HubSpot is a robust platform that worked well for many organizations we admired, and we assumed we too had to have it if we were serious about growing the business.

That assumption turned out to be pretty naive. Because we got excited about this new tool, we did not take the time to check if it would work well with our processes, our needs, and our product.

We also had to use a separate tool, Infer, to qualify leads and integrate that with HubSpot, which turned out to be way too complicated (and really expensive) for our needs at that stage. Even today, as a much larger company, we use something far simpler: Alexa rank, to determine how likely people signing up for Hotjar are to become a paying customer (for us, it’s a simple, binary situation: sign-ups from domains with an Alexa rank are 4x more likely to convert into customers than domains without an Alexa rank).

The lesson here is: don’t get ahead of yourself when it comes to investing in systems. Figure out what you need at your stage, and look for the solution that is the best fit. We should have been more critical about the investment, asked for references, and really tested the technical side of implementing a solution instead of simply relying on the recommendation of someone we had just hired.

C. Our first growth acronyms: KPIs and the OPSP

Being relatively new to SaaS, I kept looking for inspiration in what Jason Lemkin was writing on SaaStr. Articles like “What is the key SaaS metric that every SaaS Company should obsess about?” convinced me to start defining our KPIs (Key Performance Indicators), the metrics we would look at to figure out if Hotjar was working.

At that point, we knew how many new accounts we were bringing in (signups), but we needed more clarity about how many were becoming customers and how many we were retaining. We did not have time to build a fancy dashboard, so I just started centralizing our numbers from Google Analytics and Mixpanel in a shared Google doc:

I was also reading Mastering the Rockefeller Habits, which inspired me to create our first One-Page Strategic Plan (OPSP). It was basically another one-pager with our entire company vision, goals, long-term initiatives, and short-term projects:

These two documents served us well in the beginning, but while we kept updating the KPI sheet, we dropped the OPSP after a little more than a year.

Why?

D. What went wrong with the OPSP

Business leaders use an analogy when they talk about long-term strategy: they compare it to filling up a jar with big rocks (big picture initiatives) and small rocks (finer details). If you want to be as impactful as possible, you put the large rocks in the jar first. If you were to put the smaller rocks in first, they’d take up so much space that you wouldn’t have room for the big ones.

Sounds great in theory, but the analogy only goes so far.

After hitting €1million, we realized that we were spreading ourselves too thin by working on too many ‘small rocks’. So we shifted gears towards the big rocks... except, we over-corrected and became way too ambitious with our initial plan and projections.

The intent was right, but we underestimated how many resources we needed to get everything done. For example, we had a ‘big rock’ research project to study how all of our customers were using, or not using, Hotjar’s Survey tool. The person who owned this task had a million other things to do; we had not looked into how to tackle the big rock from a practical point of view, so the project fell to the wayside.

And, by the way, so did other three of four big rocks who were similarly large and not scoped out: a customer success reach out strategy, a basic form of training for users, a new email sequence by vertical and personas, and a version two of onboarding—all of them were assigned to the same person, and none of them got done in the end.

That said, looking back from where we are now, the OPSP was a good step in the right direction. It served as the inspiration for adopting the V2MOM strategy (which stands for Visions, Values, Methods, Obstacles, and Measures) that we are currently using. In many ways, our current V2MOM is an OPSP on steroids, and yes, we’re allowed to use more than one page.

E. Our MVP approach to enterprise pricing

Our path went like this: we came in with freemium, we sold to teams, we built a loyal fan-base, and we expanded as quickly as possible.

At this point, two paid Hotjar plans were available at €29 and €89, but we were getting a lot of inbound interest from larger/enterprise prospects with a lot of traffic. In fact, an executive at one of the world’s biggest companies—who recently mentioned us publicly as part of their tech stack—signed up for a free account with a Gmail address to try us out early on, and was impressed with the ease of use and the service they received. That’s not surprising since we were just starting out and they were getting customer support from the CEO!

When it came to pricing at the enterprise level, we first looked at other SaaS price points, then modeled the traffic of the sites signing up for Hotjar and created a chart to determine what to charge on each level, erring on the high side. My logic was: by setting the prices really high, we wouldn’t have to deal with more customers than our technology could handle.

I also figured that if we managed to sell at those rates—which we did—we would prove to the team that it was worth it to build an infrastructure to handle the high-traffic site market. In short, this was an unscientific and experimental MVP approach to pricing, but it paid off since we closed a few five-figure deals within a few months.

F. We almost got an investor

In September 2015, we started talking to two Venture Capitalists (VCs) about funding—one in Sweden and another in Germany.

You may be wondering why we considered funding when we were at €1 million in ARR. That’s simple math: when you divide €1 million by 12, that comes to around € 83,000 in Monthly Recurring Revenue (MRR), and we had employees to pay and overhead to cover.

We spent about eight months talking to the Swedish VCs: we created a pitch deck, and we even received a term sheet.

Internally, the founders and I had identified a range for the amount of money we’d accept (€3 to 5 million) along with a range for the amount of equity we were willing to give up (10 to 20%). When the offer came, it was at the low end of our range in terms of funding, and at the high end of our range in terms of the equity they wanted.

We declined it.

If we had received the offer we wanted, we would have probably taken it, and it would be interesting to think where Hotjar might have ended up. We’ll never know, but we still learned a few important lessons from the experience:

1. Transparency is key: during talks we identified an error in the tool we used to report MRR. When someone switched from a paying plan to a free plan, they didn’t show up as churned, so our churn rate was under-reported.

   We immediately let the VCs know about the error and apologized. They were disappointed about the churn data but impressed with the transparent and upfront way we tackled the situation, and it raised the level of trust between us.

2. Go with a set plan of what you’re after. Don’t give ranges.

3. If you are going to raise, don’t give up if you don’t find the right fit. When you explore the VC funding route, you need to be willing to speak to many VCs to get the right deal. In our case, we were lucky to be profitable very early on and did not need to raise.

In the end, we succeeded in growing the business without investors. We were looking to raise between €3 and 5 million, and two and a half years later we have accumulated this amount through profits. We could have traded equity and full control to get these funds earlier on—and we’ll never know whether that was a good idea or not.

3. Scaling Hotjar's architecture and features

A. We kept improving Hotjar through user and customer feedback

During these nine months, we improved Hotjar a lot. We didn't have a Customer Satisfaction Survey (CSAT) and we didn’t know our Net Promoter Score® (NPS) yet, but it was part of our company ethos to go beyond basic support and functionality and really double down on making sure our users and customer were happy.

We obviously had an idea of where we wanted to go and what we wanted to build, but we kept listening to our users and what they wanted us to build for them. We had a Trello board where we collected feedback we received whenever our users contacted support, and we used it to direct us in what to execute on next.

This was our roadmap at the time:

The changes we made in those months fall into three categories:

• Improvements based on user requests, such as optimizing the Hotjar script for speed or introducing sub/cross-domain tracking. The latter in particular is an obvious improvement in retrospect, but until our users asked for it, we hadn’t realized how common this need really was.

  You could now use the Hotjar script across all website subdomains (like on checkouts or across different countries). This was a big technical challenge to execute, but we got overwhelming feedback from our users so we knew we had to just get it done. 

• Improvements to the experience, which included improving the usability of our Recordings player, and setting up daily notification emails to go out whenever something relevant happened in a user’s Hotjar account (for example, when they received a new feedback response). It was a way for us to be proactive and also get people in the habit of logging back into the tool.

• Improvements to the architecture, like “Optimize the script for speed and deliverability” and "server-side listing and sorting of recordings.” We were starting to increase the number of people using Hotjar, and our architecture was still very weak; this is where our co-founder Erik single-handedly introduced Elasticsearch to render the list of recordings.

  It was a huge win at the time, but it also added complexity to Hotjar at a point where we did not have enough engineers on the team to tackle this challenge (more on this below).

B. We built a couple of quick integrations—it was a bad idea

Around this time, HubSpot reached out to us about the opportunity to build an integration. On paper, it looked like a great thing: having someone as big as HubSpot interested in working with us almost felt like a validation of Hotjar.

But the reality was that the whole process proved to be difficult. For one, we were having multiple issues integrating due to the amount of data we were sending HubSpot; we also did not plan the execution very well. In the end, although we shipped the integration, we should have spent that time building integrations for tools that had more overlap with Hotjar.

We also planned a deep integration with Optimizely since we had a lot of overlapping customers. We were supposed to work on this together, but when we finally got around to getting it done, the Optimizely team delayed it multiple times. It turns out they were pivoting to the enterprise market and launching their newer platform Optimizely X; a deeper Hotjar integration was no longer a priority since we offered our product for free at the base level (we’ve since integrated with Optimizely).

The bottom line is that if you’re going to do integrations, choose them wisely. Treat them as if you were building a key feature for your own product: speak to your customers, understand what their workflow looks like, and build integrations with tools and platforms that impact a large portion of your user. Also, as the Optimizely experience taught us: talk to your partners about their future goals, to make sure their plans are compatible with yours and you are targeting the same customer base.

C. Product growth = performance and security issues

We were definitely getting a lot of growth at this point. We tripled our revenue in nine months and Hotjar kept on becoming popular—but the downside was that we started to experience performance hits and our first incidents.

This was another key moment in our growth as a company: we decided that we were going to be completely transparent and start publishing an incident log, at a time when not many companies did that.

Our very first incident listed there is from August 2015, and this log still exists today:

For any incident where users were affected, we decided we would reach out and notify them. We were terrified about how our users would react. But we thought of our own experience using tools and being frustrated when things were not working and nobody was telling us why—and we knew we would not do that to our users.

Around the same time, security started to become a major concern as well, and we started being subjected to our first phishing attacks—so we quickly put in place security measures like using LastPass and two-factor authentication. After a few people reported vulnerabilities to us on Intercom, we also thought it was a good idea to use a proper bug bounty platform (Hacker One) to reward users for reporting vulnerabilities.

These performance and security issues opened our eyes to the reality of scaling our product, and the amount of structural and architectural changes we would need to tackle ASAP to achieve scale. Which brings me to...

D. Our biggest product mistake: we were too slow to hire engineers

Hotjar was just over a year old, and we hadn’t worked hard enough on recruiting new engineers. Our Hiring Managers for the Engineering Team were focused on product development, and they were doing hiring on the side.

So when we started to scale, we had to rush and we made mistakes—like hiring people who didn’t work out. Having wasted our hiring time, we got a little demoralized by our mistakes instead of doubling down and keeping the hiring momentum.

Not having enough engineers slowed us down and impacted our ability to quickly respond to demand and deliver more value to our customers. To be honest, we are still struggling with that: we have grown to 20+ Engineers on our team, but we constantly need more to realize our bold vision while keeping Hotjar secure and stable for everyone.

8 main takeaways

1. As a founder, you will naturally tend to do most things yourself. To grow the business, start delegating tasks to the rest of the team (for example, the hiring process) so you can focus on strategy and vision.

2. Bring the team together—especially when you are remote and miss day-to-day in-person interactions—with brainstorming sessions, employee feedback tools, and accountability charts. Make sure everyone is focused on the same business objectives by sharing the vision and KPIs with everyone. 

3. When making hiring decisions, check for culture and business fit, but also trust your gut if something doesn’t feel right. Hire for strengths—not lack of weaknesses.

4. Instead of investing quickly in systems just because someone recommends them, be critical about the investment: figure out exactly what you need for your current stage and size, ask for references, and test the technical side.

5. If you want to raise funds, you have to be very deliberate about your plan and go into it knowing exactly what you are willing to give up and what you want in exchange. In dealing with VCs, always be transparent about the state of the company.

6. Constantly improve your product through user feedback, and be open about incidents and performance issues: treat your users and customers as you want other vendors to treat you.

7. A growing business inevitably experiences performance issues, incidents, and even security threats. Do not underestimate the importance of building a secure business and protecting your customers.

8. Engineers are crucial to scaling: do not wait to hire them until you desperately need them. Bring them on earlier, and choose people who can self-manage and understand the importance of delivering in a fast-paced startup environment.

   Stay tuned for the next part, where I’ll bare it all and share some of the biggest and scariest challenges our business would ever face. In the meantime, I’d love to read your comments or learn more about your experiences of launching, and growing a business - add a comment below if you have anything you’d like to share.

*

A big thanks to my colleague Fio Dossetto who interviewed me for this piece, helped me to structure it, and wrote it from A to Z.

Net Promoter, Net Promoter System, Net Promoter Score, NPS and the NPS-related emoticons are registered trademarks of Bain & Company, Inc., Fred Reichheld and Satmetrix Systems, Inc.