Prioritising a data platform product backlog
I recently wrote that I don’t like to use user story mapping. And I don’t for large initiatives requiring software development. However, user story mapping is probably well suited for data platform product backlogs. So let me nuance how backlog management for data platforms is different from product backlog for traditional software development.
From a functional point of view data platforms are quite simple once the architecture is established. We can integrate a new data source, do transformation and a simple data model with 100 hours of engineering and without impacting any business processes. When we first established the data platform, I didn’t think there would be much to it. But I learned that is it isn’t easier — it’s just different.
The number of stakeholders is large. A business application is usually used by a specific business area but data platforms are used by the whole organisation, and as a product owner I have to prioritize between stakeholders that have little in common. The teams that provide reporting for management often get priority. However, in an organisation that strives to be data driven, business value — not rank — should take priority. To prioritize, I usually focus on two things.
The first aspect I focus on is: Will the data provide insights that can help us plan strategic initiatives? I deliberately focus on planning initiatives — not on following up on them — because we want data to support decisions, and not be a decorative stucco we stick on afterwards. As product owner of the data platform, it is important that I am aware of the business objectives and in which direction the strategy is going. Sometimes, I need to proactively suggest to stakeholders responsible for strategic initiatives that they include reporting and analytical capabilities in their delivery. As the organisation transition to be more data driven, I also consider it part of my responsibility to inspire my colleagues to think differently about how data can be used.
The other focus I have is: Can data be used for insights that are relevant across the organisation and thereby help break down silos by increasing transparency? Sometimes, I see synergies across business areas that the stakeholders themselves do not see, and in these cases, it is my responsibility to bring that to light. Prior to the data platform, our data analysts had to manually extract data for a particular purpose, transform it and visualise it. Another stakeholder might then ask for a similar thing on another segment. The analyst then had to do the same all over. With a data platform with automated pipelines, it takes longer to get data sourced and the transformation and modelling implemented. But once it is in place it can be reused over and over without additional effort. Again, this requires another way of thinking about how we use data.
Another challenge is to make sure that value of a delivery is sufficiently explored. Often stakeholders will just ask for a report that includes specific data (often from a new data source) without describing which decisions they need to make using the data. This makes it difficult for me to decide whether data already available on the platform can be reused thereby delivering value faster. When it is difficult for stakeholders to articulate their need, I sometimes create a quick report with a simple visualisation and a minimum of data. I am not a data analyst (but I understand well how the data was produced), and I don’t know all the fancy features of the data visualisation tool. Honestly, in these cases it is to my advantage, because the simpler it is, the easier it is also to relate to. If they are happy with that, great, then a data analyst can work with them to make the final report. If not, it is a starting point for discussing what it si they might need. For this reason, I have a data product with the only purpose of displaying which data is available on the data platform. Some stakeholders use that collection of reports as a reference, and with others I use it to show them available data and what else they might want to use that for.
As the organisation I work for want to increasingly base decisions on data, these two challenges become more apparent. More stakeholders need data, and we need a mechanism for making sure that whatever the CEO wants doesn’t always take priority over everything else. A team manager might have a need for data to run their team which is just as important. As a data driven organisation, we want to prevent HIPPO (highest paid person in the office) decision making and this should apply to decisions regarding the data platform as well.
