top of page
  • Writer's pictureKatie Sipos

Building a dashboard to communicate company-level metrics

Updated: Feb 2






I joined PlanetScale in September of 2021 as their first data hire. After onboarding and orienting myself, one of the first tasks from the CEO was to build a company-level dashboard. The main goal of this post is to walk through my steps for making that dashboard and how I rolled it out to the company. Hopefully it will help others who might be in a similar position to where I was.


Before I get into it, it’s important to note that a few things happened before putting together this dashboard:


  1. Established our data warehouse in BigQuery and set up our data pipelines and BI tool (Mode)

  2. Had a rough idea about a set of core reporting metrics that we would use to communicate the business’s health

  3. Did basic cleaning and transforming of data in BigQuery views


I’ll write about those topics in separate posts later, but for now let's get into my process for building the dashboard and how I rolled it out.


Step 1. Exploration and getting to know your main stakeholders


At this point, I was only about a month into my role at PlanetScale, so one of the more pressing problems I wanted to work through was identifying the needs of the main stakeholders for a company-level dashboard. I had spent the first few weeks getting to know the business at a high level and the product itself. I didn’t know what Marketing, Sales, and Engineering specifically cared about regarding data & metrics.



Getting to know your stakeholders and their needs might take some time, but it’s worth it. For me, this step took about two weeks. If time is going to be a problem, you can condense this part to fit your needs. It’s not only worth it for the initial dashboard, but you’ll make friends on other teams and understand what motivates them.


From my experience, the leadership team members are the most essential folks to get buy-in from for a company-level dashboard. This person could be the C-level of your company or the specific leads on each team. Of course, that depends on your company size. For me, it was the C-level of our company and the upper levels of leadership like the VP of Finance, Engineering, etc. This is because they have the highest vested interest in the 10,000-foot view of how the company is doing. Individual team contributors will want to dig deeper, but your leadership team will want to wake up every week (or maybe every day if you are lucky :D) and get a pulse on how the business is doing. They will also be great people to evangelize your work publicly and excite other team members about data and metrics because normally their messages carry a lot of weight in an organization.


Tasks to accomplish during this step:

  1. Set up some time with the stakeholders you’ve identified from above that will have a strong interest in the outcome of this dashboard

  2. Get to know them. Find out what they care about and what data or metrics are important to them


Your folks will be different but this is who I met with:

  • CEO

  • Head of Sales & Sales Enablement

  • VP of Engineering

  • Head of Marketing

  • Head of Finance (we didn’t have this person at the company when I was going through this process, but we went through the same steps after they joined)


Here are some sample questions that I used when talking to each group:

  • How do you know when PlanetScale is doing well as a business?

  • How do you know when a (launch | product | deal ) is successful? Conversely, how do you know when it fails?

  • What keeps you up at night in terms of our business?

  • What's the rundown you'd like to see with your morning coffee/tea/etc?

During this interview, I also started honing in on the company-level dashboard's primary audience. In a perfect world it is everyone at the company, BUT we know that’s not how it works so I wanted to orient my work around two key audiences. I thought that if I could build a dashboard that suited their needs, they would become data advocates and help spread the good word about our data in the future.

  1. Something for our CEO to look at daily with coffee to get a quick pulse on how things are going

  2. Team leads or heads of teams with only a few minutes to get a quick pulse on how things are going that they can communicate downward to their team

Step 2. Aligning on a set of core metrics that solve most of your audience needs




Tasks to accomplish during this step:

  1. Consolidating the interviews from above into a set of core metrics that you can later write queries for and visualize

Depending on your company's size and your experience crafting business or product metrics, this step could vary in terms of time and getting reviews from your initial stakeholder group. Before going through this process I had a good idea of what core metrics would be good to include from going through the process of defining metrics at a previous company (i’ll write more about this in a separate post!)


Initially, I read through all the notes from my interviews and began synthesizing to see what patterns popped up. Then, I summarized those overlapping patterns. These three patterns popped up in some way in each interview:

  1. 💰 Are we making money?

  2. 💜 Do users like our product?

  3. 👨‍👩‍👦 Are we growing as a business?

From there, I developed a set of metrics (no more than two) that supported each bullet. My main goal for a company-level dashboard was something short & sweet so folks would stay interested. I wanted to avoid overwhelming folks with hundreds of metrics on the company dashboard and opted to link to deeper dive dashboards when needed. Anyone who wanted to dive deeper could do so quickly with those quick references to the deep dive dashboards.

Here are a few samples of the metrics I used in each category. I won’t go too deeply into these since they aren’t all public, but I will include generalizations that are true of most companies:

  • 💰 Are we making money?

    • Monthly revenue & annualized revenue broken down by segments like plan (we actually didn't have all of this data available at the time of building it so we only included a monthly view)

  • 💜 Do users like our product?

    • Monthly active users

    • Active percent (the percent of active users to total users)

  • 👨‍👩‍👦 Are we growing as a business?

    • Measuring the increase across our internal metrics like new users monthly, active users monthly, revenue monthly, etc

Step 3: Prototype & iterate




Tasks to accomplish during this step:

  1. Sketch your dashboard prototype in whatever method you prefer

  2. Build a quick first version of your dashboard that you can review with your initial stakeholder group

  3. Get feedback from your stakeholder group

  4. Iterate if need be

Everyone has preferred methods that they use for prototyping a dashboard. I like sketching out the layout and charts in something like whimsical or on a piece of paper.


I started by prototyping the metrics I had defined and paired them with basic visualizations to illustrate each metric. Once I had a good base of a prototype I shared it with a few key stakeholders to get their input in the same way someone would conduct external user research about a product.


Here are some ideas for that research session:

  • Before explaining what each chart is visualizing, ask your stakeholder to explain what they think it’s communicating

  • What is confusing?

  • What stood out?

  • What do you like/don’t like?

I learned a lot of things at this point of the process:

  • Most folks prefer bar charts over line graphs for showing counts over time

  • I should always include the counts with the chart unless it’s too chaotic

  • Shared axis charts are hard to understand unless you have some basic understanding of how to read a chart

  • Keep it simple, keep it safe! The urge to make things pretty or wow folks with fancy visualizations is strong, but for something like this sticking with the basics is the best

Some things that people really liked:

  • Explanations or callouts of tricky metrics definitions directly on the dashboard. You don't have to include a wall of text but if you remove staff users, for example, from your counts you can throw that in so it's super clear

  • Extremely basic visualizations. I really wanted to get fancy with things, but what folks really wanted was something that was easy to understand at a quick glance

  • Clear labels and explanations that don't sound data jargon-y. I know some folks are very anti-labeling your chart axes but it really does help with communicating your data (at least I think so :D). Making all the labels clear & consistent really won folks over

These are relative to my process and dashboard and might be different insights for your company.


I did not want to spin my cycles too much on getting feedback and iterating, so I committed to doing two rounds of feedback and then decided I would build & ship the dashboard. I knew feedback would come over time as folks had time to sit with the dashboard, and spinning too many cycles on what folks liked/didn’t like would eventually be a waste of time.


Step 4: Build your dashboard!




Tasks to accomplish during this step:

  1. Build a version of your dashboard in a BI tool

This one is more obvious, but at this point, I had a set of headings and one to two metrics for each section. In Mode I also needed to write the queries to calculate said metrics because we weren’t using a tool like dbt at this point.


I started by creating four main headings:

  • 🦾 Growth

    • This section includes metrics like monthly new users or any other entities you keep track of to show the growth of your business

  • 💰 Money

    • This section includes revenue metrics ARR or MRR

  • 💜 Engagement

    • This includes engagement metrics like monthly active users or active percent

I also aggregated a few tiles at the top of the dashboards to sum up core metrics like total users, total databases, etc to give folks a quick visualize reference if they want some “wow-ing” stats.


Step 5: Talk about your work internally



Tasks to accomplish during this step:

  1. Create documentation for your dashboard

  2. Talk about it!

I am probably biased, because I am documentation fangirl. Creating documentation for your dashboard helps inform other folks in the company and develops a shared language around metrics and reporting. I made sure to cover the following points in my documentation:

  • Is there anything about the business intelligence tool that folks need to know? How to navigate it, how to sign in, things like that

  • How do we define our core metrics (both with words and SQL)

  • Where do folks go for questions if they have them?

I created a short demo video (less than 5 minutes) giving a walk-through of the dashboard and how to interpret each metric and folks responded really well to that. All of the documentation for my project lived in GitHub (post coming soon on using GitHub to manage your data team's work!) where everyone in the company could access it.


It’s important to talk about your work. It’s even more important as a team of one! Most companies have an internal sharing platform, Slack, or at the very least email. Once finished, write a short but meaningful post about the dashboard, what’s on it, and where folks can find documentation & training. Drop that link in a public room in Slack and spread the world of your new dashboard.


Step 6: Be reflective




As I said above, I love to write stuff down. For big projects like this I often conduct an informal retro with myself to cover the following:

  • What went well?

  • What didn’t go well?

  • What would you do differently knowing what you know now?

The process does not have to be stuffy at all. I usually timebox it to 30 - 45 minutes and write out a few bullet points for each so that I can take those learnings to my next project.


Thanks for reading this far and I hope that you found this helpful I’m not trying to be overly prescriptive about the best way to do something but this worked for us. The dashboard has been around for 6+ months and:

  • 64% of the company looks at it at least one time a week

  • 2 of the core teams use charts from the dashboard for weekly metrics meetings

I believe that the success of this dashboard is due to the time spent getting to know the initial stakeholders who did eventually become the biggest users/advocates of it! Also writing stuff down and sharing it publicly with others helped as well.


I am constantly iterating on this dashboard based on feedback from folks and as our business priorities and goals change. I think it’s important to keep this in mind that, unless your company is in a highly stable place, your metrics and the business motivations might change so your dashboard will have to as well and that is okay!


🤠


24 views0 comments
bottom of page