Building a data-driven culture and the role of data analysts

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.

Amy's LinkedIn: https://www.linkedin.com/in/amy-tang-edwards/

In this episode, Scott interviewed Amy Edwards, Formerly Director of Analytics and Product at Vista. To be clear, she was only representing her own views on the episode.

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

1. A potential Northstar metric for how data driven you are: how often are people getting, interpreting, and actioning on the data themselves versus waiting for an analyst to tell them? Hard to measure but it's where you want to head, where more and more people are making the effort to interact with data.
2. If you want a data product/use case to succeed, the absolute most important thing is an engaged consumer stakeholder - someone who really, really wants the data for a use case and how they want it. If someone isn't leaning in, consider not building something for them. Scott note: this sounds controversial but it is reinforced in almost every data mesh conversation I have.
3. Similarly, if you are building a data product, you should make sure you are very aligned with your stakeholder. Don't be a request dumping ground, build iteratively together.
4. To understand your progress towards being data driven, you need to actually measure things to track changes over time, your progress. You almost certainly will not find the perfect aspects to measure at first and what you measure will evolve. But it starts with measuring something.
5. There's nothing wrong with starting with a using a success metric that you know isn't going to be something you focus on when a data product matures. As products go through phases, so too should your measurement. So start with number of users as a key early data product success metric - it's easy and somewhat correlated to value driven.
6. ?Controversial?: The adoption curve to not just data mesh but each incremental data product is steeper than you expect. Try to get more people using each data product more so incremental use cases emerge. That will mean you need to do more hand-holding than you likely expect.
7. ?Controversial?: Because that adoption curve is hard, especially across data products, your data team or data product owners might need to do more connective tissue work with other data products to enable people to more easily consume across domains. Always look to drive more and deeper engagement to create a more data-driven culture.
8. ?Controversial?: When thinking about interconnectivity between data products, do you have the consumers create their own bridges or do you pull some of the data from one product into another? Will that create duplicated data and is that the worst thing? What is needed today for where you are in your journey to a truly data driven culture?
9. Sometimes you will probably build something that is pretty customized to a use case and you can't adjust your data product easily to fit a new use case, especially a use case combining data across multiple products. See if you can push some of your data into another data product to again make things easy for consumers.
10. !Controversial!: It can make sense to focus more on driving adoption than creating every data product to be highly reusable. If there isn't demand for data and/or if consumers aren't actually leveraging data, a highly reusable product will still not see much usage. People using the data is your data-driven Northstar metric.
11. Similarly, it's okay to take on data tech debt around your data products if it's a conscious decision. You understand what the work will be to make it - the data product or how it fits in your broader mesh - more scalable in the future and you made trade-offs now.
12. !Controversial!: duplication of work is better than not having the data available to consumers. It's okay to have the same data in multiple places for now as we crawl or walk. When we're running (or even flying!) we won't have the duplication. Scott note: how does this factor in to MDM?
13. Providing a lot of data analysis capabilities and flexibility to people who aren't confident in their data abilities can overwhelm them. Potentially look to offer them more static views/dashboards early as they get comfortable learning to consume analytics-driven insights.
14. You should want your data analysts to move beyond the work of pulling reports and answering basic questions but you might have to leverage them as change agents to teach others to do that. Would be great to not have to use them that way but you probably will need to have some group of people on the ground helping people up their data fluency. A YouTube training course will not be enough :)
15. When you think of managing data as a product, that means data is part of the product too. So managing the data should be part of the general product management/software development responsibilities of the domain. But that's an advanced state - you almost certainly won't start there early in your mesh journey.
16. When your data product team is too separated from the rest of the domain or the general product aspects of your company, there is a risk of that team becoming siloed and not really understanding the domain to the level they should.
17. When you start to build out your foundational data products, your data products might look more like data than products but you want to move more and more towards that product mindset and output if you can.
18. ?Controversial?: When building out a data product team, the first hire should be someone with data engineering capabilities. Scott note: right now, strong agree. If we can get tooling/platforms to a better place, maybe that changes.
19. Because of the lack of a really strong UX, data products can't really drive demand in-and-of-themselves. Therefore, to see good usage that drives strong value, you need that really engaged stakeholder. It's incredibly difficult - impossible? - to create a data product so amazing, people flock to it simply because they have to use it like some consumer products.
20. ?Controversial?: Crawl -> Walk -> Run. Build a solid foundation for your mesh in the long run. Scott note: this would be compared to only building to specific use cases. Should you build out a strong foundation of data products to support many use cases or only those use cases you are targeting?

Amy started the conversation around measurement in data. To become data driven, you have to actually measure things. It doesn't have to be the perfect measure but you need to track and understand your progress. In fact, it almost certainly won't be a perfect measurement and your measurements will evolve over time too as you want to focus on different aspects of a data product or mesh journey. In her own journey to get back in shape, she focused early on exercise quantity over quality because it was about forming the habit. After she saw success there, she started to focus more on performance and speed of her runs.

It's also important in Amy's mind to understand what are you actually trying to achieve in a certain phase of any implementation. For data products, there is the development phase, once it goes into production, maturity stage 1, etc. What looks like success or is important will change and evolve in each phase and as you progress in your mesh journey. That evolution is not driven only by that your measurement framework gets better, it's that what you want to even focus on changes. So, starting with number of users of a dashboard was a good initial metric = it was early phase, relatively easy to track, etc. So as a data product matures, what you track should change.

For Amy, even in a more data literate environment, it can be a pretty hard adoption/learning curve for consumers with each individual data product. So, you want to try to get more users early in a data product's life to encourage developing new use cases. But people don't just generally start using a new data product so someone needs to do more handholding and work than just creating the data product. Part of that might be the data team or data product owners doing more of the interconnection work between data products so users can understand and be confident - otherwise, they will probably stick to what they already know. Focus on increasing and deepening engagement, that's what drives your culture towards being data driven.

Amy talked about how there is a bit of a push-pull when thinking about those better interconnections between data products. A product owner or manager should be thinking about how can their data product better connect to the greater data landscape inside the company. And then should that be pushing data from their data product into someone else's or pulling in data from another data product to make their data product more valuable. Find those paths of least resistance for consumers to get useful information to drive increased adoption.

For Amy, there is an interesting challenge when it comes to balancing high reusability versus customization for data products. If you do not create the demand for data with the consumers, then even the most reusable data product won't see a lot of use. So they focused more on customizing data products to use cases than is probably general practice in data mesh. But that meant the users had an easier time adopting and leveraging the data products. You can't create too many highly customized solutions in the long run, you just can't support that many data products. But data products that are perfect in theory with very low consumption is probably far worse than a situation where you will need to refactor in the future but you have people eagerly consuming data. It was still manageable to use this approach quite far into their mesh journey.

At Vista, there was some duplication of work in Amy's view, where multiple data products might have some of the same data. But, she viewed that as a conscious choice and that it's better to have the data more easy to consume than to really put the hammer down on not have duplication of data. Again, they really focused on driving usage with an eye on improving things later. Scott note: this is an interesting note and balance to strike. I honestly don't know how I feel. If you're aware and it's communicated and people understand, as long as it's not causing issues, I guess it's okay?

One key metric for Amy along the early drive to becoming data-driven was how often people were self-serving their analytics. Essentially, how often were they going and looking at dashboards or outputs of some kind to make their decisions rather than leveraging a data analyst to answer questions for them or worse, waiting for a data analyst to come tell them the insights. It can be hard to measure specifically but you can get a decent idea of momentum around that kind of metric.

A really interesting insight Amy had was that when they first started trying to work with the broader organization, many of the people were not yet confident with their analytical capabilities and providing them a ton of flexibility around their analytics dashboards overwhelmed them. So, instead, they started by providing more static views to let people learn how to consume data and analytical information before giving them more advanced self-service tooling. And to get the general business users more comfortable, they paired those business folks up with data analysts to walk them through what data existed and how they could query it and leverage it. It let the business users get comfortable in the shallow end, not throwing them in the deep end.

Amy talked about how the role of the data analyst might not be the most glorious when you are in a transition phase. They were using data analysts as change agents, helping to train the business people to get better and better with data. It would be great if the data analysts didn't have to do that but there is that necessary transition period where people are improving their data fluency. After getting the general populace to a better data fluency, the analysts could focus more on higher-value, more in-depth analysis.

When asked about how a data product team should look and function as part of the greater organization, Amy talked about how an end-state, highly data-driven organization might look versus how you will probably start out. If we want to manage data as a product, we have to think of data management and generation at the domain level as just part of the product function/software development. That may still be a separate data product team within the domain but it's not a completely separate unit/function. But when you are starting your data mesh journey, you almost certainly will not be at that capability level from a platform standpoint or general developers being that data literate - there will probably be a need for a separate data product team that is led more from the data side than the product side. But with that setup, beware of silos even within the same domain, try to make sure the data product teams are integrated into the work of the domain.

Amy talked about the number one most important aspect to a successful data product or use case: an engaged consumer stakeholder that is strongly aligned. It's very hard to manufacture demand by creating the most attractive data product in the world. You want a stakeholder who is helping drive the development decisions and is chomping at the bit to get the data. Don't let the data product teams develop in isolation either. Make sure they are iterating with the stakeholder.

When building out your data mesh, Amy recommends focusing a lot on the foundation first. You will be building out some unsexy data products, really the core of what you'll build on later, as the early part of your journey. But that means you can focus more and more on building to value later. Of course you need the buy-in, funding, and momentum to go this route. Crawl, then walk, then run.

Quick tidbit:

When building out a data product team, Amy recommends your first hire being a data engineer. They are the ones who "build the rough plumbing", the pipes in the walls and without that, the water doesn't move anywhere throughout the house, in or out.

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