137 - Immature Data, Immature Clients: When Are Data Products the Right Approach? feat. Data Product Architect, Karen Meppen
Feb 20, 2024
auto_awesome
Karen Meppen, Data Product Architect, discusses challenges of immature data and tech in data product development. She explains what data products are and the importance of executive buy-in. Karen highlights conflicts between shadow data teams and tech teams, providing insights on effective strategies in adopting a product and UX-driven methodology.
Developing data products in emerging cultures requires leadership support and strategic alignment.
Identifying and overcoming hurdles in connecting tech and shadow data teams is crucial for successful data product implementation.
Deep dives
Data Product Leadership Community Webinar
Karen Mepin, a founding member of the DPLC, will be leading a webinar on the topic of immature data and immature clients. She will explore whether a product-driven approach to data science and analytics initiatives makes sense in the context of an immature data ecosystem. The webinar aims to discuss when organizations are ready to pursue data products and how to ensure success in serving strategic goals.
Defining Data Products
Karen defines a data product as something that directly improves a business's profits or operations. However, she acknowledges the subjective nature of this definition, as different individuals and organizations may have their own understanding of what a data product entails. She emphasizes the importance of understanding the complete analytics product and how it affects the business in relation to different personas.
Identifying Readiness for Data Products
Karen highlights key factors that indicate whether an organization is ready to pursue data products. These include having support from leadership, a clear understanding of strategic goals, and the ability to participate in structured problem-solving approaches like design sprints. She emphasizes the need for alignment between the technology team and end-users, and the importance of building bridges and addressing cultural barriers to facilitate successful data product implementation.
Challenges in Data Product Implementation
Karen shares a client case study where the existence of shadow data teams resulted in disconnected efforts and challenges for the tech team. Despite optimizing report latency, the shift towards a data product approach was met with resistance from the tech team and a lack of clarity regarding the definition of data products. Karen emphasizes the need for effective communication, understanding end-user needs, and validation of solutions to ensure successful data product implementation.
This week, I'm chatting with Karen Meppen, a founding member of the Data Product Leadership Community and a Data Product Architect and Client Services Director at Hakkoda. Today, we're tackling the difficult topic of developing data products in situations where a product-oriented culture and data infrastructures may still be emerging or “at odds” with a human-centered approach. Karen brings extensive experience and a strong belief in how to effectively negotiate the early stages of data maturity. Together we look at the major hurdles that businesses encounter when trying to properly exploit data products, as well as the necessity of leadership support and strategy alignment in these initiatives. Karen's insights offer a roadmap for those seeking to adopt a product and UX-driven methodology when significant tech or cultural hurdles may exist.
Highlights/ Skip to:
I Introduce Karen Meppen and the challenges of dealing with data products in places where the data and tech aren't quite there yet (00:00)
Karen shares her thoughts on what it's like working with "immature data" (02:27)
Karen breaks down what a data product actually is (04:20)
Karen and I discuss why having executive buy-in is crucial for moving forward with data products (07:48)
The sometimes fuzzy definition of "data products." (12:09)
Karen defines “shadow data teams” and explains how they sometimes conflict with tech teams (17:35)
How Karen identifies the nature of each team to overcome common hurdles of connecting tech teams with business units (18:47)
How she navigates conversations with tech leaders who think they already understand the requirements of business users (22:48)
Using design prototypes and design reviews with different teams to make sure everyone is on the same page about UX (24:00)
Karen shares stories from earlier in her career that led her to embrace human-centered design to ensure data products actually meet user needs (28:29)
We reflect on our chat about UX, data products, and the “producty” approach to ML and analytics solutions (42:11)
Quotes from Today’s Episode
"It’s not really fair to get really excited about what we hear about or see on LinkedIn, at conferences, etc. We get excited about the shiny things, and then want to go straight to it when [our] organization [may not be ] ready to do that, for a lot of reasons." - Karen Meppen (03:00)
"If you do not have support from leadership and this is not something [they are] passionate about, you probably aren’t a great candidate for pursuing data products as a way of working." - Karen Meppen (08:30)
"Requirements are just friendly lies." - Karen, quoting Brian about how data teams need to interpret stakeholder requests (13:27)
"The greatest challenge that we have in technology is not technology, it’s the people, and understanding how we’re using the technology to meet our needs." - Karen Meppen (24:04)
"You can’t automate something that you haven’t defined. For example, if you don’t have clarity on your tagging approach for your PII, or just the nature of all the metadata that you’re capturing for your data assets and what it means or how it’s handled—to make it good, then how could you possibly automate any of this that hasn’t been defined?" - Karen Meppen (38:35)
"Nothing upsets an end-user more than lifting-and-shifting an existing report with the same problems it had in a new solution that now they’ve never used before." - Karen Meppen (40:13)
“Early maturity may look different in many ways depending upon the nature of business you’re doing, the structure of your data team, and how it interacts with folks.” (42:46)