Usage Metrics: Users - A Unifying Force

Usage Metrics: Users - A Unifying Force

Scroll Down

Lately I've been thinking about where usage metrics and behavioral analytics fit into our overall company goals.

Why do I view these as an important part of the product development process in both large and small companies? Why does it matter?

The nature of usage metrics is what really makes me wonder this. Even a relatively small amount of users can generate a mountain of product usage data. Even small companies can be drowning in data.

It's easy to get lost in these vast piles of data and lose sight of why it is that we're bothering to do it. It's easy to lose sight of what we're trying to accomplish.

There are a few things I consider when I think about the growth of the companies I work with.

It should be noted that I don't view any of these priorities as necessarily better or worse than the others. They are different. People are different and motivated by different things.

All those differences can come together to make something great or can fight each other for dominance to make something mediocre.

The Technology Side

This is the side I've felt most comfortable with in the past.

The growth of the technological stack. The ability of the technology to meet the needs of a company as that company grows.

I'm a software engineer, after all. A software architect, at some point in time. A programmer, or a developer at others.

Of course technology is what I'm most comfortable with.

As far as I've seen - From the engineering teams I've worked with and my own feelings as a part of the engineering team:

MRR/ARR growth does not motivate a ton of engineers.

It's not often why they wake up in the morning. It's not why they build things.

The growth of the company in terms of revenue definitely affects their lives. It's what provides resources for them to work. It's what provides vertical movement through their careers.

It's what lets them keep building things. It's what puts food on their table. That's often the extent of how much MRR/ARR affects their motivations.

Often (not always, but often), the thing that fuels engineers is the creation of systems or the creation of tools or the creation of useful things.

The creation of something powerful, something grand, something impossible. Creating something greater out of a sum of small parts. Creating things that people would have never even dreamed about, all throughout history. Creation of something meaningful to the life of the creator.

This does not often clash well with the business side of things. At some points - looking at you, reduction of technical debt - they seem adversarial.

What often drains people in this camp is the lack of ability to materialize the system they long for. Legacy code. Short, poorly-timed deadlines. Rushed needs of the business that are released too early and maintained too late.

The Business Side

It'll be funny to a lot of folks that I even separate out "the technology side" from "the business side".

A lot of people would probably say "There's only the business side! Without the business side, no one has jobs!"

I agree to some extent. That businesses, and all of their employees, are there because they contribute to the overall growth of the business.

But what I'm talking about in this article is the motivations of the people involved. Not their end results or functions of their role.

I'm sure there's another side that I have very little knowledge of, such as "the interpersonal side" that might be representative of more folks who are dedicated to making teams and people within the company work together well. I won't mention that in this article. Not because it's unimportant but because I have limited first-hand experience with it as a dedicated role.

Anywho, the business side.

These are the executives within the company. These are the salespeople within the company. These are the people often deciding company vision and the priorities of the company. The people who close deals.

This camp often measures their success by MRR/ARR growth or units sold.

They often don't get motivated by how many APIs are involved in a given request. They care that those APIs are contributing to the growth of the company's revenue in a significant way.

They often aren't extremely motivated by the idea of building a beautiful product. Building a beautiful product is often a means to an end and that end is selling the product.

If the product being beautiful means it'll sell more, then they're excited about that.

If a product's beauty does not affect how well it will sell, then they often view that time being better spent elsewhere.

Their motivation comes from continued sustainability and growth of the company.

Without the company growth, everyone loses their jobs. Without revenue, no one can put food on their table. Revenue is the only real measure of success of a product.

A product that can't sell is a product that's not useful enough to people.

What often drains people in this camp is when the the company cant move fast enough to support sustainable revenue growth. When things are done that don't contribute to overall growth - such as perfectionist ideals or lack of focus at crucial points in time. That can suck the energy right out of their day.

The Creative Side

There is a beauty in a very well-crafted product. That beauty can feed the soul and turn days that would otherwise be lackluster into days that excite and invigorate. We are in one of the most exciting ages of human history and it can either be awesome, mediocre or awful.

I'm new to learning about the creative side.

I can't yet produce great, creative works myself. But I hope that one day I'll be able to. Forgive me if I miss an important aspect of what motivates a creative person.

Here I'm mainly talking about the graphic designers, the user-experience designers, the product designers, the content writers, and the creative directors of the world. There are many more - But I don't have enough knowledge to try and discuss them in any detail.

These are the folks that are excited by the possibility of building a delightful, useful product. They often want every aspect of the product to make sense and have a single, unifying theme that ties it all together.

When this is achievable and everything fits together, is easy to use, makes sense, teaches the user something, and looks stunning while doing that - it can bring both energy and personal fulfillment to this person's day.

Using a well-designed product can feel like a conversation between you and the person who designed that experience. The designer assuring you that they know what you're trying to do and have built a product just for you.

It can suck the motivation right out of a creative person if this opportunity is denied them.

If their work is glossed over, their goals belittled or they're told (often by the business side. But also by the technology side) that it'd take too much time and effort to put their work into the product. It can make things seem futile or overwhelming.

The Support Side

These are the people really down in the trenches.

The people who handle customer support for the company. The folks who handle the customer growth or customer happiness that keeps the company running.

They talk to customers. They log the bugs that ruined someone's day. They let customers yell at them, parse that information for the useful bits, and somehow turn things around for the user.

These are the people who get on the phone with customers when the company has really screwed up.

They take the feedback they're given and help prioritize the fixes so that they helps the most customers in the fastest way they can.

Honestly, I consider this the toughest job out of the bunch.

I feel like these folks would be excited by customers yelling at them less because they like the product.

Users - The Unifying Force

We've gone into detail about each of these camps. There are likely many more camps that we've not named.

These camps have different motivations and these differing motivations can tear a company apart. There are some that live and die by their camp and view the other camps as futile.

These differing motivations can also foster healthy discussions that propel a company forward. Creating a perfect storm of ideas that keeps it moving through the toughest storm.

This is where usage metrics and behavioral analytics comes into play.

It's what every camp can agree on, the unifying force between all these motivations. The things that binds them all together into an unstoppable force.

The desire to build a product that people use, find useful, and find delight in using.

We just need to find a way to measure that goal and watch how it progresses over time. Usage metrics can be the metrics that everyone champions and shares joy in.

Support Teams already knows this

Support Teams would be very happy if the full focus of a company was on its users and their happiness.

If everyone in the company unified around users and their engagement with the product, the customers would stop yelling at the Support Team.

Customers not yelling at them as much would probably a nice step upwards.

Customers not yelling at the Support Team, while many customers are actively using the product, is an indication that customers are having a good time using the product.

Customers having a good time using the product means that we've built a product worth selling.

Side note: If you're a customer of anything - Please stop yelling at the Support Team.

Creative Teams already know this

Studying design, even a small bit of design, is probably one of the most insightful and useful things I've done in my life so far. I'd suggest it to everybody.

Those who design products, design experiences, or fill products with creative content, are thinking about the users and user experience through the entire process.

These folks would often love for the company to be unified behind the experience of the users. They would love to see the affects of their designs on the direction of the company, first-hand.

What companies often lack is the tools and expertise to make this happen. Design in a company without access to usage data is like designing with a blindfold.

Creating useful things is an iterative process that requires feedback and revision along every step of the way.

The Creative Team can easily get behind understanding users and customers on a deeper level to drive the product forward.

It's better than technical achievement

The only folks that care about how many APIs are under the hood are the engineers. No one else is going to be excited about eliminating redundancy while increasing reliability and speed.

They care about how that reveals itself in the product.

No one cares about our beautiful elastic load balancer on top of clusters of Docker containers with an infrastructure configured as code.

I say that with love.

But what we engineers can appreciate, and everyone can appreciate, is that a bunch of people rely on the things that we build.

A lot of people use those APIs and frontends we worked so hard on - every day.

We can take pride in the fact that the people who use the things we build are having a good time. We can feel the sadness of having pushed something that disrupted that happiness.

Engineers and non-engineers alike can share in the joy and sadness of users using or setting aside the product they worked on.

It's not that technical achievement isn't awesome - It is. It's something that we should take joy in, in the things we create.

But if we want a shared, joyful experience with our coworkers - which we should - we should also view everything we do in regards to how it affects the end-user.

Will it bring them joy? Will it bring them annoyance? Those are the things we should be able to get behind with every new technological marvel or tweak we make.

It's better than MRR/ARR

Again - People are probably going to argue with me that MRR/ARR is the only thing that matters in the end. This is the real world and money is the only measurement of success, they may say.

I agree that businesses nowadays couldn't exist, support their employees or grow without revenue growth.

I don't think that's the only way things have to be. But that's a post for another day.

What I would argue, a bit dramatically so as to make a point, is:

MRR/ARR is a vanity metric.

MRR/ARR increases and decreases at a slow rate. Large deals can take months. Small deals can stop contributing to MRR/ARR long after the event/changes that caused them to fall through.

Salespeople often cut deals (for good reasons) at key times to close deals faster in order to hit MRR/ARR growth goals.

The delay in growth/decline of MRR/ARR is a weakness that can only be overcome through deep understanding of what drives it. An understanding that not everyone in the company has or can have.

So my above statement could be summarized to MRR/ARR being a vanity metric for everyone who does not have deep understanding of the people who are purchasing or using the product. It is useless to those without it.

Usage metrics are a part of that puzzle. Understanding the industry is a part of that puzzle. Understanding the product is a part of that puzzle. Talking to real people and getting their feedback directly is a part of that puzzle.

People in the business camp may not agree that MRR/ARR is a vanity metric. That's fine.

But what we should be able to agree on is that if people are paying for a product they aren't using, the business would not be sitting on a healthy foundation.

A healthy business is not defined by a company that can sell things.

A healthy business is defined by a company that can sell useful things.

MAU and DAU are key metrics that allow businesses to know whether or not people are using the product they're paying for.

Deeper usage metrics are a way to understand the difference between those that become customers and those that don't. Behavioral analytics, tracking and understanding of those analytics, allows for the company to know what customers they're at risk of losing and what customers are getting the most value out of the product.

The folks on the business side should be able to get behind and be motivated by the knowledge of who's using their product, how they're using it and how they feel about it.

They should feel sadness when it's shown that users aren't using the product anymore or are feeling annoyed by the product. They should feel joy when users are continuing to use their product and when users feel good about that fact.

Understanding customers is a gateway to understanding the MRR/ARR growth of a company on a deeper level and a way to spot trends and issues before they're reflected through MRR/ARR.

It's all about people in the end

This article was written by me combing through my thoughts on why I believe usage metrics and behavioral analytics to be important.

Future posts will detail different metrics that companies can track in order to help facilitate this deeper understanding.

These metrics take all the various camps of the company and marry their success and failures to the happiness of the users who use their products.

Feeling empathy and understanding for users is the way to make great products and useful companies.

Feeling empathy and understanding for those around us is a way to better ourselves and our knowledge of the world.

Because it's all about people in the end.

  • Cory Finger
    About the Author

    Cory Finger

    I've been programming for 15 years and love making tutorials to help others to learn more about the practice. Topics ranging from Programming, Architecture, DevOps, Machine Learning, to Analytics!

View Comments

I Am Cory Finger

A professional programmer

Cory Finger

I've been programming professionally for 13 years and can still feel completely overwhelmed by the breadth and depth of all the technologies out there. I've composed a list of tips along the way, to help anyone who feels similarly!

Also, I live in Seattle and work at Crystal

Stay informed with our newsletter