3 steps to value focused data product management
Practical steps and frameworks to get a data team delivering value fast and to keep laying golden eggs (apologies I couldn't find a better cover image...)
This is the first in a new article type that is more of a practical how to guide. If you’re subscribed and this is not your thing you can choose what article types to subscribe to (instructions at the bottom of article).
Many data teams, and particularly data teams that have grown out of a BI role (formerly or otherwise) have a messy and complex portfolio of work that stems from being order takers.
If you wish to pivot from BI to becoming a high value data product team these are the steps to go through.
Step 1 - Setup a Value Gateway
Just like a Technical Design Authority (TDA) ensure project work can only start with the right technical assumptions in place, a Data Product Value Authority (DPVA) ensures that work can only proceed if it is likely to deliver material benefits.
Gateways are generally not seen as a good thing and this should be kept as lightweight as possible. In the last organisation I worked in a equivalent to the DPVA was held as a one hour discussion with no slides and max 1 page of pre-read.
The aim of the forum is to make sure that everyone understands the route to value and how value will be realised. It helps to have a set of templated questions, but treat the following as prompts (you don’t have to ask them all)
Context - Why is any work needed?
Background: What’s the business area? How does it create value and what are the challenges?
Cause: If there is a business challenge what is the route cause?
Why now: What is the trigger for doing something now? Is there a crisis or a decision that needs to be made?
Existing work: What data/analysis already exists in this area?
Value - What is the value and how will it be measured?
Do nothing: What’s the cost of doing nothing?
Risk: What is the worst case scenario if a wrong decision is made?
Opportunity: What is the best case scenario if decision making was perfect?
Measures: How would success be measured?
Value: Can the benefits be measured financially? Does this relate to a strategic priority?
Data work - What analysis and/or data product is needed?
Opportunity: How could data help?
Potential solutions: What might a solution look like?
Proof of value: Is there a way value can be proved before developing a solution?
MVP: What is the minimum amount of data work needed for value?
Business change - What other work is needed to get value from the data work?
Decision: What decision will the data product be used to make?
Stakeholders: Is everyone that is involved in decision making agreed with a need for change?
Dependencies: Is value dependent on other business changes? If so what?
Resource: Is there resource available to implement these business changes?
Don’t worry too much about precise value measures. Ideally three voices are needed to approve a project going through and their judgement is sufficient:
Decision/Process Owner - The person responsible for the decisions that the data product will be used to make.
Data Product Manager - The person, in the data team, responsible for managing the data product.
Benefits Assurance - An independent voice (typically finance) to check the value assumptions so that the data and business team are not marking their own homework.
Note - a common question I get asked is does this approach kill innovation. It is OK to have max 10% of your resource dedicated to innovative work that does not go through as formal a process. However this work should not produce any products that require ongoing support without going through a DPVA.
Step 2 - Report on value to manage it through
The next challenge is that is can take a long time to get value from data work.
In order to maintain stakeholder confidence and keep the business accountable for getting value from completed data work, it helps to report on value at key points:
Backlog of verified ideas - The value of potential data work that has been approved at a DPVA but no work has commenced (e.g. no resource available)
Proof of value analysis complete - The value opportunity has been proven through quantitative analysis.
MVP complete - The data work is not complete, but there is enough of a solution for some benefit to be realised.
Product development complete - Development of the data product is finished.
Value realised - Analysis has shown a measured improved in a business outcome as a result of the data work
Start reporting the value of data work like this and you will often end up with a chart like the below, which shows that the data team are doing their job but more support is needed for change management.
Step 3 - Put a process around all of this
Now that you are only doing data work that can lead to value and are reporting on progress, you need a process to support failing fast and doubling down.
Failing fast is stopping a data project when it turns out the value assumptions were wrong and there are no or few benefits to be realised.
Doubling down is putting more resource behind projects that are proving successful and where significant value is starting to be realised.
The easiest way to support this is with an agile project management cadence that regularly reassesses projects (at least every 12 weeks) to decide whether work should stop, continue, move to another phase or additional resource should be made available.
You need to customise this cadence to your organisation, but below is a template to get you started.
Bonus tip
One issue this doesn’t deal with is technical debt.
However, once you have been running the team like this for a while add a resource reporting chart to your update pack that shows how many people are working on new work (against each project), how many people are working on old work (tech debt) and how much opportunity is in the backlog.
Use this to make the case for investment in people and tech to resolve the tech debt and deliver more value.
Please comment with your thoughts and lets co-develop the leading approaches for data.
Poll
This is the first framework post I’ve done. I’m considering setting up a wiki area where we can collaboratively develop and establish frameworks for running data teams and data professions. Would you use this?
The Datent newsletter has three feeds (long form articles, practical tips and monthly updates) to subscribe to only one of the newsletters click on the subscribed tick below.
This will take you the settings page where you choose which newsletters to get notifications for.
Benny, this is a fantastic blueprint. A lot of it is very similar to what my team and I do already, and the rest (esp. step 3) are ideas I'm going to shamelessly take and pitch we start using asap. :)
In my version of step 2, I also have a step that's about proving the concept from a technical feasibility perspective. This isn't about conflating TDA with DPVA - it's to be able to have a reasonable idea as to what the value might be, specifically for more sophisticated data and AI products where the expected uplift can't be estimated using a back of the envelope assumption alone (at least not always).
The two questions this exercise answers for me are:
1. Can we even [predict/classify/optimise/etc] the thing we're looking to do?
2. What's a reasonable guesstimate on the projected uplift for the first version? And maybe also a more mature v2?
For some use cases, this isn't needed. If it's a problem we've seen solved many times before (personally or through literature), or if the assumptions are easy to tease out of domain experts, then you don't need to do a mini version of the project beforehand. But other times we've found ourselves having no idea if we're aiming for a 2% uplift or 10% or 0.5% until we spent a few days building version 0.1 of the product.
Curious to hear if you buy into this distinction of more predictable vs less predictable data products for the DPVA, or if you'd push back by saying the above is trying to be too precise/scientific about it.
How do you deal with requests that you may not have the skillset within the existing team or tools to complete. Do requests of this manner enter a feedback loop into the TDA or do these go onto the backlog until business value in products you can deliver is realised? I am thinking asking “..can I have more Sir?..” needs to have some hard evidence of proven business value.