Subscribe to the newsletter!

Data product or data project?

Once you take the decision to build a data product, you will need projects to build certain aspects of the product roadmap.

The one cannot exist without the other. What would be the scope of your data project if you don't define the data product you want to build? How would you get approval to build your data product without a realistic project plan to actually get the job done.

The data product

The data product is the result of a set of well balanced considerations. There are four aspects that a product manager of a data product has to balance against each other. In his vision of the product he has to take User experience, Technology, Data and Business aspects into account. He has to gather user requirements, identify problems and opportunities and prioritize initiatives.

The product management role is a strategic one. Asking questions like what product to build, when to build it and why does it need to get build? You have to keep the big picture in mind and strategize about the most effective way to build a successful data product. The product manager is accountable for the decision of pursuing a project or strategic direction. He manages the product, and not the people.

Once you take the decision to build a data product, you will need projects to build certain aspects of the product roadmap. These projects have to be in line with the previously defined priorities. The project manager starts with a clearly defined scope and estimates a timeline and budget to get the project implemented. The project management role is tactical.

An R&D dynamic

But now it becomes a bit tricky. Data projects have a dynamic of research and development. You are looking for business value in the data and discover it while you are building. Sometimes this leads to a dead end. Or you find out that the data you need is not clean enough to get to an acceptable result. Or you discover you need to include an extra data source to get to more valuable insights in the efficiency of your processes. Than the question is when you discover these unexpected twists. Or you still in the product definition phase? Or are you already in project mode? Then you will probably need to extend the scope and thus budget and timeline of the project.

An experimental mindset to test assumptions and try things out can help to get the scoping of the data product as accurate as possible. Or building prototypes with a product management mindset, o identify business cases, gather requirements and identify possible problems. Then you can industrialize the prototype and put it in production in line with guidelines and best practices as a project. But this already assumes that you have some sort of platform that can serve as a sandbox to built the prototype. And that you have an organizational culture that accepts some of these experiments will fail.

It takes courage

Building successful data products, and running the projects that puts them in place is hard. It takes time to develop the context where you can do this over and over again. And taking the time takes courage.