Data CX: Data Products are still Products!

As the Data Mesh hype train continues to work its way through the data landscape (with good reason) data departments are finding themselves rushed to build Data Products, often before they have the processes, people or experience to understand what separates products that have the potential for success vs those that are destined to fail.

Data Products are sitting unused and expensively idle at an ever-increasing rate due to the focus on technology and buzz instead of the most important aspect of any product...the customer.

Let's get some fundamentals out of the way...

What is a Product?

I'm not going to overcomplicate this because it's very simple. We'll go with the Gartner definition for digital products, but it's copy/paste for basically all definitions:

A product is a named collection of business capabilities valuable to a defined customer segment.

The emphasis is mine, but these are the key words. A product provides value to a customer, and given the economics of a marketplace it must provide this value in a way that is attributable for the customer (e.g. if I'm paying for your service with money, time, attention etc then I need to attribute a return in value equal or greater than what I am investing for this product to feel worthwhile).

What is a Data Product?

Equally, I'm not going to overcomplicate this.

It's the same thing!

The only nuance is that the product is in the broad category of data (e.g. a dataset, a query, an API, a visualisation etc). Whilst the original Data Mesh papers focus on the technical and architectural implementations of Data Products, this is intended to build on the knowledge of "Data as a Product" which had existed for many, many years prior and was always heavily grounded in product thinking.

With the core basics out of the way there's something we need to address.

Build It and They Will Come

No, they wont.

One of the biggest fallacies pedalled in technology focused thinking is that if you build something that you consider technically worthwhile a band of adoring users will flock to your offering like moths to the flame.

Don't be drawn to looking at the innovations of history that have succeeded and assuming they're the rule and not the exception. 99.99%+ of successful product innovation is customer insight driven and led. Is there a chance that your lightbulb moment will be the thing that instantly connects with millions and solves a problem they never knew they had? Statistically speaking...no, there is no chance.

Now that I've deflated your bubble let's talk about what you should be doing when you start on your Data Product journey (and don't worry if you've already started, the best time to change course to the right road is yesterday, the second best time is today).

Won't Somebody Think of the Customer?

Your Data Product journey should not start at the data product - this is the end of the race, go back to the start line. Products are there to bring value to a customer, so we need to head back to how we can identify value opportunities.

Thoughtworks have a great series on Product Thinking in relation to Data Mesh:

When teams want to start treating data as a product, we recommend working backwards from organizational goals to identifying high-value analytical use cases, and ultimately, which data products are needed to bring the use cases to life.

Data Mesh in practice: Product thinking and development | Thoughtworks

The link above provides value driven templates and blueprints for workshops to help identify the value propositions that can be identified across each data domain and these will help you form the basis for the kinds of Data Products that will fill a customer need.

As you develop your data products make sure you continually revisit your product canvases to ensure that the value proposition and customer intent is in sharp focus as this will drive very different behaviours than a 'build it and they will come' attitude.

Time to Attributable Value

Once you've identified some candidate value propositions and designed some high-level lean products around them you must look to another practical and often forgotten aspect of productisation, your time to value.

Data Products require a significant level of investment given they will often involve sourcing and ingestion of data, modelling, transform and consumption work at the very least. You must have a keen eye on the level of investment (time/effort/cost) needed until this data product is able to surface material and attributable value to its intended customers - and you must do this authentically through a customer lens.

What does this not mean?

• It does not mean that you can demo the data product in dev.
• It does not mean that you can produce a report for the customer and send it to them as a once-off.
• It does not mean that you can connect to your data API with dummy data.

You get the gist. It needs to be authentic customer value as in your customer needs to desire what you have provided them and value it once using it (which will show up through engagement and usage stats). We have all done it in tech and data, patted ourselves on the back for a great release that was on time and under budget completely ignoring that no one is using it. Not this time.

Prioritise for High Value, Low Effort

To assist in reaching your attributable value utilise a prioritisation method that rewards and encourages high value for low effort. The Scaled Agile Framework (SAFe) has the Weighted Shortest Job First (WSJF) methodology which fits the bill nicely.

Having a prioritised backlog of Use Cases to drive out Data Products that deliver high impact value for the minimal possible effort is a sure-fire way to iron out the kinks in your design, build and delivery process whilst making sure you're never too far away from value realisation.

Never Stop Listening

Your first Data Product now rolls off the production line ready to fulfill a high impact use case with some eager customers awaiting some clearly articulated value, great outcome!

Have a well-deserved high-five and then come back down to earth quickly because your job has only just begun. You're now serving real customers with real needs that evolve. This is what Product Thinking is - evolving, learning and continually listening to your customers - which will include both their expressed and unexpressed needs. There are many product and service industries who have spent decades if not centuries perfecting the art of understanding their customers; tap into those expertise and resources as you bring that level of customer centricity and product centric thinking into your data world.

Products Is Products

This was a mere scratch on the surface of what is a very real problem in the data landscape of recent years - the productisation and commodification of data has opened up a world of possibilities and architectural methodologies like Data Mesh have given us the technological blueprints to bring some of those ideas to life, but the time is now for data and analytics teams to evolve (quickly) into the world of product thinking. This is a difficult transition, just ask the software industry that did it a few decades ago, but it is a necessary step to offering sustainable and valuable products to our customers.

Data people - we are all product people now, it's time to embrace all that comes with it.

For more information on Product Thinking I'd recommend the following fantastic resources:

UX Design Books and Articles | IxDF (interaction-design.org)

UX Booth

DesignSystems.com

The Resource Hub for Product Managers (adplist.org)