#122 Unlocking Your Data Value Through Good Product Practices - Interview w/ Alla Hale

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.

Data Product Manager Role on Alla's team: https://jobs.ecolab.com/job/15770737/data-product-manager-barcelona-es/

Alla's LinkedIn: https://www.linkedin.com/in/allahale/

In this episode, Scott interviewed Alla Hale, a Data Product Manager at Ecolab. To be clear, she was only representing her own views rather than anything on behalf of the company. She is hiring in Barcelona as well, see here

Some key takeaways/thoughts from Alla's point of view:

1. The most useful question in your quiver as a data producer is "what value would having this unlock for you?" It's not about pushing back, it's about skipping to collaborative negotiation. How can you work together to unlock business value?
2. It's important to remember this when there is a data request: "they are coming to you because they need your help." Act accordingly - with empathy and patience.
3. You need to really consider your data user experience (DUX) for your data products. How can you quickly get people past figuring out "what the product is" to leveraging the data product to drive value? You want users to enjoy using your data product.
4. User stated requirements often do not match actual user needs. To maximize the return on your data work, look to exchange context to find the needs instead of just taking requirements at face value. And do so with patience and empathy.
5. No prototype, no meeting = having something tangible - even if that is simply a process map on a Post-It note - for people to react to. Otherwise, what will the conversation be about? How do you prevent the meeting from being a waste of time unless there is a specific topic to address?
6. We need to take lots of learnings/practices from tangible/physical goods product management when thinking about data products. We have users who have needs. How can we best serve those needs and drive value through that? It's always about serving the users' needs.
7. Another product management learning - how can we do fast prototyping? Prototypes have an actual cost, even in data/software. What gets us to value quickly? How can we capture value early as we iterate towards product quality?
8. All products - and their features - have a lifecycle. Be prepared to prune features or an entire product if they no longer drive more value than the cost to develop + maintain.
9. Discussing sunsetting and pruning should happen with users even in the development process. Far too often, data consumers are used to data assets being available in perpetuity - even as they degrade. We need data consumers to be part of an active conversation about if they are still using something and how to create more value or lessen costs to produce data.
10. How can we avoid the data product manager having to do literal sales and marketing of their data product internally to drive usage? How can the organization make internal communication easier instead of literally marketing data products internally?
11. To really create the most value from data products, there must be bi-directional communication. One, the data product owner should create demand for what is available. Otherwise, why build for reuse if multiple parties won't use your data products? But second, we also need to react to data consumer demand to drive incremental value through new data products or features.
12. You should never develop a new data product without a very specific use case - Scott note: this is a common question in data mesh conversations. It's about 75/25 split on only building to specific use case versus not from conversations thus far.
13. It's crucial to understand the data doesn't make the decision. And only look to measure things that will change your view depending on what the results are.

Alla started with what should data product management take from general product management based on her time managing products in a number of tangible goods spaces. Start from the basics: you have a user and they have needs that you want to try to meet. And that you are responsible for discovering and summarizing those needs, not that the user should understand all their needs upfront - that just leads to requirements that often don't actually address needs... Just be careful to extract needs and push back on requirements with patience and empathy. But it all starts with needs, not the data.

Alla gave some thoughts on needs versus requirements and expectation setting. Consumers understand in a physical goods space that you don't just magically have the prototype or product - but with data, there is often the misconception that "you already have the data, why can't you just share it?" So you often have to start conversations with setting realistic expectations - realistic expectations about next steps, timeframes, etc. Helping data consumers understand that you aren't deprioritizing them and what's actually possible and when - including why that is - will lead to a better relationship.

There is an understanding that prototypes have a real cost in the physical goods space, we need to make consumers understand it's the same in data and analytics, per Alla. And that different grades of prototypes mean different costs and time to develop - how high of quality do you really need this to be? How high quality do you need for the prototype versus the end-state? And exchange context around what requirements/needs drive what challenges so they might deprioritize needs for you.

Alla's key phrase is, "what would having this unlock for you?" Instead of pushing back by asking "why do you need this?", her framing gets the other person on the front foot, leaning in to the conversation to share what this could mean for them. It gets them to what Scott calls "collaborative negotiation", a process where you can quickly iterate to what's really of value instead of a list of requirements that might not actually serve the needs of the use case. This question extracts more context from the data consumer where you might even be able to add incremental value that wasn't part of their ask. Again, this is not about deprioritizing or pushing back, it is about driving to the business value. Remember, they are coming to you because they need your help.

A general rule Alla has is "no prototype, no meeting." That prototype can be just a small drawing of a process map on a Post-It note. The goal is if we are going to have a meeting, we are meeting about something - a useful conversation will be about something, something people can react to. This prevents the dreaded update but no actual reason to meet meeting - the epitome of this meeting could have been an email in Scott's words. Instead, concrete aspects of a prototype elicit a response and that response means you can decide where to focus next or if what's been developed thus far will meet needs.

Alla emphasized that in product management, you are designing for people and developing specifically for the user. People aren't robots and we need to give space for emotional responses instead of purely logical ones. And while you are looking to serve user needs right now, those needs might change - or you might fully serve the need with your product so the need doesn't exist anymore. Thus, you need to understand that products have a lifecycle. Don't be afraid to sunset things that are no longer valuable.

As well as sunsetting a product, the concept of pruning should be discussed with data consumers at the start of development. You want data consumers to understand that things will change and some of that is removing "features" of the product - which might be certain parts of a data set or certain ways of accessing the data product - when the costs exceed the value to maintain. You want data consumers to be active in the conversation about what is still useful and what isn't but sometimes you'll probably have to resort to turning something off and seeing if people scream. Hopefully the mesh tooling can give data producers good insights into what is being consumed but even that is often automatic consumption.

One thing that is quite dissimilar in data product management from her prior product management roles is previously, she had partners in R&D, marketing, and sales in the process. Many parts of what each of those roles added to the product were crucial in driving value. How can we make sure we are having the conversations internally to drive usage but without the data product owner and/or manager literally marketing and selling? Alla sees it as somewhat on the data product manager but also a much larger degree on the organization - how are data products marketed internally? How can people learn about new products or changes instead of consumers having to discover every data product themselves?

Alla shared her view that you should never develop a new mesh data product without a very specific use case. This is a common question in data mesh: what should be your reason for creating a new data product - a specific use case or the domain sharing information they believe will be useful?

An interesting concept Alla brought up is that all domains should think about who can benefit - especially who will benefit most - from the data you have. That way, you can reach out to drive towards collaboratively finding a use case to develop a mesh data product to serve that use case. Really consider what you've got and how that could be leveraged internally instead of simply waiting for requests. And it means there is collaboration from the start so consuming domains might be a better partner if you go to them. If your organization is going to encourage this, you need to find a way to incentivize/reward domains finding good use cases for their data.

For Alla (and Scott), a truly under appreciated need in data is the data user experience (DUX). You should aim for consumers actually enjoying using the product. Zhamak has mentioned similar things, especially her love of the book The Design of Everyday Things. Data can be intimidating to many, how can you make it so people don't feel stupid when first working with your data product? As Alla said, look to get people quickly past "what the product is" so they can focus on what the product can do for them.

Alla wrapped up by sharing her view of data-driven - it's crucial to understand the data doesn't make the decision. We need to use data to inform our decisions but at the end of the day, people still make the decisions. And use that thinking to decide what you want to measure and why. Katie Bauer mentioned this too in her episode: if you won't change your behavior no matter what the result is, why should you spend the effort to measure that?

Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him on LinkedIn: https://www.linkedin.com/in/scotthirleman/

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf