Today, I’m talking to Andy Sutton, GM of Data and AI at Endeavour Group, Australia's largest liquor and hospitality company. In this episode, Andy—who is also a member of the Data Product Leadership Community (DPLC)—shares his journey from traditional, functional analytics to a product-led approach that drives their mission to leverage data and personalization to build the “Spotify for wines.” This shift has greatly transformed how Endeavour’s digital and data teams work together, and Andy explains how their advanced analytics work has paid off in terms of the company’s value and profitability.

You’ll learn about the often overlooked importance of relationships in a data-driven world, and how Andy sees the importance of understanding how users do their job in the wild (with and without your product(s) in hand). Earlier this year, Andy also gave the DPLC community a deeper look at how they brew data products at EDG, and that recording is available to our members in the archive.

Highlights/ Skip to

• What it was like at EDG before Andy started adopting a producty approach to data products and how things have now changed (1:52)
• The moment that caused Andy to change how his team was building analytics solutions (3:42)
• The amount of financial value that Andy's increased with his scaling team as a result of their data product work (5:19)
• How Andy and Endeavour use personalization to help build “the Spotify of wine” (9:15)
• What the team under Andy required in order to make the transition to being product-led (10:27)
• The successes seen by Endeavour through the digital and data teams’ working relationship (14:04)
• What data product management looks like for Andy’s team (18:45)
• How Andy and his team find solutions to bridging the adoption gap (20:53)
• The importance of exposure time to end users for the adoption of a data product (23:43)
• How talking to the pub staff at EDG’s bars and restaurants helps his team build better data products (27:04)
• What Andy loves about working for Endeavour Group (32:25)
• What Andy would change if he could rewind back to 2022 and do it all over (34:55)
• Final thoughts (38:25)

Quotes from Today’s Episode

• “I think the biggest thing is the value we unlock in terms of incremental dollars, right? I’ve not worked in analytics team before where we’ve been able to deliver a measurable value…. So, we’re actually—in theory—we’re becoming a profit center for the organization, not just a cost center. And so, there’s kind of one key metric. The second one, we do measure the voice of the team and how engaged our team are, and that’s on an upward trend since we moved to the new operating model, too. We also measure [a type of] “voice of partner” score [and] get something like a 4.1 out of 5 on that scale. Those are probably the three biggest ones: we’re putting value in, and we’re delivering products, I guess, our internal team wants to use, and we are building an enthused team at the same time.” - Andy Sutton (16:18)
• “You can put an [unfinished] product in front of an end customer, and they will give you quality feedback that you can then iterate on quickly. You can do that with an internal team, but you’ll lose credibility. Internal teams hold their analytics colleagues to a higher standard than the external customers. We’re trying to change how people do their roles. People feel very passionate about the roles they do, and how they do them, and what they bring to that role. We’re trying to build some of that into products. It requires probably more design consideration than I’d anticipated, and we’re still bringing in more designers to help us move closer to the start line.’” - Andy Sutton (19:25)
• “[Customer research] is becoming critical in terms of the products we’re building. You’re building a product, a set of products, or a process for an operations team. In our context, an operations team can mean a team of people who run a pub. It’s not just about convincing me, my product managers, or my data scientists that you need research; we want to take some of the resources out of running that bar for a period of time because we want to spend time with [the pub staff] watching, understanding, and researching. We’ve learned some of these things along the way… we’ve earned the trust, we’ve earned that seat at the table, and so we can have those conversations. It’s not trivial to get people to say, ‘I’ll give you a day-long workshop, or give you my team off of running a restaurant and a bar for the day so that they can spend time with you, and so you can understand our processes.’” -  Andy Sutton (24:42)
• “I think what is very particular to pubs is the importance of the interaction between the customer and the person serving the customer. [Pubs] are about the connections between the staff and the customer, and you don’t get any of that if you’re just looking at things from a pure data perspective… You don’t see the [relationships between pub staff and customer] in the [data], so how do you capture some of that in your product? It’s about understanding the context of the data, not just the data itself.” - Andy Sutton (28:15)
• “Every winery, every wine grower, every wine has got a story. These conversations [and relationships] are almost natural in our business. Our CEO started work on the shop floor in one of our stores 30 years ago. That kind of relationship stuff percolates through the organization. Having these conversations around the customer and internal stakeholders in the context of data feels a lot easier because storytelling and relationships are the way we get things done. An analytics team may get frustrated with people who can’t understand data, but it’s [the analytics team’s job] to help bridge that gap.” - Andy Sutton (32:34)

Links

• LinkedIn: https://www.linkedin.com/in/andysutton/
• Endeavour Group: https://www.endeavourgroup.com.au/
• Data Product Leadership Community: https://designingforanalytics.com/community

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have Andy Sutton on the line from Down Under from Australia. I feel like I’m introducing you at a show or something, but you run the advanced analytics at Endeavour Group, yes?

Andy: Yes.

Brian: What is that?

Andy: So, we’re a liquor hospitality company. So, I don’t think there’s really an equivalent in the US, but we run 1500 bottle shops and about 350 pubs or hotels across the whole of Australia. So, we’re the biggest hospitality company in Australia, probably in the southern hemisphere, I would think.

Brian: Oh okay, got it. So, both the buildings themselves as well as the products flowing through them and all of that?

Andy: Yeah because in certain states in Australia, you need to have both: you need to have a physical kind of bar, and you need to have—to be able to run a bottle shop or a liquor store, you need to have a physical bar as well. So, a lot of our venues are, kind of, co-located pubs, accommodation, restaurants, and then kind of takeaway bottle shops as well.

Brian: Oh, I see. Got it. So, you’re a member of the Data Product Leadership Community, and you have a very [laugh] interesting webinar coming up that I’m very excited to talk about. It’s called, “Uncorking Customer Insights: How Data Products Revealed Hidden Gems in Liquor Retail.” And it sounds like you discovered something.

So, I don’t want you to give everything away here, but tell me a little bit about—I know you’ve been on this process of, like, adopting a more product orientation and the work that your team is doing. What was the before world like? Like, could you help paint that for listeners, and then maybe tell us what the after or the current one is, however you, kind of, think about it.

Andy: Yeah, I think there’s probably two aspects to this. There’s a before for Andy, and there’s a before for Endeavour as well, and it kind of came together at the same point. So, let’s do the before Andy, first of all. So, I’m a data geek. I’ve always been a data geek. I’ve got math degrees which prove them a data geek, and I’ve got 20-odd years of being a data geek and doing data s—well, it wasn’t really data science, it was data analyst because data science didn’t really exist when I was a kid, or when I was younger. And so, I’ve come on this kind of product discovery journey.

And similarly at the same time, we did it at Endeavour. So, we were a, I guess, a traditional functional analytics team with a BI team, with a data science team, with an analytics team. And depending on which of those teams you went to get an answer to a question, you’d get very different answers. You either get a dashboard, or you get a piece of analytics, or you get a data science model. And around about three years ago, we pivoted to a product-led approach, and that’s given us huge steps forward in terms of the value we deliver is, I guess, is the main thing in terms of actually putting physical dollars—Australian dollars, obviously, not American ones—into our tills through deploying analytics, and data science, and insights.

So, we’ve kind of flipped, I guess, almost complete 90 degree flip from being functionally-led to being product-led. And that’s because all of our initiatives, whether it’s BAU kind of analytics, so ad-hoc reporting analytics through to big product builds, and we’ve kind of flipped the whole model to that approach.

Brian: Where did that come from? Like, someone doesn’t just wake up one day and says, “I’m going to just switch everything to this product.” Like, there is a—something happened. So, tell us, like, what happened? Or what was the triggering moment for you to change how your team was working? Like, what happened?

Andy: So yeah, all of it’s easy in, I guess, the post-[russellized 00:03:52] world, but yeah, there was certainly some big steps along the way. The biggest one was we set up our digital function, which we call Endeavour X, and in that, we kind of went with an almost traditional Agile squads, the Spotify model, is kind of what we deployed. And in a digital world, it had kind of, I guess, really is a bit more mature, right? And so—you’ve probably seen this yourself, Brian—like, the digital world of Agile squads, and product-led development is a lot more mature than the data world.

And in that space, we started executing or building personalization and personalization engine. And personalization is this is really cool mix, really, of big data science problem to solve, in terms of how you crunch the data in your customers and products, and then a nice, pretty digital front-end. And so, we kind of start to think about okay, well, how does that blend of analytics, and design, and product, and software engineering—so I guess four legs of the traditional stool—how do those things blend together, and how do we create cross-functional teams that deliver in the personalization space?

And personalization was really successful, and so we took that model, and then started to go, “Okay, well, if we can deploy it in personalization, which is essentially a big data problem, how can we deploy it in other parts of the Endeavour value chain?” So, can we take the same approach and deploy it in a merchandiser’s function when it comes to analytics, and our operations function in finance, and people and culture, and all the other domains in our business? And around about 20—let’s say 2022—I—my memory is shocking—but 2022, we started that with four squads solving four particular internal customer problems in merchandising operations. Again, that worked. So, we had four squads [chasing 00:05:41] promotions mission, a pricing mission, a mission, and… I forgot what the other was, another mission.

Brian: [laugh].

Andy: And from there, kind of we grew out. So, each of those missions started to deliver value. We kind of thought, “Oh, there’s something here.” We then [blent 00:05:56], brought a whole analytics team into that model and started to scale out. So, we’ve now got 12 squads focusing purely on the back-end, kind of, optimization within our business.

And each of those squads is working in the kind of the product-y way. And I think that’s really important is, like, it’s product-y rather than full product. So, how do you build incrementally? How do you build with the customer in mind? How do you build cross-functional teams to deliver on missions? They’re not all building nice, polished, shiny, customer-facing products. And I think it’s the mindset that we’ve kind of stumbled upon, rather than the specific actual way of working, if that makes sense. I can unpack that a little bit if you want to.

Brian: I think it’s normal. It’s kind of just, like, lowercase agile. Everybody has a flavor of it. No one’s actually doing it the way it was written down. Everywhere I go, it’s like, “Well, we have a modified scrum that we use.” It’s like, “Yeah, that’s nor—your modified Scrum is normal because it’s been modified. And it’s normal.”

If it’s working, then do it, you know? Like, do more of it. I’m curious though, was this mission to bring the digital together, was it kind of like, “Oh, we should also add the data team and to this,” or you’re like, “No, we need to have an integrated thing,” and you kind of drove that initiative, even though you were kind of attached to the data part? How did that go about?

Andy: Yes, so probably two steps on that as well. Like, to give some context, when I started at Endeavour, we had about four analysts in the whole business. And as we focused on personalization, we started to build out, what are the analytical needs we have to deliver personalization? So, you need analysts, and you need data scientists.

Then you go, “Oh, I need engineers.” And you know, I need software engineers, too, because I need to put this thing in the hands of users. And so, we started to scale out quite organically, in a way. And then Covid happened, so the whole world went analytics crazy, and we bought in a lot more analytical talent. And then I guess the big choice we made was to kind of pivot away from just customer-facing uses of data to the back-end, in terms of promotions, pricing, and those kinds of algorithmic challenges.

And that’s when we said, “Okay, we need to get a bit more thoughtful and mindful about what’s the role that analytics plays.” And how do you set up an analytics-heavy squad in comparison to a digital heavy squad. So, that was, I guess the choice was about two years ago to go, okay, in a traditional digital squad, you’re heavily reliant on software development, and you probably have a few designers, then you’ve got all your scrum mechanics, like a BA, and a delivery lead, and a product manager. In an analytics world, the nature of some of the complexity means you’re much more heavy in analytics, engineering, and data science, and you end up with bigger squads almost by default because of that. And that’s the piece we’re continually refining is, what’s the optimal size of a squad? How does that squad work together? How do you get data scientists, product people, and designers to work… seamlessly [laugh] together?

So, the same challenges you would have, I guess, in a digital Agile world, but they tend to be magnified because you’ve got people coming from very different paradigms. It’s a less mature way of working, especially between designers and analysts, and just the more people you put into a thing, whether it’s a room, or a squad, or a team, or whatever, the more interpersonal challenges you have to work through. So, it’s pretty much the same kind of challenges, but just on a more magnified scale, I’d say. Or more than—it’s just more difficult because of the scale of the differences between people.

Brian: And just a quick tangent, you talked about personalization, which I assume that meant something to do with digital. Is there, like, an e-commerce arm of your business where you’re selling products online, and all of that, as well as the in-store, in-restaurant, in-bar experience, or bottle shop experience?

Andy: That’s a good point, yes. So, we have an online business, two, kind of, core retail brands have both got online presence, one is the biggest online retailer in Australia, and one is the second biggest. So, that gives you some idea of the scale.

Brian: Oh okay.

Andy: And personalization is focused on one of those brands where we have a large loyalty program, and so personalization was our successful attempt, if that’s the right words, to kind of use that data to give customers the products that they want, and connecting every customer with a drink they love. We set out to build the Spotify for wine—can I say Spotify on the air—

Brian: You could say anything you want.

Andy: The Spotify for wine—[laugh].

Brian: [laugh].

Andy: Which, you know, taking the whole personalization experience that Spotify deliver and bringing that into the world of wine. So, how do you give people the right recommendations, at the right time, for the products they love? How do you do that across all of your channels and make it a seamless customer experience?

Brian: Yeah, yeah. Talk to me about the team, especially the team working under you. Did this require hiring different people? Upskilling the current people? Is this a hard transition to make? An easy transition? Like, tell me about that whole process of adopting this method of working.

Andy: So, was it easy? No. I’m very stubborn [laugh]. You may have noticed in the DPLC—

Brian: [laugh].

Andy: I’m not short an opinion or two.

Brian: You have passionate opinions.

Andy: There we go. That’s a very good way of describing it. So, it took a fair amount of blood, sweat, and tears, really, to bring our team on the journey in particular. So, I’ll come back to that in a minute, but the business actually were very supportive of the direction when we—especially because we started to talk about here’s the value we can unlock. An analytics team is delivering value to—measurable, tangible value to organizations isn’t that widespread, and so as soon as we started to talk about here’s the value we can deliver if we pivot to this model, that kind of got the business, and my boss in particular, very interested.

The harder part was bringing the team on the journey. And I’m trying to think back to when I was an analyst as well. What I really liked was the end-to-end accountability from understanding this problem, take a brief, [turn it 00:12:20] into analytics brief, cut code, answer the question, write the presentation, deliver the presentation, and then drive the change [in the background 00:12:28]. But you kind of realize when you try to do that at scale, it’s actually impossible because you need unicorns everywhere to be able to deliver on that, and you can’t really scale it. So, bringing the team on that journey was challenging, and to some degree, we’re still on that journey. It’s not—we’re not done, and I don’t think we ever will be.

Did it require a different kind of person? Well, the biggest change was, obviously, we brought in product managers of various shapes, juniors, seniors, and heads of product to help us embed that, kind of, product way of thinking, but also made those roles accountable for the value delivery from the squad. So, that was probably the biggest change was to move from a world analytical teams were run by analytics managers, to well, we’re going to build squads, and you’re going to bring in people, but we’re going to deploy them into the squads, and there’ll be led to day-to-day by the vision and the roadmap of the product manager. So, that was the biggest change, and data product management isn’t that mature worldwide; definitely isn’t that mature in Australia, and that’s the I think we’re still going on the journey of what makes a great data product manager. Now, is it somebody from a data background who learns how to do product? Is it some product background who learns how to do data? Is it somewhere in between? Or is it none of those things, and it’s actually more about mindset than it is about the skill set that coming with?

And I think we’re landing on the last one, that as long as somebody is open to growing either way, it’s the growth mindset that actually matters for those roles. So, that was the biggest change. And then also, you know, I’ve got some fairly senior roles in my team, so people that kind of had [org-level 00:14:03] running large teams of 70 to 100 people, and actually saying to them, “Well yes, you’ve got those resources. Your job is to hire them, retain them, develop them, grow them, but you don’t get to tell them what to do every day because they’re working in a squad which has got autonomy, and they’re being led by the vision of the product manager.” And that’s hard, even for me.

I’ve been doing this for 20 years, and you’re kind of used to, okay, you’ve got a question you want to answer. You’re going to ask somebody, and they—now it goes into backlog, and it might get done three weeks later if the product manager decides to prioritize it in a scrum ceremony. So, I think learning to let go is probably the biggest thing that some of the teams had to learn along the way, too.

Brian: Got it, got it. Was the resistance primarily from members on your team who wanted to run, like, the end-to-end thing, or did the other parts of the business find it hard to have data people involved there, or even running things if you’re building, like, a personalization model, and it’s feeling like, “Oh, no, that’s a digital thing. That should be run by we the digital people.” And you’re like, “No, that takes a lot of knowledge about data in order to do that, and it should be run by a data product manager.” Tell me a little bit about those dynamics?

Andy: That one we haven’t solved. This intersection of, kind of, customer and digital is still a work in progress. So, what we’ve essentially done is anything customer-facing, we’ve left in our digital part of the business. We give them or depl—give them; they pay for them—but we deploy our resources into their squads. So, we build up the capability, but that part of the business decides what the mission is, the task delivery side of things, and so we then focus on anything back-end.

So, in that case, personalization is now led by digital product managers, but we’ve blended squads, and some of those squad members are from the advanced analytics team. So, we give them data scientists, we give them analysts, we give them engineers, and then they work out the best way to utilize those resources to deliver on their mission. And that has worked quite successfully. As we get into problems which are kind of multi-domain and start to stretch across the organization, things like how you optimize your supply chain, how do you optimize your store network which have got a customer angle, and a supply chain angle, and the merchandising angle, those things are going to be interesting to revisit because we’re quite good at optimizing within a certain domain, but trying to optimize across our whole business is an interesting intellectual challenge for us, if nothing else. Like a number of businesses, we can be quite siloed in how we approach things, and so we ended up being the connection and the glue and sometimes the referee between different parts of the business, too.

Brian: [laugh]. How do you know this mindset and approach is working? How did they know it’s working [laugh], your other stakeholders or your C-team? Or like, what’s their perception? How do they know?

Andy: So, I think the biggest thing is the value we unlock in terms of incremental dollars, right? And so, I’ve not worked in analytics team before where we’ve been able to deliver a measurable value to the bottom line in a way that we deliver more value than we cost as a cost center. So, we’re actually—in theory—we’re becoming a profit center for the organization, not just a cost center. And so, there’s kind of one key metric. The second one, we do measure the voice of the team and how engaged our team are, and that’s on an upward trend since we moved to the new operating model, too.

So, the team are kind of more engaged—despite, you know, a fairly tough transition into a new operating model—engaged, and kind of, on the [bus 00:17:40], I guess, on that journey. We also measure internal, kind of, voice of partner score. And again, we get something like a 4.1 out of 5 on the scale. So, we’ve got… I was going to say enthused internal partners; I’d say satisfied internal partners in terms of how we’re operating. Those are probably the three biggest ones: we’re putting value in, and we’re delivering products, I guess, our internal team wants to use, and we are building an enthused team at the same time.

Brian: You talked about your team size started out at four. I don’t know if you’re able to share any numbers or results, but like, how large is the team now? And you mentioned, like, we’re profitable, effectively, or you’re making more money for the business than it costs to run the advanced analytics team. Can you share any of those numbers with us, or even just ranges, just so people can get an idea?

Andy: Easier to share, the team size is about 150 now. So, that’s 150 deployed on the back-end ones; there’s another 50 deployed on the digital side, so about 200 in total. And that’s a blend, right? So, it’s everything from BAs, designers, product managers, through to data scientists and engineers, so not purely analytical resource, but that’s the number of resources delivering on our [missions 00:18:10].

I think the key thing, in terms of progress is, we are supporting more parts of the business as we go with more valuable use cases. So on, kind of, two axes, on one, we’re doing more for more parts of the business, and the other one, every part of the business we’re servicing, we are finding more valuable uses of data and analytics. So, that’s probably another proof point that we’re doing something right. So, we’re kind of getting that cut through into other parts of the org that have not necessarily used analytics in anger in the past.

Brian: Mm-hm. Talk to me about the product management. And you mentioned you have designers; when are designers involved? Is making these data products easy to use, is that a challenge, or is that something that product managers typically can handle that work for, you know, your internal-facing stuff? I’m guessing you’re not serving a lot of customer-facing data products to [laugh] to the wine and liquor business and entertainment, but I don’t know, maybe you are [laugh].

Andy: No, it’s—the reason this is a really, really interesting question is—and tell me if I’m wrong with it that, I guess, that’s the paradigm that it is harder to fulfill the needs of external customers than to meet the needs of internal customers. And our business is actually… it’s kind of been in some ways the other way around. Like, you can put a product in front of an end customer, and they will give you quality feedback that you can then iterate on quickly. And sometimes you put unfinished products in front of customers because customers are used to it. You do that with an internal team, and you lose credibility, you lose cut through, you lose brownie points very quickly.

And so actually, sometimes internal teams hold their analytics colleagues to a higher standard than the external customers. And so, we are having to, in some respects, design products that are easy for internal customers to use. And some of the products we’re building, I guess, we’re trying to change, not necessarily the culture of the organization, but definitely how people do their roles. And part of the role, you know, people feel very passionate about the roles they do, and how they do them, and the specific thing that they bring to that role, and we’re trying to build some of that into products. So actually, that decision you make would be better if you did it this way.

And so, that does require probably more design consideration than I’d anticipated, to be honest, and therefore, we’re still bringing in more designers to help us on that journey. And it is moving progressively closer to the start line. So, previously has been, “Oh, we built this product. Now, we should test it.” And now we’re much more comfortable moving into the world of, okay well, before we start, or at least, when we’re started, we need to be getting a customer view at that point, and then designing with those internal stakeholders in mind.

I think where it’s a big challenge is, say you’ve got 60 people in one of your functions trying to support. How do you not build a Frankenstein that’s trying to support the needs of all of those 60 users, but also build something that’s bespoke enough to feel like it’s not just that you’re giving them out-of-the-box. So, there’s this balance point between one-size-fits-all, and I can’t build 60 different versions of this thing. And so, that’s—we’re still kind of working through that. And every use case we do when we’re learning more about what’s the role of design plays in the data world.

Adoption is by far the hardest part of building analytics products, I’ve found, like, over the last couple of years. Like, yes, it’s not always easy to get alignment upfront of what’s the problem you’re trying to solve, how much is it worth, whether you should build it, and all the internal political, kind of, conversations that go into that. Building it, okay, it’s not easy to build data science models. I’m not going to say that, especially when we’re trying to put them in a nicely packaged product, but it’s also not… rocket science.

The third part, which is, “I’ve got this amazing product that will change your world because it’ll make your job easier, and it’ll make it easier for you to service the needs of your customers and deliver more value.” “Yeah, but I quite like my Google Sheet.” And that’s, kind of, the cognitive dissonance. And so, that’s the biggest challenge. How do you bridge that gap between, “I’ve got this amazing thing that’ll make your job easier.” “But I don’t want to use it.”

And that’s, I think, where design and the product manager together play a really important role in helping bridge that adoption gap. And I guess, the more of that you could do upfront so you understand what you’re designing, what you’re building for, and who you’re building for, and what the blockers are going to be, I guess in some ways, it’s a traditional change management approach, but in some ways, it’s kind of harder than that because the complexity of the, kind of, domains we’re trying to solve, more than anything.

Brian: Mm-hm. As a designer myself, I frame that less as change management and more of, I think it’s natural for organizations that are actually evolving and progressing, and they’re not just repeating yesterday over and over again, it’s normal for the product and design staff to keep moving upstream. And eventually, what you realize is, we’re actually—what we need to be doing is customer research. We need to be exposed to the people that are going to use this stuff to understand how they do it now such that we could make an improvement that they would be willing to change something about their life or their workflow, they would be willing to use a new thing because we so understand what’s challenging about their old way of doing it, or the current way of doing it. It makes it easier to design a better solution when you really understand their problem, what the business is trying to do, and all of that, so it’s a natural evolution.

And I think that exposure time is where—that’s the gold. But the hard part is to some in the business, if you’re not writing code, or manipulating data, or putting pixels on a screen, or whatever it looks like nothing is happening. What can you show for going in listening to the salesperson complain about how it’s too hard to sell this product because the prices are all different, and every customer knows they’re different? And like, what am I supposed to tell this guy? He’s pissed because [laugh] last week, we told him it was this price, and now it’s this price.

It’s like, well, we need to understand that because if we don’t understand what it’s like to be the salesperson, how are you possibly going to give him a tool that does pricing guidance, if you don’t really know what it’s like to be the seller trying to convince his buyer to buy your wares, or whatever it is that you’re selling? I don’t know, that’s my take. But tell me about that. Like, do you feel like that exposure time is really important, like, getting your product management and design or UX people upstream? Is that, like, a critical thing for you?

Andy: So, I would say it’s undoubtedly, I would even go as far as to say, it’s becoming critical in terms of the products we’re building. I think there’s a few aspects of that, though. One is, you know, you’re building a product, for instance, or you’re building a set of products or a process for an operations team. So, in our context, an operations team can mean a team of people who run a pub, right? So, it’s not just necessarily about convincing me or my product managers, or my data scientists that you need research; it’s, we want to take some of the resources out of running that bar for a period of time because we want to spend time with them watching, understanding, and researching.

So, those are, kind of, more of the challenges, I think we kind of fa—and again, with we’re facing into that and doing that. But it’s not necessarily about even convincing us that it’s going to [disruptive 00:27:44] into the wider business. I think what we’ve got though, from the fact we’ve kind of almost, I’m going to say bootstrapped, or ground away to the success we’ve got today, it does give us more options when you can say, “Okay well, this exact activity might not be seen to deliver value today, but let’s take the context view of what we’re building as a function or the capability, which is we’ve got runs on the board, we’re starting to knock the ball around the park, we want to start smashing sixes”—that’s a cricket reference, by the way, for anybody in the US—“And if you want to start hitting sixes, you have to kind of [play 00:28:17] yourself in, and part of playing yourself in is spending time designing things upfront, and spending time with your internal stakeholders.” And you can’t accelerate if you haven’t done that, kind of, playing yourself into the wicket.

There are lots of things that we do now in terms of design, but also in terms of how we structure a squad, in terms of how we sequence things that we couldn’t have done at the start because people would have thought we were a little bit bonkers. And so, number one, we’ve learned some of these things along the way, but also, the success we’ve had to this point means you get more freedom, I guess, to be able to say, “Well actually, do this thing properly, we need to do this.” “Okay.” I kind of—we’ve earned the trust, we’ve earned that, kind of—the seat at the table, and so we can have those conversations. But it’s still not trivial to get people to say, “Oh yeah, I’ll give you a day-long workshop, or give you my team off of running a restaurant and a bar for the day so that they can spend time with you, and so you can understand our processes.” But it’s critically important.

Brian: I don’t know if you’re allowed to tell us about this, but is there a specific example of a data product you’re working on, or that’s already in production that would involve, like, the bar staff for example? Like, help give us a picture of—because someone listening might be, like, “Well, why does the barman need data?” Like, there’s a gap here. Fill it in for me. Andy, like, what’s happening there? Why would the data team need to talk to the barman at the pub?

Andy: So, there’s a use case that we’re building at the moment which is around pricing… let’s call it approach rather than optimization in our hotels. So, we’ve got 350 pubs around all of Australia. And Australia is a pretty big place, right, and so lots of variation in terms of demographics. You’ve got some of our pubs which are in our city centers, and some of them which are thousands of kilometers away, in the middle of nowhere. And so, when you’re trying to optimize or suggest, how do you price—this is going to sound like a foreign language to most of the US—but how do you price a schooner versus a middy versus a pint versus a jug of beer, for instance, right—so they’re the various different sizes you can get—what’s the relative price in between those things? And it’s a fairly complex problem to solve when you’ve got 350 different venues scattered across the whole country.

I think what is very particular to pubs is the importance of the interaction between—especially a local pub—so the importance of interaction between the person who is the customer and the person serving the customer, right? And so, what you don’t get from the data is a sense of Jim, or Bob, or Sue, who comes into the pub every day or every other day, what’s the impact of whatever you’re doing on them? And, you know, some of our bar teams are, I guess, yes, they’re there to serve a drink or serve a meal, but pubs are also very relationship-driven places, right, and they’re about connections between the staff and the customer. And you don’t get any of that, I think, in terms of understanding if you’re just looking at things from a pure data perspective. And so, that’s one of the use cases.

The other one we’re looking at is how do you use the activity that happens in a bar to—and if you can predict the amount of work that happens in a hotel—so that’s the number of meals you serve, the number of pints you serve, the number of drinks you serve, the number of customers you serve—then you can get better at matching your staffing roster to your demand in a pub as well. But again, that massively underplays if somebody comes in, and you’re spending three hours of your day having a conversation with them because that’s what they need from you as a customer and staff relationship. You don’t get any of that if you’re just looking purely at data, either. Because you see a transaction go through the till; you don’t see the conversation that happens off the back of that, so therefore, how do you capture some of that in your product as well? So, it’s about understanding the context of the data, not just the data itself, I guess, is probably the easiest way to describe it. Do those use cases makes sense?

Brian: It totally does. So, you’re—in that case, we’re talking about how do I help the manager at this restaurant—or whoever the person is that either writes the prices on the chalkboard or prints the next menu for the next month, to know what the pricing should be. And as the saying goes, the map is not the territory, right? And I love how you frame this about, if you just look at this as a mathematical problem, you can probably optimize the pricing in the short term, but it would not account for the damage that you would do to say, a small community where the public house—the pub—the public house is, like, a center of the community. And there’s relationships there, and probably families go there or whatever. It’s the center of that community, it’s not just a place to get beer.

And so, what is the cost of, like, sucking every last dollar out of every customer that you can get? Well, long-term, that’s not good for Endeavour Group or anybody, but that’s—the data will never tell you that. And so, you know, for listeners on this show, when I talk about human-centered design and downstream stakeholders, it is June and John that come in on Sunday afternoon at four o’clock, they’re a downstream stakeholder, as they’re the ones that pay for this, they’re the customer that pays for this thing. The internal customer is the barman who’s setting the prices, and there’s a relationship there. And if we never have any exposure to any of that, then it’s just a math problem, but you’re not going to create long-term value there because you’re not factoring in, like, well, how important is pricing in this community?

Well, maybe this is a community that doesn’t have as much money, so we, kind of, stay on the lower side because longer-term, we’re going to have customers for a longer period. And the math won’t tell you—the database will never tell you about the color of the community in that sense. And I think overall, this is still—it’s still actually net better for the business, right, because you’re factoring in these long-term perspectives, not just the short term, did we build a pricing algorithm and did it maximum—oh, look what it did in September. It’s, you know, it’s up 25%? It’s like, yeah, but what did you do for the next year to the relationships of those people long-term? You don’t know. You got to wait now, and by the time you’ve done the damage, it’s like, well, just lowering the prices isn’t necessarily going to bring them back if they just, you know, if you’ve burned those bridges. So, tell me if I’m wrong. That’s how I kind of see that.

Andy: No, that’s a completely accurate, I think, portrayal. And I don’t know, you don’t have to look too far to see examples in different industries where that’s gone askew, for want of a better word. I think the thing I really love about working for Endeavour is that it is a business that is—it’s a story and relationship business. So, every winery has got a story, every wine grower has got a story, every wine has got a story. And therefore, these kind of conversations are almost natural in our business.

So like, I’m a data guy, right? Like so, storytelling, connections, relationships isn’t really my forte, but in the business we work in, it becomes much easier because that is the business, right? Like, our CEO started work on the shop floor in one of our stores 30 years ago, right, and that kind of relationship stuff percolates through the organization. So, having these conversations around customer and internal stakeholders in the context of data feels a lot easier in some ways in our business because storytelling and relationships is the way we get things done, where our business is all about sociability as well. And therefore, that comes through.

And I think that is probably the missing part from the piece earlier on about why you go on this journey. Well, in our business, we kind of go on the journey because it almost feels natural to go on this journey, right? Because bringing together the storytelling side of our business—the relationship side of our business—and data, those two things together, is what really matters. That might sound a little bit airy-fairy, but like, it’s much easier to do this product-y thing in a world where people want to talk to each other, or they don’t want to have this separate data team that’s just doing ivory-tower type stuff that you can have in some orgs. It wants to, and we want to, connect with the broader organization in that kind of rich tapestry of different people across the business.

And yeah, as an analytics team, get frustrated with people who can’t understand data, can’t understand analytics, but it’s I guess it’s our job to help bridge that gap, right, bridge that divide. Yeah, so I think the context of the org makes some of this stuff simpler, but also potentially more important.

Brian: I mean, it’s messy, right? If you’re building stuff that involves people, it’s messy by definition, and the data might suggest that various things are orderly, and structured, and categorized, and neat, even though [laugh] the data itself can be a mess sometimes. But that’s not the actual world when it comes to putting these products and services in front of someone that actually has to use them and make a decision on it. You know, it’s a whole different story.

Is there anything you would change—like, this has been great conversation, Andy, I really appreciate you being so candid here—is there anything you would change? If you rewound back to 2022, and had a chance to, kind of, replay this transformation? I know you said, like, we had to earn some trust, we had to have some wins before we could do some crazy stuff, like talking to [laugh] customers, and some of that, but like, is there anything you would change if you went into, like, a new organization and kind of was like similar to this one where it was a few years ago, what would you—how would your playbook look different?

Andy: So, because of the nature of the egos involved, in way—mine—I’m somebody who’s we went for, like, what are the really hard things we’d go after? And we went for, what are the top five hardest things we can do, and we’re going to go after those things. And there were loads of reasons why in terms of the context of the organization, but that meant that getting the runs on the board initially was tough because we were going, they're the hardest things algorithmically, and they’re also the hardest things from the people change perspective. Oh, why don’t we do those things? And having a more blended approach might have been better for my… overall well-being.

Brian: [laugh].

Andy: But I guess what that’s also meant is, every time we’ve hit a bump in the road, it hasn’t necessarily always mattered because the value is still been there. So, the good thing about tackling hard things is that there’s lots of value in them, and so even when you’re not quite where you wanted to be, you’re still delivering value. Whereas if you’re doing the easy things that have only got marginal value anyway, you could go off track, it’s much harder to say, “Okay, I’m still delivering measurable value.” But having a more blended portfolio would probably be the first thing I would do differently. And I think the—this is probably something I’m saying because I’m being interviewed by a designer, but I think—

Brian: [laugh].

Andy: —we would probably have been better off getting more pointed around design as a capability in data sooner. But it’s also slightly the right time because the conversation we’re having around data product leadership, like, and what’s design's role in that wasn’t being talked about in my world two years ago. So, I’m slightly trying to accelerate time, and get that talked about two years earlier, but if we’d have been going into some of these things with more of a view of what does our customer want and need—our internal customer want and need—we would probably have got to where we are quicker.

Brian: Yeah.

Andy: We talked about our strategy for next year, and we adjusted to aid our strategy, but we’ve left a lot of it the same because we say we’re doing a lot more right than we’re doing wrong. And so, there are things where yes, we could tweak or do things a slightly different way, but I wouldn’t change a lot of it because it’s been really, really successful. But yeah, I think not by getting a more blended portfolio would probably be the biggest thing that most of my team would say, not just me.

Brian: Yeah. Andy, this has been great. Tell us quickly, what are people that are going to go to the webinar going to learn more about—so it’s called, again, “Uncorking Customer Insights: How Data Products Revealed Hidden Gems in Liquor Retail”—are you going to go behind the scenes, like, some case study here on some of these data products, or what’s that going to look like?

Andy: So, I’ll definitely do some more of this [scene-set 00:40:05] stuff, just in terms of some of the things we found along the way, and some of the—where we fell on our face because this is all a great post-rationalized conversation, right, but there were definitely areas where it was, like, ups and downs along the way. But yeah, I’ll talk a bit more about some of the products we’re building, and some of the problems we’re solving, some of the, kind of, specific adoption challenges we faced along the way, too. Because yeah, it’s easy on an hour-long podcast to tell the whole rosy story, but there’s definitely some bumps in the road and some cracks that we’ve kind of experienced, too. So yeah, I’ll show a bit more the secrets, and what’s behind the curtain, I guess.

Brian: Excellent. I can’t wait to check that out. I wanted to give you the last word. Any closing thoughts or advice for people, other leaders that are, kind of, in your shoes, maybe on this journey right now?

Andy: I think the key thing for me is, like, just keep putting one foot in front of the other and keeping going. It’s very easy to go off the path or be told that the product approach or the design approach or whatever else is not the right way of doing things. There’s a fair few naysayers, right? And so, for us, it’s just been keep putting one foot in front the other, keep grinding out the results, keep doing that incrementally, keep learning along the way, kind of all the—in some respects, all the things the Agile Manifesto says you should do, right, which is, deliver incrementally, value is more important than the process, and actually, keeping going I think is the thing that is probably the biggest thing nobody tells you is you need to be fairly resilient. Just keep going. So, that’s been the biggest thing for us is keep going.

And I think the other one is, find your tribe. So, I think the really positive thing that I found about the Data Product Leadership Community, but also other people all across Australia who do this kind of thing is, just finding people who think in a similar way. It’s not exactly the same because it’s boring if you don’t get to check and challenge each other, but find the people who are also trying to do this weird and wacky thing, build relationships, network, share stories, and learn from each other, too. So, those are probably my two parting words of wisdom, for what they’re worth. So.

Brian: [laugh]. Excellent. Well, yeah, but I enjoyed your contributions in the community, and thanks for sharing all this today. Where can someone who’s not in the community, how can they get in touch with you? Is LinkedIn, or where do you hang out, anywhere publicly online?

Andy: Yeah, so LinkedIn is probably the easiest place to get hold of me. So, there aren’t too many Andy Suttons on LinkedIn, but Andy Sutton, Endeavour Group, is by far the easiest way to get a hold of me. Yeah, and I look forward to continuing the conversation with anybody who wants to.

Brian: Excellent. Well, thank you for being so candid and transparent here about your journey. It’s been great to chat.

Andy: Thanks, Brian.