Building in Public 2: Product OKRs that unify, excite, and deliver

We couldn’t believe it ourselves, but we managed it. And we wanted to share it with you straight away. So, here’s our second episode of Building in Public, all about setting a universal Product OKR. Ready? Here we go...

If you’re not somewhere you can watch a video (or are just in a reading mood) below you’ll find a lightly edited and tidied version of the transcript of the video.

Setting an objective

“Hi, I'm Megan Murphy, the VP of product at Hotjar, where I lead our data, design, and product management teams. And today I'm going to share a story of something that we went through recently at Hotjar.

It's something that’s been escaping me in most of my product career, which is: setting an objective that gets those in design, product, and marketing equally excited. An objective that rallies everybody's expertise in one direction.

There are a few different ways that product companies can do goal setting, and Hotjar, like many other product-led tech companies, uses objectives and key results (OKRs). It’s a framework that was popularized by Intel, Google, and plenty of other companies.

The easiest way to describe OKRs is a set of delivery objectives with quantifiable key results that measure your success against that objective.

Today, I'm going to talk about one OKR that we're super proud of. One which in Q1 of 2021, helped us achieve some really impressive metrics gains across a number of dimensions that we’d been pursuing for many quarters.

Okay, so what’s the OKR?

One of the challenges with setting objectives is that it often feels like each discipline has its own priorities, right? In some companies, you even have a technical roadmap, and you have technical objectives.

At Hotjar, we don't do that. We have objectives across our entire tech org, and all disciplines are expected to deliver customer value in line with them.

In Q1 of 2021, our objective was simple:

This was really cool because it rallied our engineers to think of how they could contribute to making the product experience faster by way of, for example, finding the technical debt opportunities that caused the most latency.

And likewise, it got our design team very excited because that part about "and/or more fun" got them excited to think of ways to bring more delight into the product or to reduce the perception of latency.

In most cases, it might seem like paying down expensive and timely technical debt feels like it's diametrically opposed to making the product experience fun or more delightful, but framing it this way helped both disciplines feel excited to contribute.

And of course, product managers are happy when the colleagues they work with every day feel like they're doing meaningful work and are making unique contributions to a given problem.

Measuring success

Any good key result needs to be measurable, gradable, and time-bound. And with that in mind, we decided to measure the performance of the five most used areas of our product experience. We took the average time it takes for those five parts to load on different wifi speeds, then we compared them to the best industry-standard benchmarks we could find.

So for example, we have a session-replay product—which we call Recordings. We measured how long it takes for a recording to load in Hotjar, and then what the industry average benchmarks are for how long loading takes for video products. You can think of some, I'm sure, that you've watched content on.

And so after establishing those baselines, the key result that we set was that the average speed for our product experience to load would either meet the benchmark or deliver a delightful waiting experience.

There's plenty of room for interpretation there, right? What is delight? How do you measure it? How do you know if it's a great experience? When it came to determining if our product was more delightful, we leaned on bounce rates.

So we took a baseline of the bounce rate of those top five most used parts of our product. And then we said, "If we see any reductions in bounce, then we can presume that it's due to people feeling more emotionally connected to the waiting experience," which ties into the second of our five product principles that we shared in the first episode of Building in Public.

The results

And now for the exciting part: how did it go?

I'm delighted to share that in one of our five chosen areas of the product, we saw a 78% improvement in speed! And in another of the five, we saw gains of 26% improvement in speed. I would usually think that the 26% was super impressive if not for that 78% improvement.

And then the part about the delightful experience, likewise, had some incredible results as well. In two areas where we improved the perception of speed, we saw bounce rates drop by 50%.

What’s more, we saw an unexpected result that teams were able to communicate better because we were using an OKR with language that spoke to everybody, no matter their discipline.

Our engineers might have previously said something like, "We need to do a refactor on this code base." Now we're hearing language more like, "Hey, we think that if we improve this, we should see some gains in performance, and that should help with conversion rates."

It's such a different frame of mind where we're always thinking about the end-user, their experience, and the impact on them and on our business.

It sounds so simple, right? It sounds like, "Oh, of course you should know that," but in practice, I really haven't seen this in many places. I really haven't seen product teams using language that puts the user as that shared common denominator and then rallies everybody to make their contributions toward that goal.”

Your own OKRs

So, that's it for this episode of Building in Public. It felt like we cracked something here and wanted to share it with you. By setting an OKR of “Make our product experience faster and/or more fun,” we were able to create an environment where we not only set people up for success, but actually fostered greater levels of collaboration, and excitement about the work.

If you’ve had any similar experiences, we’d love to hear about them. And if you end up using this OKR for your own team, please report back with your results.

See you again soon for the next episode of Building in Public.