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...)
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.
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.