#89 Integrating analytics into product teams (with Barry Pace @ Penfold)

Written by | October 6, 2023
The Measure Pod
The Measure Pod
#89 Integrating analytics into product teams (with Barry Pace @ Penfold)
/

In this week’s episode, Dara, Bhav, and Barry dive into the world of product management and analytics. They discuss the importance of integrating analytics into the product development process and how it can enhance decision-making. Barry shares his experiences working as a product manager and collaborating with analysts, emphasising the need for effective communication and a cross-functional approach. They also explore the challenges and opportunities of working in different industries, highlighting the core principles of good product thinking that can be applied across any context. Whether you’re a product manager, analyst, or simply interested in the intersection of data and product development, this episode offers valuable insights and perspectives. Tune in to gain a deeper understanding of the role of analytics in the product space.

Show note links:

Follow Measurelab on LinkedIn and on Twitter/X, and join the CRAP Talks Slack community.

Find out when the next CRAP Talks event is happening on LinkedIn.

Music composed by Confidential – check out their lo-fi beats on Spotify.

Master Google Analytics 4 with Daniel Perry-Reed on the next GA4 Immersion 6-week cohort training course. Early bird, charity and group discounts availible!

Quotes of the Episode:

  1. “I clumsily use the term of like of product managers are like grout sometimes, just like filling gaps between things when there’s nothing better to fill it with.” – Barry
  2. “Learning the business model, revenue model, underlying tech architecture and how people and data flow through the system gives you such a great foundation for any business you come into, it’s the three number one onboarding things probably people should do when they join” – Barry
  3. “My preferred way of working is a hub and spoke model where you have a central team, but the analysts within that team are dedicated to the different products, squads or teams. And they can always come back together and sort of like share ideas and learn off one another and really grow and elevate the analytics function.” – Bhav

Let us know what you think and fill out the Feedback Form, or email podcast@measurelab.co.uk to drop Dan, Dara and Bhav a message directly.

Transcript

The full transcript is below, or you can view it in a Google Doc.

Intro | Topic | Rapid fire

Intro

[00:00:15] Daniel: So we’re back, The Measure Pod is back, Dara, Bhav, we’re back talking to Barry this time, straight off the bat what did you think? I thought it was a great conversation.

[00:00:22] Bhav: Yeah, I loved it. You know, I’ve known Barry now for a few years. I’ve really enjoyed working with him. He’s a great product manager, he really knows his stuff. And he’s, he’s one of those people that creates great product environments.

[00:00:33] Dara: I’m just really enjoying these product conversations. It’s an area I don’t know much about and actually, the more we talk about this, the more I realise the reason I don’t know, which is a classic situation. So I’m loving just hearing Bhav and our other guests who work in the product space, just talk about it because it’s really insightful. I feel like we get stuck in our marketing analytics bubble a little bit too often, it’s always good to lift your head above the water and find out what people are doing and kind of similar, you know, maybe relatable, but different industries, different disciplines.

[00:01:04] Bhav: I love talking to Barry. Barry, he’s an ex-colleague and is a friend of mine, he’s a client of mine. So, you know, I’ve got all three boxes checked with Barry and he’s genuinely one of the most knowledgeable product managers I’ve ever worked with. I’ve learned a lot from him. I hope he’s learned a lot from me as well. And I’ve, I really enjoyed this conversation, I hope everyone listening will enjoy what we talk about. A lot of our listeners might come from a more marketing background, marketing analytics background. So hopefully this will give them a lens into the product world from the, you know, from point of a product person. I know we’ve talked about product analytics from sort of an analytics point of view, but hopefully this will give them a lens from the other side of the fence.

[00:01:39] Daniel: I was actually thinking about this and, and the same as what you were saying just now, Dara, about like how the kind of coming from a marketing analytics, cutting our teeth in marketing analytics, or at least my career for the last 10 plus years in marketing analytics. And then going and talking to product analytics people and product people about this, I realised how similar they are and actually there’s often the same problems, the same approaches and I’m even having a lot of conversations with people in the sort of the video gaming analytics space as well at the moment, it’s a bit of a passion project of mine and I’m going into that as well to go in and learn as much as I can around that and realising it again, it’s exactly the same thing with often similar tools, if not the same tools and the same approach, they’ve got different names for things, but everyone’s talking about the same stuff.

[00:02:16] Daniel: I almost want to just bring the three worlds together because we’re all doing the same things in the same way. But I’m finding that actually through these conversations that Bhav you’ve arranged for us. It’s yeah, it’s fascinating to get a different perspective of the same problems and the same successes, I find that fascinating. But anyway, like exactly as you said, Bhav, I think talking to Barry today, like an amazing perspective from a product owner perspective or a product manager’s perspective, and especially around integrating analytics people and analytics roles within the organisation, within the product space.

[00:02:43] Daniel: So for sure, I like this perspective on things that Barry brings. And for everyone listening, you’re just going to have to listen, listen to the conversation. It doesn’t matter which side of the fence you are, marketing, product, whether you’re an analyst or not. I think this is going to be going to be good for everyone to listen to and listen to Barry about his experience and expertise. Enjoy the episode.

[00:02:59] Bhav: Hey Barry, welcome to the show. Before we begin, why don’t you tell us a bit about yourself and give our audience a chance to learn a bit about you and your background and what you do.

Topic

[00:03:08] Barry: Thanks Bhav, great to be here. Yeah so my name’s Barry, I’m head of product at Penfold, which is a modern digital pensions company. I’ve worked in product management in various kind of small startups for the last 10 years or so. Prior to that, I worked in sort of creative digital agencies, or I made the shift into product management about 10 years ago to I think really kind of, I think either sort of a gap that I was missing in my career. I wasn’t really getting the most out of working at agencies. And I think part of that was the structure at the time I was a project manager. And so I was doing lots of kind of organising and things, and it was quite unfulfilling intellectually. I sort of found out that there’s this thing called corporate management that existed. And I sort of felt like it was kind of a missing piece of the puzzle for me really. I got to kind of lean on some of the stuff I’ve learned in project management and agencies, but was a little bit more kind of strategic and just a lot more interesting aspects to it.

[00:03:55] Barry: So I started to kind of tune my career in that direction through different contract work and ended up landing my first product job actually at a small startup building games for kids and educational games for kids. And yes, the rest is history. And I’m sure we’ll get into some of our past experiences together Bhav along the way as well.

[00:04:10] Bhav: Yeah, of course. Barry and I, we’ve worked together a couple of times now. We worked together at Gousto, which is a meal box subscription service. And then more recently, Barry and I’ve worked together into like a consulting client relationship. So just moving straight into the conversation something you said, actually, which I’m going to just pick up right away. Like you mentioned there was an intellectual gap from project management to product management. I’d love to hear maybe like what that was and how you were able to bridge it with moving into product management and what’s so different about product management.

[00:04:36] Barry: Well, at the time when I was working in agencies, project management was quite a well defined role. And I think this is the case in a lot of agencies at the time, you had these functional groups. You had project managers, you had strategy people, you had software developers, and then you had creatives. One of my slightly controversial opinions is that creatives should always be like an adjective, or a verb rather than a noun. Always annoys me a little bit when I hear people describe themselves or things as creative, as creatives rather. And so because of that, I always found myself doing very specific things. You know, I was doing project plans, I was gathering requirements, the dreaded phrase that I say very rarely these days, I was moving things between people and I wasn’t really using my brain very much.

[00:05:16] Barry: And I was a bit frustrated by that. You know, I saw people having all these cool, interesting conversations, thinking about what might be possible given a particular situation, a particular problem to solve. And I thought I can contribute to those conversations, but I wasn’t really given the kind of the time or space. And you know, my opinion wasn’t really that highly regarded, to be honest. And so I found that just intuitively quite annoying. And at the time I thought that meant getting into strategy in agencies because they seem to be the people who are doing the thing that I wanted to do, I aspired to do that.

[00:05:43] Barry: So I applied for a strategy role, didn’t get it, tried to get into strategy in other ways, wasn’t happening. Because I’d been, you know, tarred with this project management brush and people sort of thought they knew me from my, from my job titles. I was very fortunate to go freelance, and then I had read a bit about product management and it felt like the bit that was missing and that bit being thinking creatively, think about what world might be possible given a particular set of circumstances. And I eventually ended up, I was picking a number of contracts, which were more innovative. So for one agency, I was working on a, like a Bluetooth toothbrush and an associated app that went with it. This was like 10 years ago, more than 10 years ago, actually. And more like big platform builds. So building big websites from scratch that didn’t exist before. 

[00:06:27] Barry: And I felt like those things were taking me in the direction of what I’d read about product management. And those experiences then culminated in me kind of being able to land a product management role and yeah. And then, and you know, it’s definitely kind of, my assessment was right I think. The product management felt like a really good fit for me, given the things that I was missing intellectually beforehand.

[00:06:43] Bhav: You and I’ve worked together for a while now, and I definitely hold you in the highest regard of what I think gold standard for product management looks like. So not to just blow sunshine up your butt, I genuinely do hold you very highly when it comes to product management. And I think I’ve learned a lot from you as well. So obviously this is an analytics podcast. I’d love to hear, and I think the audience would love to hear, and I’m sure Dara and Dan would love to hear, when was your first introduction into the world of analytics and what did that look like for you?

[00:07:07] Barry: Yeah, well firstly, it’s very kind of you to say that so publicly thank you very much. My introduction to the world of analytics. I almost can’t pick the exact moment, to be honest. I think there’s probably two points then. The first one is my first job as a product person. We were building this game and, you know, it was a sandbox type game. So I think a lot of the products that most people would be building are relatively linear. They have some sense of like non-linear moments where, a user or a customer can make a number of different decisions. And those decisions, you know, there might be like 12 decisions they make at one time. They make one of those decisions and then there’s another 12 and suddenly you’ve got like loads of different paths that they can take. And I think even in relatively linear experiences, those can be quite complicated to wrap your head around. In games, it’s that like times a hundred, because there are different, all these different decisions that people can make when moving their character around a screen, you know, it was kind of like a pseudo RPG.

[00:08:01] Barry: There was so many different things, so many different times between different steps, the repetition of different things, and you know, what are they getting out of that? So I think there was this kind of very simple thing that I realised at that time, which was essentially trying to turn things into funnels best you can. And I’d never really, I’d never heard of a funnel before. And my mentor at the time had kind of introduced me to Flurry, which was a product analytics tool we were using I don’t know if it still exists, actually. I started to help, you know, specify some of the event tracking, some of the sort of instrumentation for the game.

[00:08:29] Barry: And I’ve actually subsequently thought about this, you know, did they do analytics in games in the same way we do in products? I never spoke to anyone in games about it a significant fashion, so I’d be interested to hear about that. And that was my first moment when I sort of realised, oh, this is a very fundamental part of having kind of some feedback loop from your product to know what you’re doing. That was my first product job. The second one was probably at Gousto I would say, you know, Gousto is a very kind of data oriented company and the way that data was, you know, woven into decision making there was, you know, not like I’d seen at any other previous company and definitely to it’s credit.

[00:09:03] Barry: And I think part of that, it kind of, to make it more specifically about analytics, I think seeing the way in which you could kind of weave analysts into the product development life cycle as a role, a particular person who was an analyst, that was actually the first time I’d worked with dedicated analysts before that I’d been kind of doing, or be doing things scrappily with engineers to answer questions that we had. So working with analysts for the first time in a really data oriented company like Gousto was probably the other like, aha moment of realising like, wow, that’s so much more powerful having someone so dedicated to go into real difficult, complex stuff, which I would have no hope of, you know, particularly when answering particular questions that I would have no hope of answering myself.

[00:09:40] Dara: So why do you think that was so rare? Maybe I’m being a bit naive here, but I would imagine and knowing very little about actually working in product management roles, I would have maybe thought that data would be woven into that decision making process but it sounds like that was kind of unusual to experience that at Gousto.

[00:09:58] Barry: I think prior to Gousto, I’d only worked at really very small startups. And I think it’s fair to say that none of those startups were big enough to have dedicated analysts. So certainly I think data was involved. And, you know, as I used the example from my, from the first company I worked at, which was still very small and probably still too small to have a dedicated analyst, at least in my mind. The data was present and people were using it and we were using it to inform our decisions, but we were limited by our skills. We could answer simple questions with the simple instrumentation that we had in the product, but we couldn’t go into the more complex stuff where I think you need specialists or people who know, really know what they’re doing or how to manipulate data in a way that, you know, we weren’t able to at the time. And I think Gousto is the first, really the first company I worked at, even though I’ve been doing, been a product for six or seven years, by the time I went to Gousto, it was the first company that was big enough to have dedicated analysts. So although the data was present forehand, that was the first time where there was dedicated people doing it.

[00:10:49] Bhav: I mean we’ve discussed this before and I think analytics within this product management space itself has up until, you know, very recently been a very nascent thing. And I don’t think many product teams have adopted this. It’s not necessarily true towards the size of the organisation, I think this product analytics as a concept has only been around for a few years. And you know, and I think that’s maybe one of the reasons why, because I think technology, event tracking technology has evolved so much and has become so much better to allow for doing complex behavioural analysis, funnels, segmentation, things like that. So that’s probably, you know, one of the reasons why it’s you know, Barry, in your case, it sort of like arrived in your career, like six or seven years after, you know, when you first started product.

[00:11:32] Daniel: It’d be interesting to get your perspective and opinion on this Barry, but around you mentioned that having that dedicated analyst was only really when you were working at Gousto within the product space and the kind of the fact that they kind of bring this ability to go beyond, I suppose, the average person in terms of the analysis, the tools, the access and the raw data. But I suppose my question is really around like, when does that happen within an organisation? Because I suppose you could warrant or argue a need for, or an awesome value to be gone out of some complex stuff from a small startup as well. But what’s that kind of tipping point where it becomes useful to have a dedicated analyst, even though they could be doing some good work in any business of any size?

[00:12:09] Barry: It’s a really good question, and I mean, there’s two parts to this. First one I have this kind of mental model of how far particular disciplines are from delivering measurable value. And there are some systems that are very close to delivering that value and that’s engineers. So software engineers and to some extent design, and I’m talking about building products here. And then at the other end of the scale are things like user research and analytics.

[00:12:36] Barry: And if you ask any fair minded person who works in this sort of stuff, they’ll say that yes, user research is very important, analysts are very important. When it actually comes down to the decision making of where are we going to spend the money that we’ve got, it becomes much more of a risk for decision makers with budget to put the money into user research, analysts, than it does into we’re going to build another team who are going to build some stuff. And it’s a very alluring, a very easy decision to make and a very low-risk decision to make for those people. But I think the optimum decision to make is, and I’ve not actually had the experience of doing this, I hope to at Penfold, but to, if you have one good team that’s working well, and it’s engineers, product manager and designer to supercharge that one team and make them better by adding user research, adding dedicated analysts and making them extremely good and then building another team like that.

[00:13:21] Barry: So building out the functions rather than maximising output. And on the other hand, I think there comes a point in the maturity of the data I think where, you know, if you’re very early on, you’re very scrappy, it might not make sense to throw in an analyst who’s got a lot of really great skills and give them some data, which is not that interesting or complex, or that they’ve got enough users to generate enough data. There’s this kind of organisational side to it and then just comes down to, is there enough data to ask interesting questions of yet? And a lot of the companies that I’ve worked at where I talked about not having dedicated analysts are kind of pre-product market fit hovering around product market fit companies that haven’t, that haven’t had like explosive growth so we haven’t got loads and loads of data to go and look at.

[00:14:05] Daniel: Is there again, I don’t want to be putting words in your mouth now, but like the way I’m listening to that, it’s kind of like, there’s like a maturity level whereby it’s not necessarily about the volume of data it’s about like the way that I talk about it when I work, me and Dara work predominantly with marketing teams, but it’s, I suppose the analogy is exactly the same. When do you introduce a marketing analyst into the mix rather than having a dedicated person versus an agency versus freelancer versus whatever, but for me, it’s always been around let’s say you’ve got someone working full time and they’re churning out one piece of analysis every single week. Do you have the rest of the organisation at the same pace ready to absorb that much work at that pace, or is it going to go on deaf ears because the rest of the team are so busy and so multifaceted and being pulled left, right, centre, that actually they can’t make the use of the analysis. Because an analyst isn’t a, like a lever puller, they’re not pushing the buttons there, they’re advising which buttons to push and when. And so if you don’t have the people ready to enact the analysis or the insights being generated, actually it’s more of a, do you have a company ready to kind of accept that input, I suppose. Am I making any sense there?

[00:15:05] Barry: Yeah, I think so. There definitely has to be some kind of, the plan can’t just be, oh, we can probably hire analysts now, or let’s spend some money and hire analysts. There definitely has to be a, they have to arrive into a set of conditions that are conducive to them delivering a whole bunch of value. Maybe the marketing side is a little bit out of my wheelhouse, but yeah, I would imagine the same thing goes in marketing, but if you haven’t got the conditions right to drop in someone who’s going to be giving loads of great insights, information. If there’s a team or set of people who aren’t ready to interact with that or know what to do with it, or able to take action off that insight, then you don’t get the value out of investing in an analyst in the first place.

[00:15:39] Bhav: I think the big difference here is with marketing analytics you almost get analysis as soon as you start spending money, data starts flowing in based on the marketing platforms that you’re using. It requires minimal GA set up or Facebook Ad set up, or, you know, whatever it is for an analyst to be able to work with that data. The only thing that limits you is how far back that data goes. I think with product, the big difference is the barrier for entry for doing product analytics is significantly higher because there is a dependency on product managers to prioritise event tracking with their engineers, to be able to produce that data.

[00:16:12] Bhav: You’re absolutely right. I mean, it’s very similar. When do you hire a marketing analyst? But I definitely think the barrier for entry for a product analyst is going to be predominantly dependent on the product manager’s foresight to be able to say, actually, hey guys, we need to start producing some data so that further down the line, we can start using that data to draw insights.

[00:16:31] Dara: Is it a bit chicken or egg as well though? Because what I was wondering, well, when I was listening to both of you, what you were saying, Barry, but also what you followed up with Bhav is I imagine there must be like a gap because when the business starts to feel like it’s ready to have that analyst or analysts and the conditions are maybe almost right, but they’re not probably going to be quite right until that analyst comes in because they’re going to come in and look at the data, say, this is missing, that’s wrong. You haven’t been interpreting this correctly. And then they’ll in turn help the business, maybe ask better questions, keep better care of the data. So I imagine there must be this kind of awkward period where the business is ready to start bringing in a team of specialists to work with the data and then that makes them realise maybe what else was wrong that they didn’t realise. And then it’s about getting that analyst properly embedded and making sure that two way communication is on point.

[00:17:23] Barry: I think that’s right. And I’ve definitely been in a few places where we’ve had that kind of awkward stage where it feels like you’re kind of ready, but for whatever reason you can’t make it happen. To some extent, I think it’s always incumbent on product managers in my mind to fill that gap. You know, I clumsily use the term of like think of product managers like grout sometimes just like filling gaps between things when there’s nothing better to fill it with. And I think analytics, like both analytics and research to some extent, although a lot of people tend to lean more on designers for that. I think product managers have to help fill the gap there. So yeah, that’s certainly true.

[00:17:57] Barry: I also say it’s worth mentioning, you know, data engineering here as well. Sometimes if you leave it too late, you can start to generate an awful lot of data and bring in an analyst. You know, if you bring in, you know, reasonably experienced analysts, they might struggle with the state of your data, the way it’s structured, I’m sure Bhav, you have something to say about that. But certainly I have this mental model of, are we in a good enough place where we can just bring an analyst in, or do we need to invest in some data engineering to ensure that when we do hire an analyst, they can hit the ground running rather than essentially not being able to answer the difficult questions that we want them to answer when they arrive.

[00:18:29] Bhav: Yeah I mean I definitely do, on this I have a preferred hierarchy of how I would hire. If I was building a company and I was hiring a data team, it would definitely be engineer first, then analyst. I’ve actually seen and heard examples, I’ve spoken to founders of startup companies where they actually went straight in and hired a data scientist first and the data scientists spend all their time modelling data, building data pipelines, and actually doing very little in ways of actual data science. So, I think you need a solid foundation for a company to start using that data to be able to ask, even at the very beginning, basic questions that product managers, designers, engineers can answer themselves. You only really want to bring in that analyst when you’ve kind of done as much self-serve as you can, and now you kind of need help to start using some more advanced analytical methods to go and, you know, really under the hood of your product and your users.

[00:19:18] Dara: So where would that person’s, sorry, Bhav, I was going to ask you where that person would sit then, so if you’re just starting to build that data team, but it’s going to take time to have engineers, analysts, and different levels of seniority, let’s say you bring in that engineer first, where do they sit if there’s no existing data team in the business?

[00:19:35] Bhav: I mean, I think for me, data engineering sits within the software engineering part of the organisation, they are engineers at the end of the day. They’re not doing front end or back end coding, but they are writing a ton of scripts and modelling data and building robust pipelines to be able to really grow the, you know, the data that’s coming into the organisation, flowing through it, and start connecting it.

[00:19:56] Bhav: So for me, it’s always the software engineering team, like that’s where data engineers sit because there’s very little at that point for them to do in interacting with stakeholders. I think when you need to interact with stakeholders around the data, that’s when you start bringing an analyst or you have proficient product managers who can start answering some basic questions and then, you know, and so on.

[00:20:14] Dara: So on the analyst side, then would you, if you’re saying that’s when, that’s when you’d actually have some involvement with stakeholders. So with that first analyst, they’d need to be relatively senior. It wouldn’t be a good idea probably for a business to bring in a junior analyst thinking, oh, well, that’s fine we’ll get them in low level, but they’ll be able to just answer the questions we give them because you’re probably going to give them the wrong questions. They interpret them wrong and give you back the wrong information in return, is that kind of fair? You’d bring in someone relatively senior that they’d actually be able to have those stakeholder conversations.

[00:20:44] Bhav: I think it depends on what you’re looking for from the analyst. One of the things I’ve really enjoyed working with Barry around is that analysts within Barry’s team have always considered thought partners as opposed to sort of like data pulling monkeys right. You know, having worked with you for a while, I’ve always known you to bring problems to the table as opposed to, hey, can I have this data or hey, can you pull this report for me? And I think that’s where you need to decide if you want someone who is a thought partner, I would lean towards a slightly senior end of the spectrum. But if you just want someone to write SQL scripts for you, then I think you can get away with hiring a more junior person.

[00:21:17] Barry: I’d maybe add to that as well and say that if you’re in a small company like a startup, I definitely agree that a senior hire makes sense earlier. I think if you’re leaning towards a junior hire, I would question whether the work is meaningful enough for the expenditure of the salary, to be honest, think about it and come just straight up startup realities of your runway. Can that stuff be automated? Are there some tools that can help you get the answers? There probably are. In larger companies I don’t know enough actually about kind of a product analyst career paths to know whether what I’m saying is right or not, but my gut feeling is that large companies might be better, more better positioned to kind of grow more junior analysts than startups.

[00:21:54] Daniel: Let’s say you’ve got the budget, you’ve got the heads, let’s say there’s multiple product teams all with their own sort of slice of a product struggling to come up with an example off the top of my head. Let’s say you’re working at Uber and you’ve each got your own products that you’re working on. Each one have got a product team, product managers, designers, everyone, they’re all kind of rallying around a specific sort of group. And let’s say you’ve got a budget for an investment into analytics, into analysts, into the whole, the whole stack, let’s ignore the engineering and the science for now but we’re talking about the tools, the methods, the reports, the event schemas, and things like that.

[00:22:24] Daniel: Now, do you kind of integrate that across the product teams, or is there like a dedicated analytics function within the organisation that then kind of pulls and requests resources from each of the product teams or sorry, vice versa. Do you know, or do you have any opinions or thoughts around the best way to Integrate analytics within the organisation or within the product, because I’ve seen it every flavour of this in my time in my career, and then I’m never sure if one way is better, a lot has some dependency I can imagine on lots of many factors not just the kind of black and white of this, but I wanted if you had any thoughts or views on it.

[00:23:00] Barry: Yeah I mean, I’m very interested to hear Bhav’s take as well. Mine would be to avoid that situation in the first place for starters is by not having loads and loads of teams before you have any analysts. So that the analytics function matures with your, with your business assuming you haven’t avoided that and you’ve already got a bunch of teams with their own things. In my mind, you probably want to get to a relatively mature product analytics function quite quickly. Talk about a lot of different product teams that assumes cross-functional working in my mind. So you’ve got say squads of product management, design engineering. My preferred way to would be to have analysts embedded in those teams as Bhav put, you know, partners in those teams and try and make, do that as quick as possible. At the same time, that does mean for something of that size, you would be needing to invest in the data engineering and all those other things as well that would happen outside of those teams more foundationally to make sure that the data is, you know, because the data won’t be structured cross functionally so you’d need to make sure that there’s some good foundations there. So that’d be my take, what do you think Bhav?

[00:23:55] Bhav: I love the way we worked at Gousto, I think that was one of the most effective cross functional working teams I’ve ever come across. I think generally there are three schools of thought when it comes to setting up analytics for part of the organisation. You have your dedicated analytics team. They work in a very, you know, ticket in, ticket out way. There may be some collaboration, but generally the analysts aren’t dedicated to, you know, the marketing team or the product team or something like that. Then you have your completely dedicated analyst who sits as part of the product team, they report to the product person, maybe a software engineer or something like that.

[00:24:24] Bhav: I think with that way, whilst you get domain expertise, what you really lack is the ability to have that analyst grow in a very horizontal way across multiple different parts of analysis. So experimentation, doing different types of report pulling and, you know, segmentation, things like that. So my preferred way of working is the third school of thought, which is a hub and spoke model where you have a central team, but the analysts within that team are dedicated to the different products, squads or teams. And they can always come back together and sort of like share ideas and learn off one another and really grow and elevate the analytics function.

[00:25:00] Bhav: So if you can, if companies have the budget the hub and spoke model for me is the most effective. So I’m just shifting gears a little bit and away from sort of like team structures, Barry, I’d love to hear sort of like your experience on working with analysts and when it comes to things like OKRs and metrics, like how do you like to work with analysts?

[00:25:18] Barry: Well, a lot of my experiences here are from Gousto Bhav, so you should be familiar with them. I think if you assume that structure of having a dedicated analyst to your particular area, your particular domain, then I think there’s yeah, it’s two or three types of work that tend to do with them. You’ve just touched on some of them, experimentation, analysis for discovery, so helping inform the things that we’re going to build and prioritise to build. And yeah, also defining success measures and identifying targets and things like that. So the way I think about working with analysts there is in quite an organic way, really.

[00:25:52] Barry: I mean, I think if you’ve got that cross functional environment. You know, you have kind of systems that you know, things like you, you constantly want data insights rolling into your team’s kind of collective brain and be able to make decisions based on them. If you’re talking specifically about metrics and OKRs, then there tend to be some kind of some cadences that you’ll, that you’ll have in a given situation. So at Gousto for example, we had quarterly OKR planning and I think we did probably six-monthly strategy settings, stuff like this. And so there would be these kind of set points where you would have a natural, okay, let’s revisit our success measures or the strategy is looking like this. What are the right measures of this?

[00:26:29] Barry: I remember working with one analyst at Gousto on some really interesting different types of measures. You would create these almost like these models that we would use to measure success of certain things. And, you know, we work in an environment where there was enough data that you could come up with these really cool metrics that you thought best represented the type of thing that you want to see, the type of behaviour that you were hoping for. And I think it’s a difficult thing, and maybe it’s because I haven’t actually done it all that much, it just feels very organic. You’ve got to kind of create the space to have a bit of back and forth and a bit of creativity, dare I say, about how you’re kind of tackling these things and thinking about the right way to measure things and definitely a full on kind of collaboration It’s not a very transactional way of working between a product manager and analyst in my mind, I think if you do have that you’re probably missing something. Hopefully that answers your question enough.

[00:27:12] Bhav: No yeah, I mean I agree I think that kind of putting analysts in situations where they’re able to bring something to the table, maybe if I frame another way, if I’m an analyst and my role is to work with product managers, what advice would you give to any analysts that are listening who, you know, maybe never worked with product teams before to get the best out of that situation or the relationship and ensure that the outcomes are always as, you know, as maximum as possible.

[00:27:38] Barry: I mean, perhaps this is where maybe I’ll say something controversial I don’t know. I don’t know what the average analyst thinks about this. But certainly my opinion is that you should be hopefully in an environment where you can challenge things. You know, normally you will have access as an analyst to information and a way of thinking, a mode of thinking as an analyst that other people in your team, your product managers and designers and engineers, they won’t be thinking like you, they won’t have access to the same information as you.

[00:28:02] Barry: So to maximise the outcomes, you’ve got to become an expert at communicating that. Ensuring that the people in that team understand exactly what you know from the empirical data that you’ve seen. And that’s actually, I would say that’s the biggest gap that I’ve seen in cross analysts and stuff that I’ve read online as well that there is that sense that I think it seems quite a transactional discipline. I think you’re missing a huge amount of the value if that’s the way in which you’re working with any, whether it’s product management or marketing or anyone else, if it’s too transactional answering questions back and forth, then I think you’re missing a whole bunch of value.

[00:28:36] Bhav: And then on the flip side, I guess, what advice would you give to product managers to maximise the relationship with the analyst to make sure that again, you’re, you know, you’re maximising the outcome?

[00:28:45] Barry: Take analysts outside of their comfort zone, put them into cross functional situations. Put them in creative, organic situations and ask them to put what they know to work.

[00:28:54] Daniel: And just remember they’re not a vending machine.

[00:28:56] Barry: Exactly, absolutely yeah.

[00:28:57] Daniel: I completely agree with that, by the way, Barry. And I think, you know, speaking as an, as an analyst and have been, you know, my whole professional career, I think, you know, that’s something that’s the, the biggest, well, often, and I have a pet peeve around when people call it soft skills, but I mean it’s about this idea of communication of just saying, okay, you’ve done some good work now without the communication aspect, it goes on deaf ears or it will never be seen right. And so if a tree falls in the woods and no one’s around to hear it, does it make a noise? And I think it’s the same kind of thing with analysts.

[00:29:24] Daniel: And I completely agree that the kind of communication aspect of that, or I don’t want to call it data storytelling. There’s all sorts of these weird terms that have popped up over the years and disappeared probably as quickly as they arisen. But I think that is a huge, a huge aspect of it. You can’t realistically just be really, really good at being an analyst without being able to communicate the thing you’re good at. Otherwise you’ll never get anywhere with it, really.

[00:29:45] Dara: It’s a two way street, isn’t it? Because, and I’m going to just be, I’m going to try and be a bit controversial now, just to kind of make this interesting, but there is that stereotype of, of the analyst that, you know, give me the query and I’ll return the results and maybe not always being able to understand the full business context, but it’s a two way street, isn’t it? So I think often what happens is people in businesses don’t necessarily understand the data the way that they should, so they will go to that analyst and they will maybe ask really poor questions or they won’t ask the right follow up questions and then they’ll just take the answer they get and then they’ll blame the analyst if it doesn’t enable them to make the decision they want to make. So it’s kind of a two way thing, isn’t it? It’s like two people who speak different languages and they have to kind of find that common universal language and then build on that as time goes on.

[00:30:35] Barry: Exactly, and I think this is where cross functional working comes in as a solution to that problem. I think one thing that cross functional teams does is that it minimises those kinds of stereotypes, the kind of the barriers between functions, because you’re just spending time with people every day whether you’re remote or not. I’ve certainly found this dynamic of stereotypes kind of diminishing over the course of my career, the more cross functional working I do.

[00:30:59] Barry: And I think analytics is probably, it feels like the first, I say the furthest behind just anecdotally in that not only do I think that analysts haven’t been included in the kind of the cross functional revolution of the last like 15, 20 years or something where I think they should have, but also again, maybe a controversial statement, but I think some analysts are quite happy with that.

[00:31:17] Barry: You know, they’re quite happy being functional sitting behind their keyboards. and not having to interact with groups of people. So I think these two things have kind of got to come together at some point. And in my mind, the best analysts are those, and of course, I would put Bhav in this group who can kind of bring, who can bring a lot of this data to life and ensure that it has impact.

[00:31:35] Bhav: Thanks, Barry. I appreciate that. Dan, you were saying something around this and it triggered a thought for me, actually. And I think it comes down to an element of coaching in both directions. And Dara, you just mentioned it as well around it being a two way street. I think when product manager asks a question that you you know, it might not be the right question to ask, I think it’s up to the analyst to coach the product manager into that way of asking those right questions. And of course, this will come down to the maturity of the analyst and how, what level they’re at obviously, if you’ve got someone who’s junior, they’re going to take that request and blindly return an answer.

[00:32:04] Bhav: But if you have got someone who is a bit more senior, maybe he’s been in the organisation a bit longer, has that domain expertise of within that product. I think they’re in a much richer place to create that conversation, which allows for more meaningful outcomes and outputs of work. And on the flip side, I think it’s, you know, product managers are in a great place to coach analysts and bring them out of that shell because, you know, there are certain skillsets that product managers bring to the table that is you know, certainly lacking when you think about traditional analysts. So yeah I agree and I think the only way to break this down Barry, as you said, is to introduce more cross functional working.

[00:32:36] Daniel: It’s just another example, another good example of that first hire being really key and not going too junior and saving money on the salary and going a bit more mid level or senior just to kind of get that good foot in the door for the whole future of analytics in that company, really, right? I have a slightly broader question, Barry, just because in your introduction, you mentioned about doing this or being in the product space for, for 10+ years, and you started working in games for kids, then you went into like ingredient delivery and food, and then now you’re in pensions.

[00:33:06] Daniel: And so these are three, if you were to draw a triangle, I think these would be each corner of a triangle in terms of industry. So how does, how does product, and I suppose from my perspective, analytics. How does that all change or does it change between those three very dramatically different industries? Is it independent of the industry or does that have a huge part on how this whole ecosystem of product analytics works?

[00:33:28] Barry: I think you might get different answers from different product people. But my career might give you a clue to my answer, which is, I think that there’s a lot of just very core product things that are the same, regardless of the industry or the vertical you’re working in. Domain knowledge is very important, but it can be built relatively quickly. You know, when you’re hiring a product manager, you’re probably thinking about hiring someone for, you know, at least 18 months to 2 years in terms of the, kind of the, the investment you’re making in them.

[00:33:57] Barry: Really good domain experience can be built over 3 to 6 months. So I think a lot of it can depend on the company situation, how much domain experience of a particular thing you have in house tends to already be quite a lot, whereas product managers bringing the kind of the consistent, the core kind of fundamentals of good product thinking, I think can be applied to any context. You’re right, I’ve certainly sort of stretched the, I feel like I’ve stretched the boundaries of that through my career and often gone into places, knowing very little about the nature of an industry or its history. Sometimes it’s a benefit as well you can, it’s much easier to employ first principle thinking in these industries. Often to the annoyance of people who have been in the industry for a long time, because you know, you’re some random like tech person turning up pretending you can fix everything and invariably you can’t. Yeah, certainly interesting.

[00:34:42] Bhav: Yeah I mean, Barry, you mentioned first principles thinking and that put a big smile on my face. One of the first things I do when I join any organisation is to speak to the finance team and understand what the revenue model looks like. Because I think once you understand how that company makes money, you’re in a much better position, whether you’re an analyst, a product manager, you know, an engineer, to understand what those levers are that drive users into the product and out of the product and what causes them to purchase and how, you know, where are the breakpoints where you lose money and where you make money. And I think if you can understand all that, then regardless of what industry you’re in, you know, you can go from, you know, like children’s gaming all the way to food to pensions relatively quickly. And then you have your underlying skills that bring all of that together.

[00:35:23] Barry: Yeah, I would also add maybe two things that I do on top of that when I join an organisation as well, the same as you described Bhav in terms of the kind of how the company makes money, think of that as like the revenue model. I also look at the business model as well as a product person to understand the different component parts of how business operates and the underlying tech architecture. So I always book in an hour with a CTO when I join a company and really make sure I understand at a high level, how like people and data flows through their system as it currently stands. And those three things like business model, revenue model, underlying tech architecture and how people and data flow through the system gives you such a great foundation for any business you come into, it’s the three number one onboarding things probably people should do when they join.

[00:36:07] Bhav: There you go I think we’ve just designed the perfect onboarding for any company.

[00:36:10] Dara: Yeah I was going to ask where external support fits into this. Because a lot of the talk so far has been around building internal teams, but is there a point where you stop relying on or start relying on external support rather than having all of these specialist skills embedded within your existing teams?

[00:36:28] Barry: Probably two dimensions to that in my mind, one is tools and the other is consultancy. The tools, you’re obviously starting very early and you kind of want to stretch how much non-special, specifically talking about analytics, you want to use tools to stretch how much you can empower the people who are there without the specialisms. And then there does come the point you talked earlier about that kind of awkward stage of like, does it make sense to hire or not? I think that’s exactly where external support can help fill a gap as Bhav has been doing with us at Penfold recently, we’re not quite ready to take the step to make the investment in analytics fully, but we know there’s some foundational stuff we want to do. There’s some specific things we want to answer and working with a consultancy in that window is I think really, really, really helpful.

[00:37:11] Barry: And so, yeah, I think for startups in that kind of series A window that feels like the space where I think consultancies, at least in the startup world can be, can be really useful. Again, from a marketing perspective, I’m not so sure, but certainly from a product perspective, product analytics, that feels like the right sort of window. And just as you’re starting to gain traction, you’re starting to generate these large amounts of data and you want to really be scaling something that’s in a good position and you know, working with Bhav certainly helped us with that a Penfold.

[00:37:38] Bhav: In my experience, one of the things I’ve noticed is the organisations that generally look for external support, they’re usually not the tech first, like, you know, recent companies. They’re generally maybe been around a little bit longer, like 10, 15, 20 years. They have all of their marketing team set up, they have their design team set up, their product team set up and they would probably outsource the analytics or the, you know, for marketing, for product, you know, and I’ve generally seen that to be the trend. With the tech companies, I think there’s usually a very early realisation of bringing in some sort of like some data powerhouse within the organisation fairly early-ish and as soon as the data is starting to be generated. I mean, Dara, Dan, you guys have been working in agency life much longer than I have. Like, what does your typical client look like?

[00:38:21] Daniel: Well, that is the impossible question I think. Especially when it comes to marketing analytics and things like Google Analytics and, you know, how that plugs into them, marketing technology stack and things like that. Like on paper, it’s like people spending a lot of money online and ecom and, you know, digital first businesses. But the reality is that as exactly as you were saying Bhav is a lot of them have got it nailed already, or I’ve got the headcount, they’ve got an internal resource and they’ve gone all in on that very early because they need to, because it’s a dependency on the business. And I think where we find a lot of people, at least I’ve worked with over the last 10+ years has been around people that have got the revenue. So they’ve been around for that kind of 10, 15 years. They’re not kind of startup money, they’re not kind of worrying where every penny is going, but also they don’t have that kind of specialism internally, or they’ve never really invested in it before, and so it’s kind of like they’re realising now that it needs to come around to it and they’re behind, or they need to catch up fast.

[00:39:13] Daniel: And I think it’s an acceleration thing. It’s like, okay, we need to get this done, and actually we’ve worked with businesses that are well, I mean, 50 to a 100 years old and they still have a web team or they’re just, that’s still new to them. In which case the whole concept of having an analytics sort of full time employee or team is like unheard of or obscene. I find a lot of the time that I spend with clients, especially later in my career has been about kind of evangelising analytics as a, as an important thing and how it can be a full time job and how, you know, this is a worthy investment and something you touched on earlier Barry is about kind of proving the bottom line value in a sense.

[00:39:49] Daniel: And I think that’s a perpetual life as an analyst, especially if you’re an agency or freelance with this, which is like, you have to fight to prove that you’re generating revenue in some way. And I think me, Dara and Bhav, we’ve talked about this a number of times, me and Dara did a whole episode on how the hell you prove a return on analytics. I’ll list in the show notes and point people to, but I think it is one of those impossible questions. Going back to the point, I mean there isn’t one specific type of client. We work with ecom, publishing, retail or B2B agencies as well. But it is that kind of, I find it’s all comes back to maturity. It’s like, are they in a place where they are aware they are maybe lower in a maturity scale, whatever scale you pick it’s fine, where they want to be and they want to kind of boost themselves up in a maturity perspective. And I think seeking external help or validation is a good way to turbocharge that.

[00:40:34] Bhav: Barry you’ve obviously, from your own personal knowledge and I’m sure you’ve spoken to countless people within the product space. How would a product team or, you know, head of product or product director start thinking about building a business case for bringing in an analyst that is specifically focused on product?

[00:40:48] Bhav: Because I think with marketing, marketing team’s been around for so long it’s really easy for them to just say, hey, look, we need someone to come in and help ensure that every penny we spend is, you know, being spent in a way that is maximising our ROI or minimising our CPA. But in product, I guess it’s a little bit harder because product teams traditionally like to do everything in house, you know but so I guess for the point of bringing in your first analyst, you know, what kind of, if I’m a product manager, or a head of product, what kind of things should I be thinking about to build that case study?

[00:41:16] Barry: Yeah, I often look at marketing departments enviously with the amount of sort of data and provability they’re able to do relatively easily compared to product analysts, I think. Yeah, I mean, I think it’s really hard because as I said before, I talked about things like user research and product analytics being the furthest away from the provable value. Particularly in younger companies and obviously my, a lot of the, my comments here are based on startups, you know, smaller companies who are growing and have only been around for a few years.

[00:41:40] Barry: So ideally what you would want to say is you can kind of say, hey, we can be able to do experimentation and prove the value of certain things. So I think that’s maybe a good route in is the experimentation angle to say, we have someone who knows how to do experimentation. We will be able to, through the nature of the work we’ll be doing demonstrate the value that we’re able to bring without an analyst, we will struggle to do some of those experiments. I’m not sure that’s entirely true these days with the tooling, you can do experiments without analysts, but as you know, better than anyone, Bhav, I have like trust is the most important thing when it comes to experimentation.

[00:42:13] Barry: And if you don’t have a specialist checking the details, no matter what tool you’re using, there’s always a risk that you could be getting a false positive. And it’s just the worst thing that can happen to the data culture in an organisation if you lose that trust. So I don’t really have a good answer I think it’s really, really difficult. And it’s contextual, but it depends on your situation. I don’t think there’s a generic investment case you can build for analytics, I guess is what I’m saying, but you have to understand the context, diagnose the situation, organisation, and then figure out, firstly, you figure out whether or not it does make sense and if you think it does find some way to articulate that to the person you hold to the purse strings, and it’s going to be different each time.

[00:42:46] Bhav: No, I agree. I mean, it was never going to be an easy question to answer. I’ve had to pull, you know, pull case studies together and business cases together to hire analysts who would be embedded within product organisations. So, you know, to some extent I’ve had to do it on behalf of product leadership teams. And it’s never easy, you kind of assume a one to two or three pod model and hope that there is enough work, but it’s very hard to prove early on. I think getting a few quick wins in to show value of data, you know, either through self-serve or whatever is usually a good way to go. Yeah, it was a tough question on purpose. I’ve got one question that I think is critical in ensuring that product and analytics have a good relationship to maximise outcomes and outputs and before we move into rapid fire. Barry, how do you ensure that people are asking good questions? I know it touches on a topic we talked slightly about earlier, but how do you make sure that product managers, designers, engineers are asking the right questions or another way to frame it, making sure they’re not asking rubbish questions?

[00:43:42] Barry: Yeah, it’s Definitely something that requires, I think, a lot of practice and a lot of trial and error. The first thing I would say is to, is the discipline of writing, like thinking through writing is a very important way to articulate your thinking. And, you know, as with most things, if you put rubbish in, you get rubbish out. And although we’ve talked about avoiding, you know, treating an analyst like a vending machine, sometimes you do just need to ask a question, you need a specific answer to it. So the getting that question written in a way that is unambiguous, it’s very accurate and not going to return something that you didn’t actually want.

[00:44:17] Barry: It’s actually easier to make this mistake than I think people realise. I think so many people ask lazy questions and in their mind, it’s very clear and what they’ve written kind of represents it, but when someone’s coming to it fresh or thinking from a completely different angle, they might not get your intent, the intent behind it. So to get around that, I think writing things down is important, having some time to discuss it with an analyst, have that analyst kind of ask questions to you to ensure that they understand it, ensure you’re on the same page, and then they can go away and kind of get the information, come back, and there’s another exchange of views and follow up questions and inevitably both an analyst will have come up with some things that are interesting during their search, they would have thought of something that you hadn’t have thought of. And when you see the data for the first time, you immediately think of a question that you should have asked that you haven’t.

[00:45:03] Barry: And so although it’s still transactional, there is so much inside that dynamic. But there are two things that are important, writing things down and practising writing and articulating your thoughts on paper, and making space to go back and forth once the question has been asked and answered.

[00:45:16] Bhav: It’s not just for product managers to write things down. I think it’s for analysts as well as answering questions to write it in the form of narrative. I’m a big advocate for writing, it’s something I’ve worked on for years and I think when you start writing the problems down, that’s when you really start thinking about them and the different angles and, oh, actually I hadn’t thought about it this way, or maybe this is another approach. And actually you can start putting in all of those different nuances of the problem you’re trying to solve to start taking it from a single question into more of a context that you can give to an analyst that’s, you know, that’s well packaged. And that’s not to say, you know, you need to write everything down into, into war and peace. But it’s a really good practice for asking questions, but also answering questions. If people do get into the habit of writing, they’re more likely to ask better questions.

Rapid fire

[00:46:01] Dara: Okay you’re almost off the hook, Barry, but you’ve got some rapid fire questions to deal with before we, before we let you go. Okay so question one, Barry, what is the biggest challenge today that you think will be gone in five years time?

[00:46:13] Barry: I think the biggest challenge today, at least in my world in products and startups, is how will we be putting AI to work? There are so many different dimensions through which we’re using it on a day to day basis, a general agitation and fear that we’re not using it enough and that we’re not getting the most out of what’s possible and that we’re wasting our time doing things that AI could be doing for us. I think that will be a solved problem five years from now, that the speed at which things are moving, the way tools are coming onto the market, the way we’re thinking about integrating into our products, I think that won’t be a challenge in five years, I think it’d be a solved problem by then.

[00:46:43] Dara: Okay, so assuming that’s all solved, what will be the biggest problem in five years?

[00:46:47] Barry: I think in five years, AI will have transformed product management, and I think a lot of the ways in which businesses work, but the product thinking will still be there fundamentally as a thing that’s difficult to wrap your head around. It requires a lot of judgement and product strategy is still a thing that AI will not be able to do in a meaningful way and take into account a whole bunch of context because the data will just not be available for it would be my guess.

[00:47:12] Barry: I might listen back to this in five years and sound stupid, but that’s my take right now. And so therefore the hardest thing will still be, you know, prioritisation, exactly what should we build next? Based on all of this context, what is the thing that’s going to make the most difference to what we’re trying to achieve as a business? So I think that’s a, that’s a big challenge now. And I think that will persist despite the kind of the transformation that lots of ways of working are going through.

[00:47:32] Dara: Okay, so what’s one myth that you’d like to bust?

[00:47:34] Barry: This is just like a small, a small one that annoys me to be honest, which maybe is not the best forum for it because it’s more for engineers. But I think it counts for analysts as well in some ways. I’ll summarise it by saying Jira is not a product management tool. This idea that ticketing that product managers somehow do ticketing systems and hand people tickets to do is an extremely antiquated way to think about your role as a product person and for other people to think about your role as a product person, anyone can create tickets. Project management should be socialised, it’s not a specialist skill, it’s something that everyone should be able to do. And if you are a product manager who’s spending a lot of your time doing project management, it’s a waste of your time and a waste of everybody else’s. If you’re someone who isn’t doing project management, it’s kind of offloading the thinking and the organisation of your own personal time to others in your team, then you’re not pulling your weight.

[00:48:23] Dara: So that could be the answer to the next question as well, but if you could wave a magic wand and make everybody know one thing, what would that be?

[00:48:32] Barry: I’ve got to plug Penfold here. I was quite taken when I joined Penfold. You know, a lot of people are like, oh, interesting going from Gousto to a pension company. You’re like, well, interesting or not interesting to them. But I’ve found it so interesting joining a pension company. And the first thing is just the power of compound interest so yeah, that’s what I would, if I could wave a wand, I want people to understand the power of compound interest. It’s the thing that essentially triggered Penfold to exist. One of our co-founders read an article about compound interest and realised if people understood this. They would put money into their pension in their twenties, in the early twenties. And so, yeah, if I could wave a magic wand, if you’re in your twenties, listening to this, please go and read about compound interest and save your money into your pension. You’re invariably not saving enough money into your pension. Lots of arguments against it, I feel like I could debunk almost all of them. I haven’t got time, contact my LinkedIn if you want to.

[00:49:20] Daniel: We need to get on TikTok if we want to get the 20s though, Barry, sorry. This is purely podcast audio.

[00:49:25] Barry: That’s a good point. Okay, well, if you’re over 30, don’t bother increasing your pension then.

[00:49:30] Bhav: I will say having worked with Barry and doing some consulting work for Penfold, it’s a fascinating space. There is so much I didn’t know about pensions that I learned in a very short space of time. So yeah, listen to Barry, learn about your pension and start thinking about it more seriously.

[00:49:45] Dara: I just think of Danger Mouse when I think of Penfold. Does anyone get that reference?

[00:49:48] Bhav: I’m old enough to think of Penfold as well from Danger Mouse.

[00:49:52] Dara: I’m sure there’s no link whatsoever.

[00:49:54] Barry: There isn’t, the co founders had no idea until they’d named the company. But it’s a nice icebreaker.

[00:50:01] Dara: So last question, Barry, and maybe the toughest one, actually. So I’m going to sweat you here a little bit. What’s your favourite way to wind down when you’re not working?

[00:50:09] Barry: My favourite way to wind down is to go on long walks with my dog with an audiobook or a podcast.

[00:50:17] Dara: What’s your dog called?

[00:50:19] Barry: My dog’s called Pixel.

[00:50:20] Dara: Amazing.

[00:50:21] Barry: Unfortunately, she was named about a month before, well, two months before the Google Pixel phone came out. So there was this first era where people thought she was named after a film called Pixels, which I didn’t know existed. And then after that, they’re like, oh, you like the phone. So apparently people didn’t know what Pixels were before those two things.

[00:50:38] Bhav: Adam Sandler movie if you want to watch it. It’s terrible.

[00:50:41] Daniel: You’ve really, you’ve really sold it, Bhav. All right thank you so much for joining us Barry. It has been a great conversation and yeah, all of the links to everything we talk about will be in the show notes and links to Penfold so that we can all start saving for our future.

[00:50:55] Barry: My pleasure, thanks for having me.

Tags: analytics team marketing analytics Podcast product analytics The Measure Pod
Share:
Written by

Daniel is Principal Analytics Consultant and Trainer at Measurelab - he is an analytics trainer, host of The Measure Pod podcast, and overall fanatic. He loves getting stuck into all things marketing, tech and data, and most recently with exploring app development and analytics via Firebase by building his own Android games.

Subscribe to our newsletter: