Build Analytics Products, Not Reports
With one simple mindset adjustment, you can transform your reporting approach from reactive and tactical to proactive and strategic. Along the way, you can change how the wider organization sees the value you provide.
How can you accomplish all this? By treating the dashboards, reports, and analytics you provide as a unified product.
Too often, reports and dashboards are considered requirements within some other product or project. Even worse, sometimes reports and dashboards are simply delivered upon request, without being tracked or grouped together.
Instead, create an analytics product: a grouping of all the related reports, dashboards, trend jobs, and reference tables related to fulfilling a set of requirements for a defined audience.
There is clear value in approaching reporting and analytics as a product, including:
- A more strategic approach to design
- Higher expectations for your reporting and analytics
- Clearly communicated value to the organization
A More Strategic Approach to Design
Product management provides structured processes for thinking through the requirements that a product should fulfill to provide value.
Regardless of which product management approach you apply, treating your reports and dashboards a product prompts you to think strategically about what you are building and why.
The first step will be defining what exactly the product is. Simply setting out to create “some incident management reports” is too nebulous for product-focused thinking.
Instead, one analytics product might be Major Incident Triage Analytics, using dashboards to easily drive quick responses based on information drawn from Incident, Change, Outage, and CMDB tables. Another product might be an analysis of incident trends, looking for patterns that would inform support staffing levels or changes to key technology.
Each of these analytics products will likely encompass multiple dashboards, each aimed at a different audience, with underlying trend jobs, reports, and reference tables. Thinking of these dashboards and reports as one product prompts considering how they work together – does the technician’s dashboard prompt actions that improve the KPIs tracked by the executives?
Product-focused thinking will prompt you to ask questions like: what do different audiences need from our analytics product? How do we make this analytics product more functional? How do we expect the users the product to interact with it?
Higher Expectations for Reporting
A natural by-product of this strategic approach to designing dashboards is that you will find that you are asking more of your dashboards and reports.
Reporting and analytics can be simple or extensive; it can provide insights shallow or deep. By focusing on the potential use cases that an analytics product can solve, you will naturally find yourself asking more of the reports.
When reports are simply the last checklist item when deploying some other project, the result is usually simple reports – simple lists, pie or bar charts. For example, an incident management dashboard might go live with a few charts that break up incidents by category, location, and priority.
On the other hand, designing an effective product will prompt you to create more advanced reports to accomplish more. Rather than waiting for a stakeholder to come with a requirement, you’ll already be building high-impact dashboards that go beyond the lowest common denominator.
For example, one large international food service company used Explore Analytics to create an analytical product about their company’s end-customer experience. Because their focus was on a product – comprehensive insight into customer activity – including information from ServiceNow, their call system, and their chat solution was a day one requirement. Why? Because the analytics product only made sense to their users if it included all the information. As a result, they were able to break down silos of information and communicate to stakeholders outside their IT organization in business terms.
The following screenshot shows a similar dashboard example, including information from chat queues, a call system, and ServiceNow incidents to meet the basic requirements of a call center analytical product:
Clearly Communicated Value to the Organization
Once you’ve defined the analytics product, including clear use cases for defined audiences, you are already on your way to communicating the value of your analytics products to the organization.
Defined analytical products give you a concrete and limited set of products to describe, each with a host of use cases and value to deliver. This is much easier to communicate than potentially thousands of reports and trend jobs with no clear relationship.
In the customer experience example above, the analytics product had value that was naturally easy to communicate to executive management. By providing an end-to-end, packaged solution, executives could see the impact on strategic thinking across departments that such mature analytics could bring.
With such comprehensive solutions in hand, asking for the resources you need to reach the next level becomes a straight-forward conversation. Rather than reports being an afterthought that deliver low value and merit little investment, you can place analytics in an important place on your development roadmap.
Create Strategic and High-Value Analytics Through a Product-Driven Approach
As we’ve seen, packaging analytics into products creates a framework for strategic thinking. Thinking about products is the gateway towards an ambitious, proactive approach to reports that deliver high value to the organization. Finally, communicating to executives in terms of analytics products enables clear communication about the value of such analytics and the investments required to deliver more powerful, impactful dashboards in the future.