Before we dive in, lets first agree on a simple definition of what constitutes a minimal viable product:
“It’s the most basic version of a thing, built with the least amount of effort, that allows the person using it to do what they need to.
Simultaneously, it enables the people who build it to learn how to make it better.”
Having laid this foundation of understanding, we can look to add some complexity. Namely by asking how does MVP translate to data projects?
Well, quite simply. Especially when we consider that gaining rapid trustworthy insights from the data you hold is the primary reason to hold it in the first place.
The very nature of insightful data is change.
Whether that be within the confines of the established data structures i.e., user behaviour trends, or an external event which impacts the organisation, causing a seismic shift in how the data is captured, processed and stored.
The true meaning of MVP for your project
Getting started with a data project MVP’s is often a challenging process; especially for organisations who have various specialist teams contributing to the project. This could be the platform team, the data team, the BI team… the list goes on.
From a Business Analyst perspective, rather than juggling each stakeholder group’s “must haves” into either an unsatisfactory release OR an unachievable monster, it is critical to start with the organisation’s wider context and strategic objectives.
Get a feel for the nature of the organisation, understand their industry, competitors, maturity, size and, arguably most importantly of all, their appetite for risk. Any “must have” use case or requirement which does not specifically support the strategic objectives is up for negotiation with a later iteration.
In practical application, this translates to only implementing technologies that fit the current and short/medium term needs of the data product. Be careful to avoid being blinded by all the sales patter and shiny aspects of available tech, you will end up with costly features which you ultimately might never use.
It is likely that other stakeholders will have little or no understanding of the technical detail or data needs – their main concern, and view of the overall project, might be just the dashboard or report that they see at the end.
The MVP mindset is about getting value realised fast and learning from everything else.
Lock down your MVP
Deep into the analysis of the MVP product you are delivering, you may find yourself at the negotiation table.
Bear in mind, you are looking to limit your scope to achieve the most business value from the least effort, both in usability but also in learning for the project.
Be vicious, if it doesn’t solve a key risk for the organisation or support an objective, it’s probably not essential for your MVP.
A top tip for ensuring all stakeholders adopt an MVP mindset is to document the MVP in some format; diagrams are especially effective.
Say for instance you are delivering an end-to-end data warehouse solution from source system to insight (reports). The MVP is more than likely to be the core infrastructure and security to support a limited number of critical reports which drive the most business decisions/processes.
A visualisation indicating the specific tables which need extracting from source, loading into the warehouse and transforming ready for the key business reports is a perfect way to gain consensus on what you are delivering.
Enabling technical constraints to be surfaced, solution decisions to be made and ultimately a shared common understanding of what is in scope.
Keep focussed
By now your scope MVP is documented and ready for delivery, all you need to do is maintain the focus on the existing needs of the business with one eye on the short to mid-term future to keep yourself honest.
Fight off the temptation to “futureproof” as you go. It can be incredibly tempting, what with the endless technology options and opportunities to build dashboards for every purpose, but you must keep coming back to the question – does it solve the customers immediate and evidenced data need?
If the answer is no, then you shouldn’t do it yet. If the MVP diagram/document is forever changing, you are not going to deliver on time. Keep referring back to the diagram to ensure that what has been suggested is within the scope.
In this light, here are some red flag statements to listen out for:
“We don’t do this now, but…”
“Ideally we would have…”
“These aren’t needed but would be good to have…”
Your MVP data project
Mission accomplished; the MVP has been released for the data project. The business got the value from the reports, the warehouse passed the pen test or whatever other key milestone you needed to achieve.
Now is the time to take stock, go back to the drawing board, prioritise your backlog and in doing so you hit the cycle of negotiation again.
But either before or during this process, take time to analyse how successful your MVP was. Where did it fall short? Who does it primarily serve? What could you have done differently?
Taking time to assess your MVP’s value is the first step to being able to achieve the MVP mindset.
The MVP mindset, especially in relation to data projects, allows you to deliver tangible value to stakeholders, most of whom have no notion or concept of the technology and data details behind the scenes.
