Ship your dashboard before you ship any product
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...
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.
There's been a lot of great thinking on dashboard and metric development, here are some posts I've found helpful...
Generally, the approach I've seen work well in developing what goes on a product 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.
There are a few tools that will accelerate your product team's ability to ship and review new 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 :)
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.