When working in Analytics, it’s easy to view all the requests you receive as disconnected, one-off events. This is the traditional approach for Analytics departments, where Requests would be collected, prioritized and answered accordingly. But there are some issues with this way of handling things:
- It’s hard to see the bigger picture behind those business questions, especially between departments. Different people may have the same questions but ask them in a different way, leading to different answers.
- When requests are handled individually, it becomes hard to maintain a standard for the way they should be answered, especially if you are working as part of a team.
- Since not all stakeholders are equally Data-savy, they may ask for the wrong thing without letting you know what the questions is they are trying to answer.
This leads to some awkward situations. People will ask for the wrong or suboptimal reports. You as the analyst will become more and more disconnected from the business and don’t know what actually matters to your stakeholders. In bigger teams, the same questions might be answered differently if they are asked by different people. Ultimately, you will run into a situation where people won’t trust your reports and hesitate to request them entirely. But what can you do?
How to build products
Let’s get some inspiration by looking at how companies approach product development. The classic approach roughly looks like this:
- Concept phase. Based on day-to-day observations, market research, trends, or customer pains, Product Management or Sales would come up with an idea on how to deliver value to the customer. Those ideas would be mapped with the abilities and skills of the company to get an idea for a new product.
- Market research phase. In this phase, research would be conducted to scout the potential of the product idea. Researchers would look at the size of the potential audience and possible gains.
- Business analysis phase. Now that we know what we want to do and what the audience is, Business Analysts would take that idea and see what costs and resources are required to develop a product. They would also estimate the sales volume and develop the business case.
- Development phase. Next, Product Development takes over to develop and test the actual product.
- Launch phase. Once we have our product, Marketing and Go-to-Market take over to bring the product to market and let the target audience know about it.
- Maintenance phase. Once customers are using the product, bugs need to be fixed and users get educated on how to use the product best.
- Sunset phase. When the product gets older over time, it will eventually be taken off the market and retired.
This circle would then repeat with the next product that is developed. But with the rise of agile digital development, things have changed quite a bit. Now companies focus on delivering initial value as fast as possible by building minimal-viable-products (MVPs), and then continuously develop them further in product iterations and deliver increments regularly.
Stop building dashboards, start building Data Products!
So, what can we learn from this? Instead of handling every request individually, we should start developing data products for our internal audience. If this means to either build a report or dashboard is up to us as the experts. To do this, we need to be vigilant and get to know our audience quite well. Who are the people you are working with? What are their tasks and pains? How do they deliver value to the business and how can you help them be successful? How experienced are they with data-driven-decisioning?
Once you know your audience, build a Data Product roadmap for your company and update it regularly. Think about the ways you will help your stakeholders be successful and prioritize your work by how big the audience is and how big the value your product delivers is. Then start building and let your business know what you are doing. For this you need to define the MVP scope to build something that is actually useful in a short amount of time. Discuss with your stakeholders what they need to find value in your product.
When that product is developed, you need to market it to your audience and let people know about it. For this you need to ask yourself how you will get the message to your target audience and what that message should be. Why should they trust you and invest their time in using your product?
But things don’t end here: Now that your product has some actual users, you need to collect and incorporate their feedback in product development. On top of the next steps on the product roadmap, there might be bugs you need to fix and UX issues you need to look into. Also, don’t forget that you need to document your product and educate your users on the best way to get value out of it.
At the end of the road, the time will come to finally sunset your product. Business changes, and so does the need for Data Products. You need to keep a close relation to your stakeholders, aka your target audience, and check in with them regularly on how to continue to deliver value.
Now we have defined what the ideal way to develop a modern Analytics practice is. The transition to such a way of working might be hard, but definitely worth the effort. It will lead to satisfied stakeholders and a clear understanding of how your team delivers value to the business.
A good way to start thinking in an agile manner is to ask yourself what the story behind your daily requests is today. What are your stakeholders trying to achieve with your report? Are they doing it in the best way possible? Is there some potential for a new Data Product? Who else would be interested in that?
If agile is completely new to you, it might help to educate yourself on methods like SCRUM and Kanban. A tool like Jira will help to keep an eye on your tasks, priorities and the backlog. Once this is clear to your team internally, give stakeholders access to your tool so they can see what the status of their product is (and why there may be other priorities right now). This will help you manage demand and show that you might need more resources to keep up with it.