Episode 63: Aligning Product Organizations with Adrian Howard
Melissa Perri welcomes Adrian Howard to this episode of the Product Thinking Podcast. Adrian is an Agile Consultant and product coach with more than 25 years of experience, and specializes in coaching leaders around “those messy spaces where product delivery and user research overlap.” Adrian joins Melissa to talk about involving engineers in strategy building, the importance of meaningful strategy, aligning teams across large organizations with varying initiatives and goals, and why team vs team competition can lead to an organization’s downfall.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and Adrian talk about:
Adrian talks about his introduction to the agile and technical world. [1:58]
When incorporating other disciplines such as engineering into product strategy, you need to involve user research and customer support to gain better insight on how a product is developing. [3:30]
Before asking questions to your engineers as a product leader, make sure that they are on board and understand the company's strategy. "Your job as a leader is to help either provide that direction, or talk to the people in your organization to discover what directions they think is useful and find a way of prioritizing and aligning about that," Adrian says. [5:14]
Too many teams do not feel aligned with the goals of the company, or don’t feel like they have a piece of value that they can deliver on. [9:57]
Have conversations about value at the lower levels. Oftentimes these conversations happen at the top, and by the time those conversations reach the bottom level, they're more about effort and work rather than the outcomes. [14:23]
Orgs should stop pitting teams against each other, and instead treat their teams as groups collectively trying to deliver on a larger set of values. [20:30]
Adrian talks about the competition mindset being ingrained in some company cultures and how he's helped them move away from that. [23:26]
"Just asking for the rest of your team to solve a problem that you have pulled out of thin air isn't leadership of the C-suite…that is hoping to steal the credit from the people who are actually coming up with ideas and hoping they'll manage to solve your problem for you," Adrian remarks. [27:48]
Usability testing has to be done in tandem with user research to fix organizational gaps, and it also has to be actionable. [31:05]
Resources
Adrian Howard | LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to the product thinking podcast today. I'm joined by Adrian Howard, who is a long time friend and prolific coach in the agile space, working with all these different teams from product management, to UX, to engineering, to help them work better together. Welcome Adrian.
Adrian:
Hey Melissa, it's lovely to see you again.
Melissa:
It's great to see you too. Can you tell us a little bit about how you got into, uh, this agile world, this technical world?
Adrian:
Um, I started off as one of those sad kids with the microcomputer in the eighties. Um, so I was, I was doing development in the latter half of the last century, which is a wonderful thing you can say now. Um, I then kind of wandered into doing a little bit more of what we now call kind of user research and product work. And I got into agile, real heavy, real early, uh, which accidentally felt got me to fall into a little niche, um, around kind of where delivery work, product work and user research work overlap. Uh, and that's kind of what I'm doing now. Uh, I'm a coach who helps leaders in improve around that cross-disciplinary work, those messy spaces where, where product delivery and user research overlap.
Melissa:
That's really interesting. So one of the biggest issues that I've been seeing out there, um, in my work with product managers is around everybody collaborating to set strategy. Um, and before we popped a on this, uh, you know, this podcast, we were talking about this a little bit. One of the, like the issue that I see is there's product leaders who obviously are the, let's say responsible party for the implementation of the, the strategy, right? They're the lead on actually creating it. But we know from agile and from other things that we need UX design involved in that we know we need all the other disciplines involved in it, even marketing sales engineering. When do you involve the other disciplines, uh, like engineering or UX design in setting strategy and how should leaders really think about when and how to incorporate them?
Adrian:
Um, well I'm very much in the early and all the time camp. Um, my experience has been that the, the kind of ideas and, um, you want the ideas and input around strategy to be as, as wide as possible, um, to bring in the stuff that, that you don't know because your leader cannot know everything. Um, so bring in engineers early, bring in, um, user research early, bring in customer support early. Um, tho those, those people have stuff that they've been hearing over and over again, problems that they've been hitting over and over again. And not all of those are gonna be in your space. You are gonna hear about the, the fact that development have to deal with this huge monolithic service that goes down for, you know, a day a week or something like that. And they have, they have to invest all this time dealing with counter measures to it, and it's slowing down the overall delivery pipeline, which means that this cool new thing that you want the product to do to help deliver a new market is not gonna happen. And that stuff you need to know earlier later.
Melissa:
So, um, some product leaders that I've been working with, and sure you've seen this as well. Um, you know, a lot of the bigger companies who are going through an agile transformation, or even some of the smaller ones too, um, they have leaders who are not as technical, right? As some of the product managers who've come up through more of a technical space or from, you know, product management, working very closely with engineers. Um, and they struggle with how to incorporate, um, engineering into their strategy planning and also capacity planning. Man, I've heard capacity planning just like thrown around a lot as the bane of people's existence lately. So I was like, oh, we've reached that point where people care about capacity planning. Great. Um, so if you are a product manager, who's trying to figure out like how to work with either a CTO or an engineering lead, uh, what types of conversations should you be having with the engineers? And like, what's the questions to ask them when you're actually planning strategy? Like what information do you need from them to plan it correctly?
Adrian:
Um, I think the, the thing you need to do first before you start throwing questions at them is make sure they're actually, um, on board and understand what your, your strategy actually is and that you have one, um, that the, the two problems I see a lot are either the, um, there is a strategy inside the organization, but no one else inside of the organization knows about it. Um, and therefore the, the input that you get from different parts of the organization are misaligned to what you're actually trying to do. It's like we had a, um, work with a client who was, um, building a new platform sort of thing. And one part of the technical organization thought this was basically a, a kind of a technical spike to see if we could do this complicated technical thing that no other organization had successfully. They were not expecting us to make a bunch of money.
They were expecting to find out whether this thing was possible or not. You know, um, another group of, a bit of the organization on the business side thought that this would be delivering many million dollars by the end of Q4 next year. Um, and because no one had actually written down that strategy and communicated it in a thorough way and had those conversations with different groups to, to talk about, okay, what do you think's gonna be happening in a year's time, um, from this, uh, they were trying to deliver on very different expectations. Um, so, um, just having a strategy and talking about it is, is the first step. And the second step is making sure that strategy is meaningful. Um, and I, I know you've, you've had rants about this before, but, um, those, those strategies, which are kind of, we are gonna have more customers, or we are gonna have more money, you know, well, tho those are good and, and nice things for a company, but they, they don't really give much direction to what the organization should be doing.
Um, that's is, is to help either provide that direction or talk to the people in your organization to discover what directions they think is useful and finding a way of prioritizing and aligning about that. Um, once those things are in place, then you can start talking, um, on the technical side to people about coming here, what are, what are, what are the blockers here? What's, what are they, um, what are people doing right now? That's, that's a thing that I'm surprised, the, the number of, of product leaders who don't understand what teams are doing at this moment in time, um, where the resources are being spent, uh, how much of those resources are actually, um, aligned with what the comp, what the team should be doing. You know, you, you see a team that that's labeled kind of, you know, customer support and they're, and they're nominally kind of managing the, the pipeline of customer requests, dealing with that and what they're actually doing.
And that is managing a metrics, shed load of, um, metrics management or analytics gathering that is necessary to some other bit of the organization. And that's been, they've been doing that for the last six months because somebody had to do it and they were the team without any, you know, a good spare space in that particular moment. So there's a lot of stuff that's kind of hidden, um, behind the, the default labels, um, around teams. Uh, so having, having those conversations about, okay, who's, who's doing what, where is the time being spent? Um, how many people are involved in that, uh, and making sure that those numbers are actually aligned with what you think the organizational strategy is. And if it isn't, then one of two things has gotta change what deal either gotta change where you are, where you are spending, the time that your people are, are putting effort in, or you've gotta change what your strategy is. Uh, and that conversation is the conversation you need to be having with engineering leadership at that point is like, what's, what's wrong here is, is, is our, as the way we're spending our time wrong, or is the idea about where we can go, does that need to change? Um, and listening to that feedback is, is, is the, the bit where you need to be trusting your, have built trust with your engineer team, that they, they can tell truth to power at that point.
Melissa:
Oh man. Yeah. I see that all over the place where people just don't know what their teams are actually working on. And then you find out they're working on like 8,000 different initiatives that don't ladder up to a comic goal at all. So when yeah, right. It's, it's, uh, it's kind of mind blowing, but I understand when the teams get super large, sometimes it's really hard to keep track of what is everybody doing and how do we stay aligned with that when you go into organizations and you're trying to help leaders understand, like, what's the work in progress, what types of tools, or like methods do you use to go out there and like audit the work, especially if you've got like tons and tons of teams.
Adrian:
Um, that's a really good and hard question. Um, I'll give the, the favorite consultant answer of it depends. Um, the, I try and listen first to, to, and discover where the biggest pain points are. Um, they're usually around alignment in one way or another. Um, for example, we worked, um, that old guy talked about before, when they had one group wanting to do the technical spike and, and another thinking was going made lots of money sort of thing. Um, the thing that surfaced that was getting, um, you know, the leadership group in a room and talking about what the world would look like in, uh, a year's time, if this project, uh, or this kind of replatforming product, whether this replatforming project was successful or not, you know, and there was one group was giving, um, results around, you know, lots of money in the bank, or if it went horribly wrong, uh, you know, no money in the bank.
And, you know, we, we've spent a lot of, uh, pointless time marketing this new feature, and everybody hates this sort of thing. And another group was saying things like we'll know if this really complicated data managing process, uh, can actually deliver results that, that map onto success. And these mapped onto success numbers will depend on some stuff happening in the world. So that's gonna take three months to figure out whether that stuff happens in the world. So we're not gonna know this until like four months down and like, how do we know how much, you know, money to invest now and time to invest now? And what's, you know, there was a lot of uncertainty about what success would look like and like, how, how good does this counted as a success? Uh, and when you have those radically different results, um, in a room at the same time, uh, then everybody can look at, okay, we've, we've got like 14 different things that this strategy you're supposed to be delivering, and they seem kind of opposite in places.
Um, that's, that's a hugely valued just, just to surface the, the alignment problem that's happening there. And once you have surfaced that alignment problem, then you can start digging into, um, why that happened. Um, you can look at, um, the org chart and, and see how maps onto the, and the delivery work that's being happening on the product work that's being happening. Um, you can look at, uh, you know, the JIRA or the, whatever, the, the, the work monitoring system in and see, okay, how the team's broken up. How are, how is the value talked about where does this stuff come into the, the work more process monitoring system from where does success get measured after stuff gets delivered? Is, is that in there, or is that in a separate pipeline? What are the incentives for the different teams, um, who gets the reward and for what, you know, what counts as this, what counts as success for a, for a project?
And this is something that, where things fall over so much for, for large initiatives that involve multiple teams, is the fact that, um, no one team has a little slice of value that they can actually deliver on. Like everybody is expected to deliver all the thing and all the thing will then magically deliver value to the organization. Uh, and that's, that kind of, um, breakdown of work means that it's really easy to go kind of, um, Hey, we're, we are successful and, and we fail because other team didn't do a thing. Uh, and then it becomes a fight, um, amongst the organization around who is successful or not. And rather than, um, a conversation about, are we building a successful product?
Melissa:
That's a really good point. Um, I've seen a lot of teams, especially ones. Um, you know, when I was working in healthcare, for instance, we'd have these big initiatives where we need the integrations team, which, you know, was under a different VP product, um, to work with a team that was in clinicals, right. To work with the team that was in billing, cuz everything didn't work unless it passed all the information to each other. Um, and there was always these fights about like, well, did I own that? Or how can I like align that with my roadmap and where do we go after this? Which a lot stemmed from not having a super clear strategy at the top and we fixed that, but then it got down to what you're talking about, where it's like, Hey, if I just deliver my little piece for integrations, it's not the full value of this whole initiative that we're going after. How do you, what do you do to recommend to companies, um, how to like make that work, like how to set success so that people all feel like they're contributing to it. So it's not just finger pointing and, and what types of things do we do to like get around that initiative, break it down and make sure we're all working towards it.
Adrian:
Um, All the easy questions. It's trying to shift for me that, uh, some companies have a lot of conversation about, um, value at the top. You know, they'll, they'll talk about, we want, we want more money or we want, uh, a new market or we want more customers. Um, or we are going to deliver this kind of set of functionality. It's gonna, um, be valuable to our customers. So they they're gonna like us. And by the time it gets to the bottom of the organization, the conversation is all around, um, effort and work rather than the outcomes that we are trying to deliver and the value that we are trying to deliver. Um, and moving that value conversation down into the lower levels of the organization is, is the time where you can, um, start helping those teams have a conversation about value earlier and understand that if they, um, deliver something that works, but doesn't work with the rest of the org, then you know that they've not delivered something, something valuable and, and effective and helpful to the organization.
Um, for example, we had a, um, a team that was, um, working on kind of, um, the authentication I ever want of a better term of, of a, of a large project. And they were doing lots of complicated stuff to deal with, um, different kinds of customer having access to, to certain bits of data and certain bits of functionality, depending on their, their layer and their region and various legal permissions that had to be ticked off. Um, so there was, there was a, there was a very, kind of, a lot of complicated logic you there and, and all of it in theory, you know, had to be done. And that's the way that they were thinking about it. We've got this big chunk of work, we've cut it up into little bits and we're gonna deliver all the stuff to allow this great layer of functionality.
They were doing lots of big upfront architectural design to make sure I could cope with all of this functionality and they didn't finish. Um, they didn't finish in time, which meant none of this worked, um, even the simplest case didn't work, you know, the simplest case, letting someone log didn't work, cuz that was easy, you know, so that they'd kind of put off the easy thing to do later while they complicate concentrated on the hard stuff. Um, and that meant there was no way in the entire system because no one could log on yet someone had to do this emergency last minute project hack just to let the, the easiest case of our customers login and use the, the preset set of kind of features and data, um, that we knew that they could use in this particular region with this particular set of permissions.
Um, this was something that tin could have done in literally the first week, you know, first two, two weeks, certainly of the project they could have had this out there shipped, working and other teams could have been using that functionality. And because no one was sitting there in product overlooking that and going what's what value can we deliver early? Um, how do we deliver this value early those conversations with the developers of going, yes, we need this complicated authentication logic way of describing things. So we can flip things for different regions of products, but let's, let's deal with these dudes in the states who have this simple use case first, you know, how much does that take? And that's like a, you know, we can do that in a week. We can just, hardcode the that's fine. Um, that's, that's the conversation that was missing right across the org organization, um, that, that they had, um, they had sold the, the complete system as it were not even to customers, but inside their own heads. Um, that was, that was the thing that needed to be delivered.
Melissa:
How did like, uh, why wasn't their product management over it? What, what was preventing them from looking at that? Did they just not have the right people? Was somebody not dedicated to it? Was there two product managers like over the two separate things?
Adrian:
Yes. Um, all, all of the above, a lot of it I think was around incentives and, and the way things were being tracked. Um, the, the way that the work was being conceptualized was, um, you know, things were broken down functionally rather than around the value that was being delivered or around the customer's journey or experience. So there was like the authentication bit, that was the data services bit. That was like the, the front end UI bit.
Melissa:
My favorite way to organize teams.
Adrian:
Oh, absolutely the most useful way to break and work. Um, and those people were, were fundamentally when you looked at the way, the organizations running status updates and, um, the way that they were, uh, checking from information, it was like, have you what's, what's, what's our end progress to our six month goal on delivering all the stuff, um, rather than have any of our customers use the BT yet, or, you know, are any of our customers seeing value in the work? Um, or, you know, do our customers, even, even like this as a thing, have we found that out yet, there was one team, um, that was, um, and this was kind of horrifying. I mean, it was good. It was good in the sense that they realized they needed to validate the work that they were doing with their customers. Um, so they had a stream of work that they were doing, where they were going out and talking to customers, um, on a, not as often as they should be, but at least they were doing it. They were doing it at the same time as they were building the thing. Um, so it was like, kind of, you know, and this was a question we asked, it was like, what hap, what happens if the customers say, no,
Melissa:
Yeah. Do you stop building it? Do you like go back and just say, oh, you know, or do we keep going? I find so many people do that. They like do the research while they're already building it, but about the stuff they've already started building, and then they don't wanna like kill it.
Adrian:
Yeah. But the status updates were the interesting things when you, you stood. And, and, and when I sat in on those as an observer, you, you saw that the, um, and they didn't have the product manager title, but that was kind of the work that they were supposed to be doing, but they, they were presenting almost as competitors in that context. You know, it's like in the sense of like, I I've, you know, my team's been successful and we've, we've done all these, all these stories and we've made so much progress on the entire our thing. Um, and you know, I, unlike Mary who's like two stories behind where she said, she'd be at this point, you know? Um, and there was, you know, the management were kind of playing the, the, the product ownership group across, against each other, rather than treating them as group that was trying to deliver on a, a larger set of value, which was depressing. But yeah, something we had had a conversation around what, what the incentives and what the, um, and again, that's the incentives, the rewards, the, the bonuses were all around kind know, delivering to expectation rather than, um, customers like our product.
Melissa:
I have seen that before in so many places and that like, toxic, I don't understand that though. Like how do you build a company and pit all the teams against each other when you're all trying to achieve the same goals like that, to me makes absolutely no sense if you're trying to be like a leader of a company and, you know, achieve all of these things that you've set out, promise to your board, promise to your customers or whatever, like why, why turn it into a competition?
Adrian:
And I think it, it, it also sets you up for failure in, in various different ways. I mean, first of all, um, you know, people are incentivized to, or I used that word. I hate that word. I'm sorry. Um, people are encouraged as it were by those incentives to, to lie, to some extent, to it, to present better than things actually are to, to hide the truth from you because, um, you know, their bonuses, their, their organizational success, their team's success, um, all, all ride on them, doing the things that were promised up front and two that, that hides vital into from you because, um, the work that the organization does should be an expression of the organizational strategy, um, that that's what should be happening. And the thing you really want to hear as soon as possible is whether that's actually working or not.
Um, and when organizations frame stuff, that way, people are trying to actively hide that information from you. And the, the way that praise and punishment is rooted in that kind of organization, it becomes the, the teams fault rather than for, for not doing the thing rather than the organization's fault for the strategy not being right. Um, and getting those two things confused is just a fatal error. Um, you see, because then it's like doubled out we'll, we'll like throw you are not delivering fast enough. We'll, you know, throw more resources at it, fire you and get a contractor in, or we'll, you know, we'll outsource this to, to make, you know, to, to deliver this thing on time. Uh, not understanding that, that what the feedback is actually telling you is, is that market doesn't want this thing, customs, don't like this thing, um, you've misunderstood. What value people want out of this thing? Um, they, when organizations are set up that way, they, they, they hear, they either don't hear the feedback and when they do hear the feedback, they hear it wrong.
Melissa:
Yeah. That's so fascinating. The, and it's so prolific out there, I just see it so many places. How were you able to overcome that there and change it? Or was it ingrained to the culture? I'm, I'm always torn. I'm like, is this a, is it a fixable problem? Do, do people, can people get over it? Can companies get over that?
Adrian:
Um, I think it's hard for companies to get over it. It really is. Um, things that helped were, um, hiring. First of all, um, just, just hiring in people, you had more experience of successfully doing this kind of, of product work and having those conversations, um, with the C-suite, um, that was hugely valuable just because it was a, um, both because that person had a bunch of really useful knowledge and, and information, uh, to help the organization change. And because once you get to that point, that there is that, you know, company has kind of said, stuff's not quite working as we want it to, this is why we're doing this thing with this person. Um, and that person then is because of that is, is given a little bit more Rema to, to, to mix some stuff up, uh, and change things. And that's, um, bringing in the, bringing in the skills and having permission for those skills to work is, is the, the place that it needs to get to. And just looking at the incentives, I think is often the, the, the biggest thing. What do you, or what language do you use when you, when you are talking about, um, the, the status reports and updates, what, you know, do you, do you tell people off, you know, and, and how do you stop that happening? And, and, you know, having that hard conversation sometimes about kind of, you know, this person always does this thing, is this good for your organization? You know, um,
Melissa:
Yeah. Those some like really, really good suggestions on it. I'm curious, too, you mentioned before that the person who was kind of doing the product management stuff didn't really have a product manager title. Um, did you see that as an issue or was it, it was just bigger than that. Didn't really matter.
Adrian:
I think it's bigger than that for me. Um, I think there's like, I've seen, like in this particular organization had the product owner job title, um, and the problem wasn't the job title. The problem was the fact that a jump of the people in this organization were not doing good product management and were seated in a place where they functionally could not do good product management. You could hire the best product manager in the world, uh, into, to head up one of those teams. And they would either be doing the same things or have just like resigned in a huff, after a few months, because there was no space in the organization for them to do the good work. Um, the, what had to change first is things like, okay, we're gonna stop tracking stories now, you know, this, this isn't useful number, or in fact, you know, and okay.
They still want to see the stories. Okay, we're gonna put the stories to the end of deck, you know, and we're gonna talk about value first. Uh, and that's, that's a pattern I found really useful with where, when I'm, when the people who I'm working with a kind of middle of the organization, rather than top of the organization, is start working with your peers, uh, and working in, in the work you communicate up about the stuff that, that, that is important first, you know? So, um, when there isn't a strategy that, that they, that they understand just write down the strategy that they think is happening, you know, because that's the thing that will then help them go, you know, kind of the C-suite leader go, yeah, that's that strategy now you've got it right. Or they'll, or they'll tell you no, that you haven't got it right.
And then you can have a conversation about it. Um, rather than were delivering, you know, so many stories and with this far down our, you know, our product backlog or our sprint backlog, whatever it is, um, you know, rather than talking about the flow of stories through, through the work start talking about, you know, and this is what the product can do now, and this is what we've seen from our customers. Uh, this is the change that we are in the future. Um, having those conversations earlier in the deck, rather than later in the deck or whatever that they're using to communicate with management, whether it's like the slack channel or the, you know, the status update deck, or the kind of the little chat in a room, uh, start talking about the, the things that you care about first and things that are less important last, um, and that just gives more time for the important stuff in that conversation. And it helps you, and hopefully the people above you in the organization see the impact, um, of the, the more value of stuff first.
Melissa:
Yeah. What happens too, when you do at, into that situation where you're communicating, you know, Hey, this is what we think that we should be doing. And leadership's like, Nope, that's definitely not what you should be doing. And they decide that they need to change strategic direction. Right. And, and kind of focus on, um, you know, new things. Uh, I've seen like a lot of friction emerge from that. Mm. Um, have you seen that as well? And like, how do you, how do you navigate a strategic shift like that? Well, especially across all the disciplines, right? It's not just product changing. It's also engineering, changing what they're doing and UX design, like what are things that leaders need to keep in mind for that?
Adrian:
Um, I think this could be very dependent on where you are in the organization, cuz leaders, leaders sit at many different levels. Um, I think the, a failure mode I see at the C-suite level is, um,
Very little direction beyond markets and money. Um, you know, they, they know they want more, more people using their product. They know they want more cash and they kind of hoping that some one else in the organization will have the, you know, if we give them this goal, someone else will figure out how to do that thing. Um, and there needs to be more direction than that. Just a little bit more, you know, about the areas that the, the, the company is, is paying to move into. Is it, is it changing market? Is it changing business model? Um, just asking for the rest of the org to, to solve, to solve a problem that you've pulled out of thin air, um, isn't isn't leadership at the C-suite level, um, that that is, um,
Hoping to, to steal the credit from the people who are actually coming up with ideas in you hoping they'll manage to solve your problem for you. Um, so I think that that's a gap I see in some organizations that, that, that, that, that the people right at the top don't don't have that product knowledge. They don't have the CPO, they don't have the, um, enough contact time with, with customers. They don't have that kind of in, and, and use a research side or the people they have in that product role has a, has a, a focus on subset of that. Like the product skillset, you know, someone who's very custom focused, but not very market focused or the opposite. Um, so there, there isn't balance there. Um, so that's, that's, that's a hiring and a skill thing at this at the c-suite level. And that's really hard to fix unless people are willing to see that gap.
Um, once that's fixed it, it is just talking to people around what that big organizational vision is, making sure it's communicated, aligned, and everyone agrees on that. And then you can start talking about the, the different bits of information, the different blockers in different parts of the organization, the things that need to happen to fix that. And that's when you gather the ideas where you actually have a, a strategic direction that people can align around. Um, for example, we, what the client had had a, to people, a solid customer satisfaction problem. Um, people have been using the product for a while. Um, for a while, it was the kind of the only product in the space for this particular niche. Um, um, and it kind of sucked to use. It really did. Um, people were complaining about this on multiple levels. There, there were like UX issues.
They were is the damn site online issues. Um, there were customer support issues, um, whole lot of stuff. So, you know, and they could see the, the C-suite were okay. They were good. They could see that this was a problem for them. And they could see that competitors were eating their lunch when it came to, um, user experience and they were stealing, stealing their customers from underneath them. So they had it like, this is, this is what we're gonna be doing for the next six months. We're gonna be focusing on moving our customer satisfaction, numbers up, um, dealing with the, they have various metrics to look at that way. Um, and as that drop down in New York, you saw different things coming back up, back up out of the teams you saw engineering talking about. There are these reliability issues around tech debt that we've been kind of ignoring because you've been like hitting us on the head to deliver more features like, you know, this is the time where we fix those things to make this, you know, to make the up time go up, which we think will help the customer satisfaction get better.
According to these metrics that you care about. Um, when we went off to talk to, um, user research design and some other kind of the front end folk, there was a lot of, um, conflict, that sort of thing, because the usability folk had been going for ages, well, we do this usability testing, and we tell you all the many, numerous hundreds of ways that our product deeply sucks. Uh, and then you never fix it. Uh, and the dev side were more going kind of you. Yes, yes. You keep telling us the product sucks, but you know, we have to ship this thing in two weeks when you tell us, so like too late, then, you know, as there's, you know, you give us UN actionable work and getting those groups together, having a conversation about, okay, the, the organization always make customer satisfaction get better.
How do we make this work more effectively? Um, kind of, oh, like user research is obviously something we need to get better at. So, um, the, the usability testing is something that needs to be actionable. So that became a goal for those two groups was that the, you know, there would be, uh, and I can't remember exactly how they phrased it, but it was something like kind of their, you know, usability, usability testing will result in actionable improvements to the product, something like that. And they had some metrics around that, around the, the number of P one issues that would be, um, discovered before the product launched the number of, um, the number of P one issues discovered post delivery as it were, uh, they wanted to increase the cadence of usability testing. Uh, they wanted to do usability testing earlier in the product development cycle, so they could catch problems before they became big problems.
Uh, and that, you know, didn't universally work. Some of those numbers didn't come quite as they wanted to having that strategic direction and having that conversation, um, about this is what we want. The, you know, customer satisfaction is our big thing. This is a conflict inside the organization. That's affecting that. How do we improve that, um, was coming from user research that was coming from, from 10 dev. Uh, they, they could have a conversation together to figure that out and present a, this is what we're gonna try and do to help you with the customer satisfaction problem, um, to the, the layer above that. And that worked really nicely.
Melissa:
Fantastic. Sounds like really good advice too, for a lot of product leaders or a lot of organizational leaders out there. And I'm sure if people are struggling, this could be something that you could help them with too.
Adrian:
Um, I would hope so. Um, we do, uh, these days, I'm mostly doing one on coaching with, with, um, leaders. Sometimes that's, that's, that's in product. Sometimes that's in user research, sometimes that's in dev. Um, and it's the, the time we spend is, is mostly about conversations around the, the cross-disciplinary problems they hit. And that's usually the ones they hit when they're kind of leveling up a little bit in the organization. Um, when they're going from being the, the IC to being the team lead, when they're going from the, the team lead to the director or the VP, um, it's the time when people are changing the work that they do when they're moving, like, um, the product person has previously had this focus and, and there's been like pointing all their product skillset at, at the, the product that is being delivered and they, the end users and customers of that product, and they then need to kind of move that skillset set and point it at the product org, uh, and helping make that product organization better. Um, that's the kind of space I play. Yeah.
Melissa:
Great. So if, uh, people wanna get in touch with you, Adrian, uh, where can they learn more about you about your work and, uh, reach out?
Adrian:
Um, the, my work stuff is on Qstars.com, uh, where you can sign up to our awesome free newsletter, which will eventually start going out again. 2021. It was an interesting year, um, as my personal writings up at Adrianhoward.com. And if you want to know when I'm drinking coffee, you can find me as @AdrianH on the Twitter.
Melissa:
Great. Uh, thank you so much for being here today. Adrian, it's been great talking to you, uh, and for those of you listening, if you'd like to, uh, hear more about, uh, you know, Adrian, please check that out. And if you'd like to listen to more episodes of the product thinking podcast, make sure you hit subscribe wherever you're listening to this podcast. We're on all the platforms and stay tuned for another episode next Wednesday,
Adrian:
Absolutely, lovely talking to you.