How We Set Goals for Goals

When we first decided to build usage goals as a feature in Pendo, we started by doing what most product teams would do — we developed a thesis for what this feature might achieve and tested it via customer interviews. We wanted to learn how product teams set goals for things like feature adoption, user retention, etc.

We asked questions like:

What are the metrics that you measure? How often do you review progress? When do you report out the results? And who is in the audience / how do they like to see that information displayed?

The answers that we received were quite different than we had expected. In fact, we didn’t really get a ton of answers at all. Sure, some teams had a couple of metrics that they measured on a quarterly basis, but most teams spoke about goals in an aspirational manner.

A series of these conversations made us go back to the drawing board and rethink how we’d build goals in Pendo. Rather than prioritizing a robust set of metrics to accommodate a variety of goal-setting use cases (as we had originally anticipated), we doubled-down on a UX that actually helped guide a user in setting a goal.

For example, each time that a user chooses to add a goal to a particular feature, we provide a default date range, metric, and target value based on what we know of the historical performance of that feature. This takes the guesswork out of creating goals and hopefully helps PMs who have aspirations to set goals, actually just set them!

We released Goals at the end of August and, seeing how we dogfood our product at Pendo, launched a goal for Goals on the same day as the release. This was a big deal — like the PMs we surveyed, our team hasn’t been great about setting goals for feature releases. We typically review usage following the release, but rarely have a concrete usage target in mind at the time of the launch. Looking back, I realize that the customer responses we received from initial interviews probably shouldn’t have been all that surprising. We too had a learning curve for setting goals.

I had no idea what goal to set for the Goals feature release, but I did know that we had released a different analytics feature called Trends just a few months earlier. So I pulled up the usage for that feature in the first couple months after it went live, and found that about 120 visitors adopted Trends in the first 30 days, and 260 visitors had used it within the first 90 days.

I knew that Goals wouldn’t have quite the adoption uptick as Trends because it was less discoverable in our product. I also knew that it would be more valuable to measure how many accounts (or customers) set goals rather than visitors (or individual users), since goals are typically set by an entire team. So, I just adjusted the numbers slightly to reflect my assumptions and set the goal target.

By setting a goal for Goals, I realized that I, like several PMs I talked to in interviews, experienced a moment of hesitation just before saving the goal to my dashboard. In fact, when I reflected on my career, I recognized a strange pressure that came along with setting goals regardless of where I worked. I often thought to myself, if I set it, then I am accountable to it, and if I miss it, then I fail…so better not to set it.

Even in this case, after studying and designing this interface for setting and measuring goals, I cannot say that I was all that confident about the value that I was setting. However, I did know that it was really important to set it. My logic followed that if you don’t set a goal, then you never get to track against it. And if you don’t track against it, then you aren’t asking why. And if you aren’t asking why, then you aren’t learning about the levers that affect performance and ultimately making changes to find success.

And in fact, we didn’t hit the goal (as you can see above). Nevertheless, I found myself following up and asking questions that I wouldn’t otherwise have asked, like “Why aren’t we seeing as fast adoption of this feature?” and, “Is there anything that we can do to increase the discoverability?”

We were excited to get the data, and turned around and asked these very questions of our customers via Pendo in-app polls. I set up a guide targeted to users who had interacted with our “Add a Goal” link, but had not actually saved a goal.

The responses that we got to this poll were incredibly informative. Some responses confirmed our suspicion that teams didn’t feel ready to commit to goals. Other responses were really actionable and helped shape the set of feature optimizations that are now in our backlog. I’m really happy with how this feedback cycle turned out and will definitely be setting goals for all of my future feature releases.

Ultimately, when you set expectations and measure against them, then you are spurred to ask more of yourself, to seek understanding of the situation, and ultimately learn which levers actually affect change. And that makes you better at your job. Who doesn’t want that?

So, rather than be afraid of not reaching a goal and therefore not setting one, I’ve learned to just set it! And measure against it. And act on it. But that is the spirit of agile, after all, right?

PS: For those who might be using Goals in Pendo, I learned something else while dogfooding our product. I learned that it is much harder to monitor your goals without notifications or reminders to do so. Luckily, I had one of the front-end engineers who played a major role in building Goals checking in with me over Slack almost every other day about initial usage. This is certainly an optimization that our team will be looking into in the future!

Thanks to Brian Crofts.