Today I’m joined by Jonathan Cairns-Terry, who is the Head of Insight Products at the Care Quality Commission. The Care Quality Commission is the the regulator for England for health and social care, and Jonathan recently joined their data team and is working to transform their approach to be more product-led and user-centric. Throughout our conversation, Jonathan shares valuable insights into what the first year of that type of shift looks like, and why it’s important to focus on outcomes, and how he measures progress. Jonathan and I explore the signals that told Jonathan it’s time for his team to invest in a designer, the benefits he’s gotten from UX research on his team, and the recent successes that Jonathan’s team is seeing as a result of implementing this approach. Jonathan is also a Founding Member of the Data Product Leadership Community and we discuss his upcoming webinar for the group on Oct 12, 2023.

Highlights/ Skip to:

• I introduce Jonathan, who is the Head of Insight Products at the Care Quality Commission in the UK (00:37)
• How Jonathan went from being a “maths person” to being a “product person” (01:02)
• Who uses the data products that Jonthan makes at the Care Quality Commission (02:44)
• Jonathan describes the recent transition towards a product focus (03:45)
• How Jonathan expresses and measures the benefit and purpose of a product-led orientation, and how the team has embraced the transformation (07:08)
• The nuance between evaluating outcomes and measuring outputs in a product-led approach, and how UX research has impacted Jonathan’s team (12:53)
• What signals Jonathan received that told him it’s time to hire a designer (17:05)
• How Jonathan’s team approaches shadowing users (21:20)
• Some of the recent successes of the product-led approach Jonathan is implementing on his team (25:28)
• What Jonathan would change if he had to start the process of moving to outcomes over outputs with his team all over again (30:04)
• Get the full scoop on the topics discussed in this episode on October 12, 2023 when Jonathan presents his deep-dive webinar to the Data Product Leadership Community. Available to members only. Apply today.

Quotes from Today’s Episode

• “How well do we understand what someone’s trying to do, ultimately? How well do we craft a solution that fits seamlessly into what they’re trying to do rather than, ‘Here’s another dashboard you got to look at, here’s another step in your workflow that you’ve got to remember to do, you got to look for insight 17 on page three of dashboard five before you can get your work done.’” — Jonathan Cairns-Terry (08:57)
• Re: identifying his team’s adoption of a product-oriented approach: “I think you’re always trying to take the temperature of the team and get a sense of how people are feeling about what they’re doing. I think you can get a sense of when people feel like their role is clear or not. But what I’ve really appreciated is the way the team have embraced the user perspective.” — Jonathan Cairns-Terry (10:29)
• “I think what I’m looking for from [a UX Researcher] is to help us understand our users better: what are their problems, how could our solutions contribute to making their world better in some way, and to help us engage as well with the things that we were already doing.” — Jonathan Cairns-Terry (14:47)
• “When we chose to structure the team, we took a little while to provide some sort of sub-structure to the team, and what we chose to do was group ourselves around users rather than sectors or subject matter expertise or those kinds of things because we wanted to set an expectation that we would be growing in our understanding and depth of knowledge about the different roles of the people in the organization that we were working with.” — Jonathan Cairns-Terry (16:02)
• “I think there’s a danger that we design our products for the top 20% of most data-literate inspectors. … But then you’ve got, perhaps 80%—thousands of people potentially—who aren’t specialists, who also need to access and understand this data and take useful things from it. And that can’t just be data literacy; that also needs to be to do with the way that we present insights to them.” — Jonathan Cairns-Terry (19:52)
• RE: Shifting a data team to a product-led approach: "One of the things we did early on was prioritizing trying to get that sense of team, trying to make changes and do the practical stuff, because we wanted to have a sense of identity and feel that we were all in this together.” — Jonathan Cairns-Terry (31:55)

Links

• Care Quality Commission: https://www.cqc.org.uk/
• LinkedIn: https://www.linkedin.com/in/jcairnsterry

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Jonathan Cairns-Terry on the line from the UK. How are you, Jonathan?

Jonathan: I’m good. Thanks, Brian.

Brian: Excellent. And you are helping regulate the quality of care and social services in the UK. Is that correct? Did I get it right? That’s what the UK Care Quality Commission does?

Jonathan: Yes. We’re the regulator for England for health and social care, that’s right.

Brian: Excellent, excellent. You used to be a math person and now I’m a product person. What does that mean? Like, I want to know, what did you let go of and what did you have to bring on, and what were your demons that you had to fight through? Or like, I don’t know, what was that transition like? Or maybe it wasn’t. Tell me about that?

Jonathan: Well, the maths part was quite a long time ago. I did a degree in maths and then became an auditor when I started my professional career. I think a lot of the maths corners were probably knocked off me as part of my auditing experience. In maths, it was all about closing all the little loopholes and making sure you’ve got everything absolutely spot on, but in auditing, it’s you’ve got concepts of materiality and things like that. And so, I had to learn pretty quickly—probably slower than I would have liked—but that you’ve got to let the details go a little bit and focus on the bigger picture.

So, by the time I got to analytics, I think hopefully, made the adjustments and learned to think about the business outcomes more than focusing on the technical detail. Most of my maths was more esoteric [unintelligible 00:02:04], so less of the statistics and that kind of thing. So, a lot of what I brought from that is really around problem-solving mindset, how I approach problems and think my way around the solutions more than it is about, maybe, the technical detail of some of what I was learning.

Brian: Got it. Got it. Do I sound American when I say math? I always forget you guys pluralize [laugh].

Jonathan: [laugh]. The worst was when I was spending some time in Australia, and the data [dayta]-data [dahta] divide was—

Brian: Oh, okay [laugh].

Jonathan: —real and painful [laugh].

Brian: You hear both of those around here and in New England, you also hear data [dater] because they take Rs off of words, but then they kind of get added on to the—it’s like you net out at zero Rs. But [laugh] anyhow, I don’t want to get into all of that. So, you’re running this insight products team. Who consumes insight products that the Care Quality Commission—like, who are your customers? Are they patients? Are they, like, citizens? Are they only the internal stakeholders that are out there, kind of… policing is probably the wrong word, but regulating the care that’s been given? Tell you about who’s using these solutions that you make.

Jonathan: Sure. So, our users are really anyone who’s interested in quality of care, but primarily that’s internal users at the moment. So, that could be inspectors, chiefs of inspection, people making policy, those kinds of decisions, colleagues in the wider data and insight unit. So, we’re a team within a wider data function. In the future, we’re looking to share more with providers and shine a light on the data that we’re using for regulation so that they can understand the way that we’re looking at their data. You can help increase data quality that way if there’s things that haven’t translated quite right, all those kinds of questions. But primarily, we’re building products for internal users at the moment.

Brian: And my understanding is, you’re fairly new. You’re about a year in at this current role. Is that correct?

Jonathan: Yes, that’s right.

Brian: Got it. And during our, like, pre-talk, you were telling me that at the time you joined, they were going through a transformation on the data team and basically taking kind of these generalist data professionals and turning them into, like, a platform team, a maths team—with a ‘s’ at the end—your BI developers, the people doing the dashboarding, and this kind of design work we might call it. And then you came in and you’ve got this product orientation. And I’m wondering, like, how does that—does that have anything to do with the way that team is structured, or is it kind of—it’s orthogonal to that? Like, how do you see that relationship between what you’re trying to do with a product orientation and the way that team is structured?

Jonathan: Yeah. So, I think that that’s a really live question for us. So, in our, sort of, broader organization within data and insight, we’re about 200 people. My team is around 20. We’ve got teams that are kind of the business partnering to data and indicator development, that’s the sort of what characterizes the maths bit.

We’ve got the platform team and there’s a number of specialist roles in there, so data engineers and so on; it wasn’t just analysts who became that, although we’re open to that as a training pathway in. For my team, we’re working through what that looks like. We’ve started out with a team of analysts, but we’re looking to take a product approach, manage across a product lifecycle, and adopt some of the disciplines and processes and skills and learn the things that have been learned at cost by people in other industries. And so, we’re working through what that looks like. It’s quite a broad thing to do, so we’re primarily responsible for that, kind of, the consumption layer of analytics.

At the moment, that mostly looks like Power BI dashboards, and so you’re asking people in a single role to do everything from problem-solving and making technical changes and deploying Power BI products, and you can take that all the way up to, kind of, software level disciplines around continuous integration and deployment or that’s where we’d like to go with it—to wanting people to do the design and then also the discovery and product management piece and be really responsible for the vision and where they’re taking the product, how they understand the users and the users’ problem space, and turn that into a broader solution. So, that’s a really big role.

You’ve also got specific roles under that you might see in a more traditional product team around user research and delivery management or some of those adjacent disciplines, and how do we structure ourselves in a way that allows us to execute on all of those in the best way? How do we give our people the right support to have a job that they can get their hands around? And a career pathway as well because the analyst, sort of, career pathway might look quite different to what you’d expect and the skills and so on that you’d be expecting product managers or developers, or so on. So, that’s something we’re exploring, considering bringing in additional job descriptions to the analyst job description, perhaps a dedicated product manager job description. We’d love to bring in a designer to help us broaden the space of the solutions that we’re considering when we’re talking to our users. When you’re a team of people skilled in Power BI and someone comes to you with a problem where they want to access data, it’s very easy to immediately jump to a Power BI solution than a dashboard solution, but I’d love for us to think more broadly than that.

Brian: How do you talk to the team or your stakeholders about—or maybe you don’t talk about product, but if you do talk about this product orientation, like, how do you express the benefit to them? Or maybe your team’s like, “Well, how do we know when we’re doing this thing?” It’s almost like design. It’s like, how do—are we doing it? Are we not doing it? How do they know when they’re doing it and what it means to be successful? Because there’s a point to you wanting to do this and I’m curious, like, what is that and how did you communicate that to the team? What’s the problem you’re solving by adopting this product orientation?

Jonathan: So, there are a couple of things, I guess. One is around adopting kind of a product management lifecycle as opposed to a project lifecycle. So, before our reorganization, we were organized by sectors, things like dashboards and things—it would more often happen that an individual would be doing analysis end-to-end so they’d received the requirements from someone or do some investigation, they get the data, they’d move it through analysis lifecycle to deliver a dashboard, and then that will be supported by that individual, but perhaps only for as long as they have capacity or they’re in the organization or what have you. But with the product orientation, we’re looking to move more to an idea that these are corporate assets that belong, sort of, to the business, I guess, or to the organization that needs to be managed in a consistent way, developed, and those kinds of things. And so, part of it is introducing that product management lifecycle of we’ve broken it into creation, maintenance, development, and retirement of products as well, and sort of thinking actually, when do we no longer need to support something or when do we need to choose to not do it, to prioritize something that’s more important.

So, there’s that side of product, but then the other side of it is around the user orientation and really thinking and challenging ourselves on outcomes. How well do we understand what someone’s trying to do, ultimately? How well do we craft a solution that fits seamlessly into what they’re trying to do [it 00:09:05] rather than here’s another dashboard you got to look at, here’s another step in your workflow that you’ve got to remember to do, you got to look for insight 17 on page three of dashboard five before you can get your work done. And that’s the kind of thing that we’re really looking to challenge ourselves on. And so, in terms of how well we’re doing at that, we’ve recently gone through looking at what we want to consider as impact metrics.

And so, how we know we’ll be successful will be how well, I guess, we achieve our outcomes and how we measure those. And some of them are easier to measure and some of them are harder. And some of them are more ambitious and some of them a little bit, sort of, closer and within our remit. But that’s something I think we’ve perhaps seen as a gap is that ongoing measurement of progress as we’ve just been growing in maturity. You can’t address everything at once, but that’s something we’re looking to make progress on now and help people to provide some clarity with what good looks like.

Brian: Do you have any signals along the way? Are you trying to objectively evaluate, kind of, this transformation, and are there some signals along the way you’re looking for to know if you need to course correct or, like, this is getting friction or pushback or wow, this is, like, having an impact that I want? Like, are there signals that you’re looking for as you go through this?

Jonathan: I think you’re always trying to, sort of, take the temperature of the team and get a sense of how people are feeling about what they’re doing. I think you can get a sense of when people feel like their role is clear or not, or that kind of thing, but what I’ve really appreciated is the way the team have embraced the user perspective and you hear people actively engaging with user research. We brought someone in who’s got—we’re really fortunate, he’s got some experience with user research, he’s helped us—able to help us get a bit further ahead with that as well, and just the willingness to ask those questions in a different way. So, I think we are picking up those soft signals; we’re talking about users a lot, we’re asking the right questions when we’re thinking, considering developing new solutions. I think some of the challenges, sort of, as you talk about going through that transformation are really about, in a wider organization of 200 people that’s used—just talking about the data and insight unit—that’s used to doing things in a certain way, and building that level of understanding when everyone’s working in new roles and new teams, what are the interrelationships within teams, what am I responsible for, what are you responsible for, things like that.

So, for example, we’ve got a lot of—well, Power BI is our analysis tool as I’ve mentioned, and there’s an expectation that people across the data and insight unit and indeed across the organization will be using Power BI as part of their work. And so, someone who’s in our business partnering space, maybe our [operational 00:11:47] business partnering or our more strategic business partnering, will start some analysis and take it to someone based on a request or a need that they’ve identified or been brought, and then they’ll start to build out a solution. And then at some point, someone goes, “That’s great. I’d like to see that every month.” And then what’s the point at which that becomes—that’s actually something that is a corporate asset that needs to be lifecycle-managed versus something that’s sort of a tactical piece of analysis that’s really helpful?

And how do you make that transition? And how much are they adhering to or responsible for adhering to visualization best practice, for example, or our design guidelines? And have they had the conversations upfront that we might if we were doing it to create a product ourselves? And so, you’ve got to do that through—a lot of that is through experience, I think, communication as well and trying to set out the boundaries. But I think you sort of—you make progress, then something comes [up 00:12:44], and you sort of see someone’s gone further than perhaps you’d like, and you just manage it through relationship and try to grow in it together, I suppose.

Brian: Yeah, the—I heard this great podca—The Knowledge Project is a podcast I listen to all the time—and I forget the name of this PM; he was at Twitter and Stripe for a long time—and he talked about this idea of everything should be data-driven and metrics-driven, and if you’re not measuring it, you can’t improve it. And he’s like, that’s not correct because you can evaluate things and you can measure things. And I thought that was such a deep insight that I’ve been wanting to bring this into this show because you’re doing very much that, which is you’re not necessarily measuring everything quantitatively, but you are evaluating the feedback and what you’re hearing, which can be qualitative. It can be stories, it can be opinions, temperature of the team, these are all things that we can do that may take a lot less time than doing formal measurement, which could be quite difficult to set up sometimes. So, I like that there’s some—you’re taking in the signal and sounds like you’re reacting to that and all that.

The thing I want to double-click on and go down a little deeper on is you said you brought in this, it sounds like a UX researcher? I don’t know what their title is, but someone that knows how to do user research and it sounds like something changed or they brought some insight into your team. And I’m curious, like, what are some of the things that you either learned from this person about how you do it or what to do? Because I think that is an area that data people get kind of gets scared of sometimes is like, I know I should be doing this, but like, what am I supposed to ask this person? Like, so I’m curious, like, what have you learned from bringing in that person about doing user research?

Jonathan: Well, I think that’s very much a work-in-progress piece for us as well because this individual was brought in in a sort of a quantitative analyst role. And we’ve been really fortunate that she’s brought some of those skills in. But we also have user research elsewhere in the organization, and so at the moment, she’s more been sort of helping us liaise with them and bringing in some of her own knowledge and training, helping some of the rest of us to do some of that kind of work as well. I think what I’m looking for from that role is to help us understand our users better: what are their problems, how could our solutions contribute to making their world better in some way, and to help us engage as well with the things that we were already doing.

One of the things that I think we’re doing more of than perhaps we used to is taking our solutions to use [this 00:15:09] building them and saying, “What do you want to see? What can you see here that you weren’t able to before?” And those kinds of questions, sort of, as we’re developing, do more of that sort of iterative feedback approach. But I think that’s certainly one of the areas that we’re growing in. But as I say, we’re fortunate to have… not quite accidentally, but brought someone in who has some of that background, which has been a real help.

Brian: Do you see that as, like, ideally, you have that as a dedicated role that goes out and does that kind of work for your team, or that’s a skill that all of your own people—or at least the ones that are in the closest thing to a product title—should be doing?

Jonathan: Well, I certainly think anyone in a product title should be doing that themselves, on some level. I think—and I’m still very much learning in all this space as well, but sort of, the discovery piece is really important. And when we chose to structure the team, we took a little while to provide some sort of sub-structure to the team, and what we chose to do was group ourselves around users rather than sectors or sort of, subject matter expertise or those kinds of things because we wanted to set an expectation that we would be growing in our understanding and depth of knowledge about the different roles of the people in the organization that we were working with. So, I think there’s certainly a place, [and 00:16:29] I would expect that we would have user research as a dedicated skill, certainly within our organization and in our team, partnering with people elsewhere to do it, but it very much should be part of what we’re thinking about. And it should be something, if we do go down a route of having more dedicated development resource, I’d expect them to be understanding and talking to users, maybe not at the same level, but there should still be an expectation that you’re thinking about, you’re getting in the shoes of the people who are going to use that product and you understand something about their world to make sure that it realizes the outcomes as well as it can.

Brian: You mentioned earlier too that you’re thinking about bringing in, like, a product or interaction designer to help out and kind of get out of the, you know, every problem is a Power BI problem space. What are the signals that you got that it’s time to invest in that? Like, how did you—you didn’t just wake up one day and said, “I need to hire a designer to, you know, help my team out.” Something happened to trigger that. What were those signals?

Jonathan: So, part of that for me is a learning piece. So, as I say, I’m not from a product management background myself, and so over the last year, I’ve been taking a lot of time to sort of grow in my knowledge and understanding of product management as a discipline. And so, I’ve seen regularly in the things that I’ve been reading and listening to people talking about their experience, understanding more about the role of the designer and that being seen as, like, a key piece of product management. So, that’s sort of the theoretical thing, but theory is fine. I guess in terms of a practical piece, I think it’s around, how well are we understanding, sort of, the overall user journey. How well are we thinking about how this fits into something broader than just the design piece and the user interfaces and things like that?

And are we bring sort of truly different perspectives from a sort of traditional analyst perspective, which is, we’re a lot of people who are really good and used to working with data, but we’re not non-specialists. Like, you don’t join a data team if you’re not a data person, for the most part, although we’re trying to get some people into some of these roles, maybe people who’ve been in product teams but not data teams. Like, we’d love—come and talk to us; we’d love to hear from you. But actually to see these through the eyes of someone who’s not spent their life bringing in data, trawling it for insights, those kinds of things. Because I think there’s a real danger with what we’re doing.

So, one of the things we’ve talked about is data literacy, for example. So, we’re in an organization, the wider organization is about 3000 people. And so, 2800 of those, more or less, are not in the data unit, and our products are supposed to work across the [unintelligible 00:19:11]. So, we’ve got thousands of inspectors. And it’s very easy when you’re sitting in the data unit to build a dashboard that works for someone who likes dashboards or understands dashboards or data.

And you can get a certain way with a data literacy program that raises the bar on everyone’s organizational capability, which is great, but if data isn’t one of the core competencies that’s recruited for in that role of inspector, and that’s one of the most important or a really important role in the organization with a really high headcount, how are we thinking about the way that we present data and what we can do to, sort of, meet people halfway? And I think there’s a danger that we design our products for the top 20% of most data-literate inspectors. And there are those who come to us and they love the data and they want to engage with it and understand more, and I need more on this. But then you’ve got, perhaps 80%—thousands of people potentially—who aren’t specialists, who also need to access and understand this data and take useful things from it. And that can’t just be data literacy; that also needs to be to do with the way that we present insights to them.

Can they use them in a consistent way? Can they explain them to others, and all of that kind of thing? And many, many of them will be able to do that well, but do our products reflect that need? And so, bringing in a designer—or a designer; we’re going to have one designer who saves this. This is going to be great. Um [laugh].

Brian: You mean, Superman?

Jonathan: Yeah, exactly. For a designer—

Brian: Super D.

Jonathan: Who’s coming in and I’m like, “You solve all these problems for us. It’s fantastic. There’s your desk. Come and see me if you have any problems.” But you know, bringing in more of that way of thinking and that understanding and that perspective in the way that we build things—

Brian: Yeah.

Jonathan: —who’s not a data person, I think, will really help us strengthen. And then maybe we build something that at least 80% of inspectors, and probably a hundred percent, can really get value out of it. And even those who aren’t pushing the envelope with it, they’re still able to do the core things that we need to do effectively.

Brian: I’m curious, have you ever sent any of your data team out to do an inspection with the inspector and just watched them? When do they pull out their tablet, or—I don’t even know the context of, would they be doing that real-time or it’s like, back at the desk type work, but any type of, like, shadowing to see when does data play a role in their day-to-day, kind of, life?

Jonathan: Well, it’s funny, you should mention that actually because I asked one of my deputies to [fill 00:21:45] out our [old 00:21:46] policy for doing that very recently. So, it’s something that used to happen before our restructure and it’s something that we need to get back into. I think that kind of thing is going to be really important. I’m absolutely keen to do it myself because I’m new to the organization and it’d be really important for building my understanding. There’s also, sort of, a wider transformation going on at the moment around the platform that we use to record and do our assessments and inspections, and wider than that, as well.

And the hope is that—or part of the driving force behind that is to give better tools for capturing the data in a structured way and for inspectors and assessors in different roles that we’ve got within that group to be able to make better use of the data in the assessments that they’re doing. So, there’s going to be a bit of a meeting in the middle. I think they’ll have better tools to look at insights, hopefully, potentially, on the go, or in the different aspects of their inspection journey and we’ll have a better understanding and ability to deliver really relevant things to them that moves the needle on understanding quality of care and what we’re trying to achieve.

Brian: I’ve never seen an example where spending that time, that customer exposure time, particularly in doing shadowing, is not beneficial. So, if you’re listening to this show, it’s definitely something that I advocate. And it’s not just about—there’s kind of two benefits. There—one of them is, like, yeah, sure, you get to see functionally in this workflow, like, “Oh, they’re pulling a tablet out. Oh, what are they going to launch? Oh, they’re launching Power BI. Oh, what are they looking at?” And you’re seeing which data they’re using and which of your tools, and then you—oh, they’re—they used it wrong. What is he doing? And you’re thinking—you’re running all this stuff in your head.

Very practical stuff, but the other thing you’re going to do during that time is, you’re probably going to have time to get to know Karen. Karen has a job to do. She’s an inspector. And at some point, you stop building tools for the inspection department and you start building tools for people like Karen, and Karen’s boss. And Karen and her boss aren’t so good right now because the boss got burned because the staff didn’t do something right and reported some information wrong, and blah, blah, blah, and you start to understand what Karen’s afraid of.

And it’s having the wrong information or it’s like, I don’t know how you counted the number of widgets on the screen. And we got burned last week. And you kind of like Karen now and you start to realize, like, my work has a direct impact on this person. Or we could actually, we could save her day so easily with this, like, little widget or whatever the heck it is. This is—when we talk about empathy, this is the practical development of empathy. Like, just—this is literally the practice. It’s not a fluff thing; you’re just naturally going to probably start to have some more empathy for this person.

And then your team starts talking about building things for Karen and her team, not for the whatever department, which is this faceless entity, the corporate entity. It doesn’t have a face, it doesn’t have a heart and feelings, and all this kind of stuff. And it’s hard not to when you know how your work is going to go out into the wild and you start to, like, really understand that doing a poor job here could burn somebody, you know? And maybe in some cases is, like, the data is not that—you know, it’s not that life-impacting or whatever, but it makes the work more rewarding as well when you kind of feel like Karen is going to love this because we saw the struggles and she’s going to totally dig this. Or at least you hope—that’s your hypothesis and you want to go out and validate that like a good product person. But anyhow, that’s my little—so I’m going to get off my soapbox because I want to hear more about you. But [laugh] [crosstalk 00:25:11]—

Jonathan: No, that’s great. And absolutely… absolutely. And we, as an organization, it’s a key part of our strategy to be smarter through data, and so understanding where people are at, how they’re using it, and all of those kinds of things is super important. So, I’m totally on board with that.

Brian: Do you have any before/after stories you can share or anything with kind of this—and I know you’re on a journey right now with this product orientation thing, but have you had any near-term results or kind of like, we put these two things into practice, you know, we made an adjustment to something that we learned, we sent it back out, you know, the data product delivered better results or we got some qualitative feedback? Like, anything you can share just about something that makes you feel like you’re kind of on the right track and there was a before/after you can share with us?

Jonathan: I think for us, a lot of what we’ve been doing in the last year has been sort of adjacent to the work we’ve been doing developing in that way as well. So, we’ve been learning the project management piece, but we’ve also been doing, like, systems migrations and things like that. So, we haven’t had as much time as we’d like to, to do, kind of, some of the A/B sort of pieces. But what I’m seeing, I guess, like, it goes back to the behaviors that I’m seeing, the way people are talking to users. And so, we’ve got a recent one where what we ended up building would have been really different if we hadn’t engaged with users and understood what they wanted from the tool and how they were going to use it.

And so, just some different—we had some different dashboards in different—that were sort of fragmented in different places and we’ve brought that together in a single place and we’ve talked to users about what the most useful parts are. And so, it’s really influenced what we’ve done there. So, I can’t say we’ve got metrics that we’re here and we’re there, but the way that people are starting to do that. And then there’s some other ways as well. We’ve also been trying to adopt more of an agile approach to the way that we run the team, and one of the things is just in terms of having a backlog of things or prioritization around a list of things that we’re looking to do.

And I had a conversation with one of my deputies where he was saying, “We’ve got this list of things and there’s some stuff that we’re just not getting to because we’ve got higher priority stuff.” And I think for me, that was also a really good thing in terms of, we’re doing a good job deliberately not doing things as well as getting stuff done. And we’re, sort of, picking up some of those behaviors in terms of, sort of, the best use of our time. And also, some of the stuff we’ve probably said no to where people have said, “I need a dashboard for this.” And you go, “Ah.”

You don’t just build it. You go, “Oh well, okay. What are you looking to do?” And they say, “Oh, we’re looking to do this.” And [we’re 00:27:40] like, “Oh, I’m not sure a dashboard is the right thing.” And then we’ve sort of saved the whole work of building and maintaining a dashboard that wasn’t needed.

Brian: Right.

Jonathan: I mean, one of the biggest successes overall is that we’ve got a dedicated list of products; we’ve got a product catalog now. So previously, there was a very, sort of, fragmented landscape. We did an audit as part of a systems transformation we were doing of Power BI dashboards. There were, like, 4000 dashboards or workspaces across the organization in all, sort of, various different states of this is a live—

Brian: 3996 not used? [laugh].

Jonathan: Yeah. Well, potentially. That’s the danger. Or perhaps even worse, used but not maintained. You don’t know. But—

Brian: Right [laugh]. Used with bad data that hasn’t been updated in three years.

Jonathan: Well… yes, you hope not.

Brian: I’m just kidding.

Jonathan: But you know, like, how do you get your hands—how do you get your hands around that? And so, for us, one of the big things has been, okay, so as a team, what are we responsible for? What’s that list of things that we’re saying we’re going to maintain, we’re going to monitor, we’re going to transform, we’re going to develop, if something comes up, it’s our responsibility to fix it? So, that’s actually a really huge piece around defining our scope and thinking about taking that portfolio view on of we don’t have a lot of individual dashboards. Like in the old—what I call the old world of pre-transformation, lots of good work was going on, but it was going on in isolation with individuals, for the most part.

And what we’ve been able to do, since we’ve, sort of, consolidated as a function rather than as sectors is to have common, I guess, standards and approaches and ways of doing things that allow the whole piece to be strengthened, that people don’t have to worry that stuff is not going to be maintained when they go on holiday, if something comes up and no one else has access or knows or those kind of things. Like, some of the things that I think actually—it just improves quality of life for people. You haven’t got that, sort of, anxiety that if this breaks, I’m the only person who knows how to fix it. And what I—[unintelligible 00:29:34] to earlier, that sort of corporate asset piece, how are we thinking about these things as products that add value to the organization on an ongoing basis? That I think is a really huge piece. So, we’ve got a list. It’s around 60-odd products, I think, at the moment. We probably expect that to reduce as we’ve got a new, sort of, broader system that goes online and we consolidate around probably a smaller number of products. But that’s a huge piece for us organizationally.

Brian: Are there any things that you would change, you know, if you got picked up right now and dropped into the Spanish Care Quality Commission—and let’s assume you’re fluent in Spanish now—same org, same structure, same mandate, you’re still like, I’m still bought-in on this product orientation, same space, are there any things that you’re going to do different or anything—like, no one told me this the first time. I’m not doing it this way again. Like, any adjustments you’d make about how you’re, kind of, trying to lead this process of going towards outcomes over outputs with your team?

Jonathan: It’s a really good question. I think one of the things that happens when you come into a new organization is that you want to understand and grow and find out the way things are before you start to think about making changes or making changes in your context. And so, it’s difficult to say, “Oh, I would do this differently or that differently,” but I think some of the emphasis maybe would change and some of the learning that I’ve got now would feed in. So, as I say, I’ve been learning a lot over the last year and one of the things I’ve tried to do is consistently make time to read books, listen to podcasts, get across a lot of this material, and just understand more about how to do this effectively.

And so, for example, recently I’ve been reading—or listening to—Empowered by Marty Cagan and Chris Jones. And if someone had handed that to me on day one and said, “Read this. It sort of tells you how to lead a product team,” [laugh] there’s lots of things that I’m taking from that, that I think would have strengthened us. But at the same time, we’ve had a journey to go on over the last year anyway, through sort of various factors, like I say, through the migrations and so on. But forming as a team, for example, we—like, as the transformation, a lot of people who had been colleagues before but not worked together had been put together in a new group.

And so, actually one of the things we did early on was, sort of, prioritizing trying to get that sense of team, [unintelligible 00:31:58] trying to sort of make changes or do some of the practical stuff, maybe because we wanted to have a sense of identity and feel that we were all in there together. So, I don’t have—there aren’t any, sort of, really big ones where it’s like, “Oh, I wish we hadn’t done that,” or, “We should have done this first,” or that kind of thing, but I think just the more that I’ve learned, the more I’m finding things that are helpful and can help us in our journey going forward.

I think maybe some of the ones around metrics and providing that clarity of, where are we now and what are we doing, maybe even just, like, really basic usage stats, if we can, and starting to say, okay, we’re just going to try and get the number of products down in some way, like, a more focused portfolio, the number of uses up and providing some of that role clarity to people, I think, would be helpful. And just trying to make it—make people’s priorities as clear as possible. I think one of the things around, as I said, that sort of very broad analyst role is that people haven’t quite known what the right thing is to focus on right now. And I think probably I would look to define that a bit more clearly upfront.

Brian: Thanks for sharing all this. This has been really great. I wanted to shift to an upcoming event. So, you became a member of the Data Product Leadership Community. You’re one of our founding members, actually, so I just wanted to, first of all, thank you for participating and screening new applicants.

Jonathan: Thank you for having me [laugh].

Brian: Yeah. No, it’s been really great. And you’re going to be our second… third. You’re going to be a third presenter, actually, in October 12th, 2023, if you’re listening to this now. So, you’re giving this talk; it’s called, “From Analytics to Insight Products Adopting Product Management.” I assume a fair amount of what we talked about—

Jonathan: Yeah.

Brian: Today will kind of be in there, but you’re going to probably go much deeper with the DPLC. Anything you want to share there about that, the webinar that’s coming up or just your participation so far in the DPLC?

Jonathan: Well, in terms of the webinar, I’m still thinking and planning what I’m going to share, but I think it’ll cover maybe some of the same ground, but more of the, sort of, practical bits and pieces potentially, and also just learning and looking to start a conversation. So, being part of the DPLC has been really good for me and I’m excited about the opportunity because there’s someone who’s growing in this space is, sort of, doing the data product leadership part of it, having a community of people to draw on for advice, see how other people are doing things, to bounce ideas off, and all of those, and build a network is really good. So, there’s a conference coming up in the UK next week and I’m reaching out to people from the community to sort of meet up in person and those kinds of things and just build those relationships. And I think sometimes, when you have the opportunity just in one-on-ones to talk to someone about, oh, this is what I’m doing, or that’s what I’m doing, so it can spark ideas really quickly, even without—you’re not having a deliberate conversation to say, “I’d like to talk to you about how you do role descriptions,” or something like that, but you just are, like, “Oh, I hadn’t thought of doing it that way,” or, “Yeah, tell me more about that.” So, that’s really good. So, I’m absolutely excited about that. And yeah, looking forward to sharing.

Brian: Cool. Yeah, I think you guys were the—UK was the first geo-specific channel in the Slack, so it’s nice to see that, like, there might be a first IRL, real-life meetup between some of the members. Because we’re all over the globe, so I was excited to see that some of you—I think John Cook’s go into that as well and you guys might meet up. So, send us a—put a photo in the Slack. We’ll look forward to seeing that. I just want to advise the listeners again, it’s October 12th, 2023.

These are all recorded as well, so you can check them out later if you choose to join at a later date or you’re getting this episode in 2027, listening to the back catalog.

Jonathan: Goodness.

Brian: So, Jonathan, where can people follow you? LinkedIn? Is that the best place or do you have a website? How can people get in touch?

Jonathan: No, LinkedIn is the best place—

Brian: Okay.

Jonathan: —to get me. Yeah.

Brian: Excellent. Excellent. Yeah, thank you for coming on and sharing your journey. And I just want to say, like, sharing work in progress is difficult and in this case, the work is the management of this team and all of that, and I really applaud you for coming on and just show us how your sausage is made. Like, a lot of times, that’s a really difficult thing to do and I really wanted to have people in the Data Product Leadership Community who are at different stages, and some are coming from design backgrounds, some come from PMs, we got our, you know, analysts and data scientists in there. So, it’s really interesting to always, kind of, hear the different approaches here because product is such the soup of, like—

Jonathan: Yeah.

Brian: Different domains and it’s fairly ambiguous sometimes. And so, I really applaud you for coming on and just sharing [us 00:36:19] kind of where you are in the journey right now.

Jonathan: Well, thanks for having me.

Brian: Yeah, yeah. Cool. Well, take care and until next time, thanks for listening and we’ll see you at the next one.