Using data to inform product and feature prioritization decisions
As a Product Manager, I have become comfortable with the idea of having a never-ending to do list. There will always be more bugs to fix and features to build, and thus, knowing how to prioritize that list of feature requests and bug fixes is an important part of a Product Manager’s job. Building feature X might mean that you have to hold off on building feature Y, especially when development resources are at a premium – and let’s be honest, what tech company can say that dev resources aren’t at a premium.
At MediaMath, data plays a vital role in helping our product managers make those prioritization decisions. We leverage a suite of third-party applications and internal databases to pull information on platform usage, feature usage, and performance. Some of those tools include:
We use Google Analyticsfor tracking site-level data such as number of page-views, time spent on site, most popular browser, etc. We had also been using it for event tracking, but it required development work on our end for each and every event we wanted to track.
Our internal databases store data about campaigns, client orgs, and spend, among other things. All of this data is used to inform new features, reports, and UI improvements. For example, real estate on the home screen is at a premium. Reviewing average campaign name lengths can help us make UI decisions for how we handle truncating long campaign names. However, this data primarily lives in our databases, which require you to know SQL to get at and manipulate the data.
The problem we faced was a lack of a central, easily consumable repository for all of that data. Getting answers to questions about platform or feature usage often required writing one-off queries to pull the relevant info or manually searching for it on the third party’s site. Because of this, the data wasn’t getting used as frequently as it should be.
Our hypothesis was that if we built a dashboard/UI that housed many of our commonly asked questions and metrics we cared about, it would help us make more informed decisions as Product Managers. It would provide a standard to better inform future development and platform enhancements based on usage patterns and actual data.
We looked into using a third party app like Chartio, but ultimately decided to build the dashboard from scratch in-house. The reasons we opted to build it in-house were:
- We wanted full control over the data and how it is displayed.
- Outside options were expensive.
- It would be a fun opportunity for a few Product Managers to hone their programming skills.
We launched an MVP (Minimum Viable Product) in early August. Since our launch, the Product team has been using the dashboard to help inform prioritization decisions and improve our client’s daily workflow, and many other internal teams have adopted it for their own purposes.
Fig. 1: A screenshot of our dashboard and visualization of campaign creation data.
The dashboard is by no means done just yet. It currently offers a visualization of the 15-20 most often run queries including top spending currencies, top spending countries, and adoption rates on our newest features. But we still have tons of other data we’d like to include, and plan to continue integrating new data sources.
If you’re interesting in learning more about how we built this dashboard or if you know of another great tool we could be looking at, hit me up in the comments.