Early on in a new product initiative (in what eventually became Personas), our head of sales operations presented a new product sales dashboard at our team meeting.
That new product was in its infancy. We had no paying customers. We'd spent most of the prior year developing the product with early beta testers, who were using the product for free.
And here we had a very professional sales dashboard, pretty much zeroed out across the board. A blank canvas, waiting for us and our go-to-market teams to paint something beautiful.
How would we ever turn this dashboard green?
We spent the next 12 months reporting to the team and company on this dashboard. We put the dashboard on TVs in our team pod. Some quarters we'd miss and we'd adjust our product and go-to-market-strategy. Others we'd hit and celebrate. We'd pitch each other new features or marketing campaigns, and bring the conversation back to the expected impact it'd have on our dashboard.
The best product teams build their dashboards first. That's because the best product managers are maniacally focused, and a dashboard is an easy way to externalize and scale focus across a team or an organization.
Building dashboard-first means that you develop your dashboard before you develop any product or feature. It reorients you from "what are you trying to build" to "what does success mean for my customers, product, and business?"
A dashboard forces you to visualize the outcomes you want your product to have, and have a clear way to measure that impact.
A well-designed dashboard forces you to think through the specifics. It forces you to answer key questions...
How will we measure the impact we're having on our customers? What does success mean for us?
What data do I need to collect to measure that success?
How frequently will I need this data?
What's the best way to visualize our progress?
And while OKRs, PRDs, and Roadmaps can all answer these questions, a dashboard makes the answers to these questions obvious. If you've answered these questions, you have a dashboard the team relies on. If you haven't, you don't.
What goes on your dashboard?
There's been a lot of great thinking on dashboard and metric development, here are some posts I've found helpful...
Amplitude's North Star Playbook
Segment's Choosing Metrics that Matter
Generally, the approach I've seen work well in developing what goes on a product dashboard...
Simplicity over science - People can quickly look at the dashboard and understand how it's structured and what it's measuring. Metric precision and complexity often go hand-in-hand, so think hard about where you want to land on this spectrum.
Correlated with customer value - We can say with some certainty that moving these metrics will lead to success. This does not need to be causal or perfectly correlated, but something that matches intuition and is supported by data. Be wary of anything that just based off intuition or just based off of data.
Easy to measure - You want something that can be measured easily vs. requires a ton of work to measure. Needing to survey all customers every week may be costly and infeasible. Looking at renewal rates, or customers that canceled their subscription, may be easy.
Find Leading Indicators- Some part of the dashboard should be focused on your leading indicators of future customer success. A metric that could only be sampled a month before renewal — when you need to know 6 months to change the trajectory — would be a bad metric on this dimension.
How to develop your dashboard?
Here's a pretty simple process you can follow to develop your product dashboard. Depending on the product complexity, tools in your stack, and analytics support, you may be able to get this done alone, or need to work with a data analyst.
Draw - First, before writing any SQL or thinking through data sources, draw the dashboard you want. Don't limit yourself to what you think might be possible. Imagine this will be the first email in your inbox every morning iand the new tab screen on your browser...what do you need to know?
Prototype - Take your drawing and turn it into a working prototype. Use the analytics tool you're most familiar with (I recommend Amplitude or Mode Analytics).
Review with your team - In your next recurring team meeting, review the prototype with your team. Ask for their feedback. What types of questions do they want answered, that the prototype doesn't answer?
Schedule - Schedule Dashboard Review as a recurring agenda item at your product team meeting. This creates accountability to incorporate team's feedback from (3) and creates space for the team to review trends and correlate their work with impact.
Tools & Data
There are a few tools that will accelerate your product team's ability to ship and review new dashboards...
Segment to collect and unify customer data
Amplitude to build out-of-the-box dashboards
Recently, our success and product teams ran a project to update the Segment documentation.
Segment Docs are often one of the first steps a new customer takes to get started with Segment, so it's important that these . The goals of this initiative were to (a) improve our Docs and (b) collect the data and build the process to continually improve our documentation.
That process begins with collecting user feedback on specific pages that users find helpful/unhelpful, and reviewing that feedback on our Docs dashboard.
This Connections dashboard gives our team a view across our products, to see how multiple teams were performing across a few standard metrics. I've included the "prototype" below. As you can tell, the hand-drawn prototype can be very rough :)
Necessary, but not sufficient
A great product dashboard doesn't make a great product.
A dashboard is not a product strategy. It's not a "why" that excites and inspires your team. It's also not customer-obsession, or fast iteration cycles, or a high-context and empowered team.
But it does help you — and your team — stay focused on what matters. Build your dashboard first to create that focus.