I work on the reporting team at HubSpot, and have for some years. And things have definitely evolved on the product during that time. New team members have come and gone, new organizational developments and projects have kept us on our toes. But the biggest and most powerful change has been our transformation into a true platform team that creates things that can effectively scale all over the product. It wasn’t always this way.
In the olden days of HubSpot, for instance, if the email team wanted a chart, the email team sent one of their engineers deep into what we’d come to think of the High Charts Wasteland, where they would wander among earlier examples of similar reporting and charting, and eventually just commence to build a new thing themselves. In the High Charts Wasteland, anyone can build any chart to any specification, with no concern for consistency across chart styles and options. If the social team wanted a bar chart, the social team sent one of their engineers deep into the High Charts Wasteland, and that engineer returned with a new beautiful bar chart that served their purposes and needs. If another team wanted a bar chart, their engineer went on a similar journey and returned with another beautiful, but slightly (sometimes very) different chart indeed.
This was all fairly suboptimal, as the kids like to say.
Each engineer was using different data, and their designers were using different types of information architecture and labelling, resulting in wildly different chart styles and formats. Users were often confused by the many slightly different bar charts they encountered, and the 30 slightly different meanings of words like “views” or “visits” that accompanied them.
But the thing is, HubSpot runs on and prizes deeply our value of having small autonomous teams, which allows each of us to move quickly to solve for the customer with minimal dependencies. So we rely less on opinionated rules and systems than other, less autonomous teams, and more on guiding principles and good judgement to shape what we do.
It became clear to us that we needed to find a middle ground by offering our teams a true reporting platform. Autonomy is great, but duplicating efforts and providing an inconsistent user experience is not. We knew it wouldn’t erode anyone’s autonomy if we offered a platform of consistent charting components, and a framework to approach using data in the product, then let each team solve for their customers in their own way. So that’s what we set out to do.
Still, asking a group of people to change the way they do something is hard. People have habits and workflows baked into their existing process. People don’t know or understand your proposed improvements at first. People don’t know what they’ll get out of it or how it will benefit their customers. People fear it will slow their team down or create needless bureaucracy.
So how do you convince people to change their process?
What happens when you make something that slows people down, or worse, doesn’t work as promised? They lose trust. They will never try to use your solution again. Your coworkers are the customers of your process proposal. If you don’t show people that your recommended change in process will make their day easier, and their work faster, they won’t invest in you or your efforts.
We provided a selection of standard charts and a guide for how to think about them. As a reporting team leader, I made myself available to guide and provide feedback if the new self-service system was too daunting for designers or product managers to navigate. Our engineering team built us a sandbox so engineers could build their own reports.
One problem we faced was an inconsistent depth of reporting across different parts of the product. Users would sometimes see a simple dashboard with one date filter, while other times they’d be able to look at their data through many lenses and explore it in depth. We took the time to identify the two approaches and prescribe their best use in the product.
We defined the first type as a dashboard and the second as an explorative chart.
Dashboards are for “best of” types of data presentation, usually with some default start state to make it easy to use. Some filtering is possible, but for the most part, they should be understandable at a glance so you can move on with your day.
Explorative tools help you understand the full scope of your world. You don’t even need to know exactly what your question is before you dive in. You can wander around in your data and poke at the edges. You can drill down, go deep, then pull back out again for the overall view.
We had plenty of customer feedback that told us we had a problem that needed to be solved. Customers wanted more consistency between reports across the product, and they wanted more power to find the data they wanted to see over time. It’s not an unreasonable request, and it was one we knew we needed to fulfill.
So our teams would be motivated to make the change if they could see that it would solve this customer pain. We did even better than that. We made it clear that using our new reporting platform wouldn’t just make users’ lives less painful, it would give them more joy.
First, by using the reporting platform, customers would see much more consistent numbers across different tools. This would improve trust in the data we gave them wherever they were in the product. So if they checked page performance in one place, and then found that data again somewhere else, the numbers matched up. This sounds like a simple proposition, but anyone who has worked with a large product group consisting of many small, autonomous teams knows it’s easier said than done. Well, the reporting platform made it nearly as easy to say as to do.
Another benefit was that using the platform gave our user more freedom to customize the tool to their own unique needs. Tapping into a product-wide reporting platform meant that customers could add any chart to their dashboard no matter which tool it came from. Again, it seems like a simple thing, but it was only going to be possible on a fully supported, cross-team reporting platform.
This was another obvious area of improvement we could offer our teams. The old process of sending an engineer into the High Charts Wasteland was an incredible waste of time and often led to confusion and frustration on individual teams. Offering a platform that promised grab-and-go service of just the reporting your team needed, in a way that would be consistent and clear right out of the box, was a very easy sell to our internal teams.
We offered a lot of help and support to the teams that wanted to migrate to the new reporting platform, and made sure they knew they didn’t have to do it alone. Our Tech Lead Zoe Sobin was instrumental in making this switch as painless as possible. While migrations are never easy, ours was once again supported by the motivation that the old way wasn’t exactly pain-free, either. Together, we helped every team move their reports to the new platform in less time and with fewer problems than anyone expected.
Communication is also key in any change management process. We created and circulated a helpful diagram to explain the process and system so that everyone knew what the point of it all was. We took every opportunity available to roadshow this diagram internally, talk about it, explain it, answer questions, and calm fears, until we’d built up demand for migration to the reporting platform and built a huge backlog of trust that it would go according to plan.
The reporting platform is now three years old and still going strong. The framework supports our commitment to small autonomous teams that can move fast and solve for their customer needs, and it’s giving our customers more of the consistency, freedom, and flexibility they want from their reports.
We will, of course, keep working to improve and add to the ways in which our reporting platform can help support great work on our teams and great user outcomes. And we’re happy to report that the High Charts Wasteland is no longer a place anyone — HubSpot team member or customer — needs to go anymore.