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

Get involved with Data Mesh Understanding's free community roundtables and introductions: https://landing.datameshunderstanding.com/

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

Frannie's LinkedIn: https://www.linkedin.com/in/frannie-farnaz-h-a7a11014/

Jill's LinkedIn: https://www.linkedin.com/in/jillianmaffeo/

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

In this episode, guest host Frannie Helforoush, Technical Product Manager/Data Product Manager at RBC Global Asset Management (guest of episode #230) facilitated a discussion with Alla Hale, Senior Data Product Manager - Digital Capabilities at Ecolab (guest of episode #122), and Jill Maffeo, Senior Data Product Manager at Vista (guest of episode #151). As per usual, all guests were only reflecting their own views.

The topic for this panel was broadly data product management and the role of the data product manager in a data mesh implementation. Data Product Manager is still a very nascent role so there is still a lot of confusion around it :) If I were to sum up the feeling of the conversation very succinctly, it would be: it's early days, have patience.

Scott note: I wanted to share my takeaways rather than trying to reflect the nuance of the panelists' views individually.

Scott's Top Takeaways:

The role of the data product manager is pretty wide-ranging. It's easy to get overwhelmed and not focus on what really matters. We have to be patient as we learn best practices around data product management because it's still a nascent space.
It's crucial to focus on who the user of a data product will be - whether that is an intermediate user creating a report for another or someone directly consuming from the data product. It's very easy to lose sight of what is the exact use case and how will people use the data product - to consume information. Data for the sake of data is just expensive 1s and 0s.
There isn't even a common understanding of what a data product is, no standard definition. So data product management is even tougher to define in many ways. It is still a very emerging practice so everyone is still figuring it out. It's okay if things are a bit messy and muddled, they are for everyone else too.
Because there isn't _really_ a tangible UI (UX is also a bit muddled) to a data product, it's really hard to get a good understanding of the boundaries of a data product. People don't have an experience with data products like they do with most types of products, digital or physical, so you have to have some patience as people figure it out.
There are a ton of learnings we can bring from physical and digital/software product management to data products. Some things only need small tweaks to work well. But be prepared for lots of trial and error so make more room for experimentation than you would in software.
What is a data product team - or is there a data product team - is a question every organization has to ask. And the answer for each org probably evolves too. At first, as you are figuring out how to build and manage data products and your platform is immature, you probably have a team specific to data products. But eventually, for many data products/domains, there will likely simply be a data product developer that is part of the product team or data product development will be among the general team's developer duties and product management gets a bit more fuzzy.
Product marketing is a relatively foreign concept in data products. But it seems there needs to be far more interaction with existing and potential users of a data product to add value to existing use cases and create new use cases. As of now, that responsibility probably falls on the data product manager unfortunately.
The best path to developing a very valuable data product is 'consuming stakeholder' engagement. If the consumer isn't engaged, if they aren't giving the necessary information to really develop the data product to solve a use case, consumption seems to be below expectations across every org I'm seeing.

Other Important Takeaways (many touch on similar points from different aspects):

User Experience (UX) is such a crucial part of essentially all product management - how does that play in data products? Is it on the platform team to create the UX and the data products just plug into that UX? Is that just the UI? How do documentation, number and types of APIs, interoperability/interconnectivity to other data products, etc. factor in?
We need more adoption of forward-thinking/leaning product management practices in data. Instead of only being reactionary to requests, how are we going to extract what people want next?
Data products are so new and so many people have preconceived notions of what the phrase should mean or does mean. Be prepared for lots of work on alignment just around the definition of data product.
Be prepared for friction when introducing good software product management practices to data. Many data people aren't used to really interacting with product management/managers so they will require some time and hand-holding.
Getting buy-in for the budget to put the proper amount of data product management/managers in place might be a little difficult. Especially when you start to ask where that budget comes from. Make sure to have these conversations early in your journey and adjust as needs arise.
Similarly, a common issue in software product management is a PM is too overloaded to talk to customers or potential customers. That's even more likely to happen in data product management if you aren't careful. Really focus on making sure there is enough time for product discovery or you will be doing development by request only.
Defining data product success metrics - broadly and then specifically for each data product - is going to be a struggle. Usage is an indicator but not comparable across data products for instance. That doesn't even get into the challenge of then measuring the success metrics. But you just have to start and starting with mediocre metrics is better than not starting at all.
How the heck do we think about A/B testing relative to data and data products? Do we have enough consumers to test? What does it even mean to A/B test data?
Similarly, experimentation is key to doing data better. But can we experiment around the data itself? Or are we just using data to power and measure experimentation? Maybe experimentation around interfaces to data?
Data products have a lifecycle. If you are unsure of the value of a data product to users and you can't really get them to articulate it, sometimes shutting down the data product - at least temporarily to do the 'did anyone scream' test - is going to be the right call.
It's crucial to balance long-term product sustainability with time to market. As you learn more about building data products, many organizations are seeing decreasing time to market of new data products but especially at the start of a data mesh journey, it is really easy to create non-sustainable/maintainable products to match requests instead of needs in a productized way.
We can create data products that answer questions that 'should' be asked, but should we? If we are sharing insights that are not ready to be leveraged or are not what the stakeholders care about, what will adoption be like? Thus far, it seems like most data mesh implementers are saying adoption is below expectations for proactive data products not created to specific stakeholder-defined use cases. Hopefully that changes as we increase data literacy but important to consider.
It's crucial to consider interoperability and cross-domain usage/queries as part of your potential user flow but it's also very hard to try map ahead when you aren't sure of those use cases. We can easily lock ourselves in and reduce flexibility, which then might become like a data warehouse, just micro-warehouses everywhere…
It will be interesting to see where data product managers come from - if they come from traditional product management, they have to learn a lot of the hidden nuances of data. But coming from data, it's easy to get too tied into the data work instead of what is the data product supposed to do.
Figuring out where data product management reports will be important for organizations. It could be into the data team, it could be into product org, into the domain, or maybe even the CTO. There are definitely puts and takes to each. Personally, I think they should start reporting into the data org and eventually move to being part of the product org or reporting into the domain itself because data ownership and data products are just a part of a domain's mandate.
Frannie asked a great question: should the data product manager own the data product strategy? And what even is a data product strategy? I feel like the answer is yes but that data product strategies will be very immature as people learn how to build and manage data products. Who should own the overall strategy across all data products?
It all starts from the user and use case. To build a good data product, you need to understand how people are going to use it. But then, are we building one-off instead of universally usable data products? I think you start from a use case and build out, expand out but maintain as much flexibility as possible.
Product discovery - the process of finding out what products you should build and what are the useful features to add to those - is really important in product management. But it's far more challenging in data because everyone always says yes to 'do you want more data?' How can you determine what will be used and valued? Where is a real use case versus a 'that would be nice to have'?
Data product management should extend into what data do we want, what incremental data should we generate, not only what data do we have. As Stephen Galsworthy talked about, especially with hardware, you often don't get to change what info you are collecting. Data sourcing is going to be part of data product management.
Maybe good data product marketing is just being highly available and willing to explain - having office hours and show and tells. If trying to generate new uses cases from unengaged potential users isn't driving great value, maybe it's all about inbound marketing, not outbound.
Much of the value in data mesh is cross domain use cases and that value is captured by combining information from different data products. But it seems we are still early days in figuring out how to communicate some of the potential questions out there to design good data products to answer them.

Learn more about Data Mesh Understanding: https://datameshunderstanding.com/about

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

#432: Migrating to Pydantic 2.0: Beanie for MongoDB

Talk Python To Me

Reasons for Using MongoDB as a Document Database

The AI-powered Podcast Player