How to foster data driven culture
Last week I was talking to a founder who recently launched a product. He expressed frustration on how he’s the only one on the team who cares about metrics. His team values data in general, but didn’t end up tracking any metrics for their recently launched product.
I have been in this situation before and was able to guess several things that they as a team might be doing wrong. Over the years, working on several web and mobile products, I’ve learned so many things that I have been doing wrong to try to get the team on board. In hindsight, some of these things seem glaringly obvious but can easily be overlooked. Here are a few things I’ve learnt that can help small teams care about metrics.
Don’t Change Workflow
When working on product or marketing metrics is your focus, you’ll most likely have analytics tabs open at all times. Constantly checking numbers, looking at various reports, etc. Initially, to build a data driven culture, I passed on our Google Analytics credentials to everyone on the team expecting that they’ll login to check the numbers everyday. It was soon evident to me that that’s not the best way to get everyone on board with a metrics driven culture. There’s huge friction for other members of the team to login to Google Analytics (which was another Google Account), then click on the profile, click on the right dashboard and then see a bunch of numbers which they may or may not have any context of.
Two ways I found that worked best with bringing everyone on the same page about metrics are:
Email — It’s safe to assume that everyone on the team checks their email (or at least used to, Pre-Slack). We decided to send an email with our most important metrics everyday at the same time (preferably at the start of the work day) with a few key metrics in the subject of the email. Adding key metrics to the subject helped in other ways. More on it later in the post.
Slack —Several years later when I started using HipChat (and later Slack) we translated the success with email to Slack. Due to the (bite-sized) nature of chat/messages, Slack opened up more doors to embed lightweight analytics into the existing workflow. I didn’t want to send too many emails so we’d only send one email per day, but with Slack we could control the frequency and timing of messages as well as which channels they go to. We have a dedicated #reporting channel where a lot of metrics get pushed into. It’s more like firehose for metrics and reports. We avoided building several dashboards because we were able to push those metrics into the #reporting channel. The #general channel only gets the most important KPIs.
Lesson Learned: In order to get your team to adopt something, treat them like your internal customers and come up with solutions just like how you would for the users. Try to incorporate as much as you can into existing workflows. Remove as much friction as you can.
Bite Sized Data
Being a product or marketing person, you look at several metrics from MAUs to engagement metrics. Although, these are great metrics to track, not everyone on the team needs to know about all those metrics. Once I learned that team members are usually not motivated enough to login to the analytics dashboard, I started taking screenshots from Google Analytics and sharing those with the team. Everyone looked at the numbers, but I could tell they were overwhelmed by all those different metrics.
When we started sending a daily email report, the biggest thing that I learnt wasn’t the email itself, but the Subject of the email. Here’s an example: “DAUs: xx,xxx MAUs: x,xxx,xxx”. The email body had a lot more details. I noticed that most of the time people would simply glance over the subject and deleted the email. Since these were daily emails, everyone had a ballpark idea of what normal metrics numbers were. The days when the numbers had a major dip or rise, everyone opened the emails to see what had changed.
Lesson Learned: It’s better to not dump all sorts of metrics on to the team and hope that they’ll weed out all the unnecessary info. It’s much better to selectively display 2–3 most relevant KPIs.
Real Meaningful Metrics
In the name of simplicity, it’s very easy to share feel-good metrics with the team but the main problem with that is that metrics like total registered users, total downloads or any other cumulative data numbers don’t really tell the whole picture. Leave those numbers for the press/marketing pages. Avoid using them as main KPIs internally. It’s good to share and celebrate cumulative numbers, but using daily/weekly/monthly numbers with delta change from the previous period can prove to be a lot more beneficial. One of the metrics we track and share on a daily basis is the percent growth or decrease in Weekly Active Users (WAU).
Monitor and Update KPIs
This is probably the simplest of them all, yet from my experience, ignored the most. Usually once the KPIs are added, they are never taken off the list. Gradually new KPIs keep getting displayed, but the old ones that are not relevant anymore are not taken off the list. It’s a good practice to clean up the list once a quarter. Get rid of things that aren’t relevant anymore.
Apart from a few metrics becoming less relevant, some KPI metrics don’t change too much. Instead of pushing the metrics every hour, push them only if there is a significant change. For instance, rather than blindly pushing hourly updates for average response time for your API, only push if there is a +/- 10% change. Showing same metrics often can make the team desensitized to the metrics (see banner blindness).
Got tips or tactics on how to spread a data driven culture? Would love to hear them. Comment below or tweet at me.
