Dash Studio

Problem

Keeping Up with the Times

Some months after launching Particle with my team, I became the Product Manager for AppDynamics Dashboards. Visual dashboards are critical tools for conveying critical performance data. They allow custom mashups of data in a pleasing style that can be shared with others.

Custom Dashboards had been in AppDynamics since the product's first version a decade earlier. Over that time, customer complaints had piled up about the high degree of effort and time needed to create good dashboards. Several attempts had failed to remake the platform in the midst of competition from newer tools such as Grafana. The existing product was built on outdated absolute positioning systems that were brittle and difficult to edit. Even so, Custom Dashboards represented over 70% of the day-to-day page views across all of AppDynamics, with over 100,000 new dashboards created each year. They were too critical to ignore.

The previous Product Manager understood that change was needed and had spun up another effort, but it was far from market-ready. Upon inheriting the project, my goals were to evaluate the foundational work that had been done so far, re-engage with customers, build a prioritized roadmap, and work with the team to finally bring it to market. This is how Dash Studio was born.

Analysis & Vision

Engaging the Dashboards Community

I focused on re-engaging and growing the user group, interacting with users across many customers via the AppDynamics Community forums, and conducting direct feedback sessions to holistically analyze the role of Custom Dashboards at a variety of customers.

From these interactions, I learned that:

• Thousands of dashboards had been built in the old system using very rudimentary and brittle approaches, such as layered SVGs to make traffic light performance rollups.
• The out-of-the-box widgets and controls were too basic and ugly.
• The existing tool presented layers of confusing popup windows that caused lots of frustration.
• A complex dashboard could take hours and hours and an academic degree to build. One power user said it took him 28 hours to build one of his team's most critical dashboards!
• Building a great dashboard was often so complex that customers needed to engage with our Professional Services team. The onboarding experience was also nonexistent.
• Custom Dashboards felt disconnected and separate from the rest of the product, but teams turned to them because most of the other AppD screens were inflexible and lacked the information they needed.

I conducted competitive and secondary research and found that Datadog, Dynatrace, and New Relic had all overhauled their dashboarding tools. I decided to continue down the path of building a new dashboards platform that could eventually power data visualization across all of AppDynamics. While I understood that a significant redesign would present risk and customer pain, it aligned with the long-term strategy for the company.

Planning

Priorities, Roadmap, and User Stories

In a perfect world, we'd be able to build the ideal product in as much time as it needed. But in reality, we must make smart compromises in order to achieve quality. This challenge is often illustrated using the PM Triangle: Cost, Time, and Scope.

The Dash Studio team, while not large, included talented developers and QA engineers. Due to customer escalations, executives set the expectation that we'd have to ship something within 6-9 months. So my main level to pull was Scope.

I wanted to establish a “Minimum Lovable Product” (MLP) that would do the most important things for users while feeding a longer-term roadmap. I built a sort of “Maslow's Hierarchy of Dashboarding Needs” with three priority buckets:

• Priority 1: Dashboard authoring and responsive layouts to greatly reduce the time to value and improve satisfaction. We needed to have an elegant data binding experience that allowed users to create dashboards in minutes.
• Priority 2: Beautiful, powerful out-of-the-box data visualizations. Our new widgets needed to address a wide range of use cases, scale to large datasets with excellent performance, and look beautiful on any screen.
• Priority 3: Specialized use cases for collaboration and time range comparisons. These included much simpler dashboard sharing and comparing datasets for critical business events, such as Black Friday for retail customers.

I created a roadmap and worked closely with the Design and Engineering teams to develop T-shirt estimates of the effort. I also got very involved with developing epics, user stories, and general acceptance criteria around UI performance, accessibility, and screen resolutions.