Curious about the illusions and realities of corporate culture? In this week's episode, we chat with Keiji Adedeji, an experienced product leadership coach with deep insights into the world of product management. Keiji shares her fascinating journey from software tester to product manager, driven by a relentless curiosity and a knack for problem-solving. With over 18 years in tech and extensive experience in B2B sectors, including her recent work with the International Baccalaureate Organization, Keiji brings to light the humorous and perplexing behaviors of large companies and the illusion of control that often drives their decisions.
Chapters
Featured Links: Follow Keji on LinkedIn | Watch Keji's talk at #mtpcon 2023 | The Spotify Squad Model
Episode transcript
Lily Smith: 0:00
Hello and welcome to the Product Experience. This week, randy and I caught up with Keiji Adedeji. She's a product leadership coach and consultant and we talked all about the annoying things that companies do and why they do them. Happy New Year. The Product Experience podcast is brought to you by Mind, the Product part of the Pendo family. Every week we talk to inspiring product people from around the globe.
Randy Silver: 1:01
Keiji, thank you so much for joining us today. How are you doing?
Keji Adedeji: 1:05
I'm great thank you. Nice to see you, randy, and nice to see you, lily.
Randy Silver: 1:09
So we've known you for years. We've been trying to get you to come on for years. It's great to finally have you, but for people who don't know you already, can you just give us a quick intro? How did you get into product in the first place and what kind of stuff do you do these days?
Keji Adedeji: 1:25
How did you get into product in the first place, and what kind of stuff do you do these days? Okay, sure, I'm KJ Adedeji. I've been a product person for gosh about 13 years now, but I've probably worked in tech for about 18 years. My route into products is probably not that dissimilar to a lot of people I think certainly our generation's route into products. I wore pretty much every other hat you could wear in a tech organization.
I started off as a software tester. I did that for a while and then I was like I'm bored of this, I need more, and so I asked the company I was working for to give me more and they said, okay, you can go off and be a software tester in this team, but in this team you get to wear lots of other hats. So I did business analysis, project management, implementation. I used to go on site and train the customers, I used to go out and grab the requirements and all of that. And then I realized the thing I really thought I might be interested in doing is a thing that the developer who started the team was doing. So he pitched the idea to business. They gave him a bunch of money and said set up a team and go make that thing become reality. So he had the problem to solve. He went off and figured out if it was really a problem, if customers had a problem to solve, if it was going to be valuable, and then he put a team together and then we built that product, et cetera.
I was like I want to do what he does, except the coding bit, and I think I might have actually Googled it. I think they gave me the job title of product consultant at the time, which didn't mean anything, and so I was like what's a product consultant? And then they were like Google was like it's a product manager, and so that's how I discovered product management and decided that's what I was going to go off and do. And I've been doing it ever since. So I've worked in primarily B2B companies. I spent a lot of my time in ed tech for a company called Talis. Two times around. I've worked at big organizations, small organizations. I've worked at National Express. My last stint was at FT, but I've also worked in small, startup and scale up environments and currently I'm doing a little bit of product consulting with the International Baccalaureate Organization, and that's me.
Randy Silver: 3:24
Fantastic. So with all of that experience, having seen lots of different things, you've got war stories, you've seen some absolutely insane things that companies have done, and we were talking early and realized that there's a common element to some of this craziness why are big companies stupid? That's probably.
Keji Adedeji: 3:50
Well, I think you've probably said it a bit more diplomatically than I said it when we were talking about it earlier.
You can say it your way, it's okay, I can say it my way. So when we were talking about what I was going to talk about and I didn't really have a topic per se, but I then shared a document I had started many years ago that was titled the bat-chick, cray-cray things that big companies do, and had a set of examples in there, and really ultimately, underneath all the things on that list was, for me, I think, the illusion of control that companies have. That ultimately boils down to a lack of trust permeating through the organization in various ways, either through the culture or either through the need to control outcomes but kind of not really having a language for outcomes.
Randy Silver: 4:40
It sometimes can come from failures and then an organization becomes afraid of failure and therefore kind of locks down on trust and control and therefore craziness abounds in many ways we need to get into the serious side of this, but when you introduce it as the batshit cray-cray things that companies do, please give us an example before we go into the serious stuff companies do.
Keji Adedeji: 5:06
Please give us an example before we go into the serious stuff. Okay, one of my favorite examples of this is, um, I was working with a team and they'd uh, as often many teams have done, they've, they've come across spotify's squad model. They're like this is great, we're going to adopt this without really getting it. And so they'd adopted spotify squads and they were doing a good job of kind of their transformation, but, um, with with a lot to learn. And and they were doing a good job of kind of their transformation, but with a lot to learn. And so they were doing agile and all the teams were working in an agile way. They had a Kanban board and it was all on the wall so everyone could see. And so when a developer finishes a story, they'd get up and they'd go and move a piece of card from this stage to that stage, and that's the way it was done. And then they tell a project manager that that had happened, and then the project manager would move it on Chira, yeah, and I was like hold up, hang on a minute. What's going on here? Oh, no, no, that's the way we have to do it, because the project managers are the ones who make sure that everything is showing in the right stage and the right status and so kind of. If anyone's doing the reporting, it's all right. We're not allowed to move the Jira cards. I was just like I don't understand. So I went to talk to the project manager. Why is this happening? Well, we've got to do a bunch of reporting on this and sometimes people you know developers do the thing but they forget to move it. I'm like, but they could forget to move it on the physical board. Like I don't really understand, but no one could really get to the answer for this.
So I went around the houses just trying to help people see that this was, you know, batshit cray-cray, and couldn't quite get the message across. And in the end the way that I got the message across was you know, these developers are building software, solving customer problems with you, the team and they. You trust them to hit ship right at some point. They're done with that software, they finish that software. Everyone's like yep, it solves the problem. And then you trust them to hit ship now if anything goes wrong with that, we literally can see the money, not like the money failing. If they fuck that up, no money's happening. We will literally see that happening.
So if you can trust them to do that, how can you not trust them to move a jira card on a jira board and you force them to stand up and move it on a physical board and then tell another human who will then move it on a jira board. Can you not see how A crazy that is? And B how demoralizing that is and how that breeds a lack of trust in a team? So that's just one example of kind of what I thought was just a crazy crazy thing to be happening. But somewhere underneath that, you know, you have to kind of like really try and delve into like what's really going on underneath this thing. Why are we so afraid that something won't be updated? What's the real impact of that?
And in the end it comes down to the fact that there's a bunch of reporting that happens regularly by the PMOs, the project managers. They have to do this reporting to help kind of the higher-ups understand what the status of things are. And I think somewhere along the line they've been burnt in the past because something was reported wrong or someone hasn't had the information they needed or and so they locked everything down. Nigeria was locked down for the people who were actually working with doing the work, and so it's kind of unpicking why that was a problem and and helping people kind of realize that it's okay if, like, we get an update wrong. What's more important is we ship the right thing and then we trust our people and we we kind of give them that trust and allow them to get on with their job rather than fearing for, you know, forgetting things wrong. Again. It's that kind of fear of failure, that fear of trust, that kind of is seeping in there Underneath. A crazy thing like that is always going to be a real reason why humans are afraid of something.
Lily Smith: 8:50
So it's going to be something that's happened in the past, right, I think the other thing that is really striking about that story is well, there's a few things the you know the the fact that they are reporting on the tickets being moved on the board exactly, you know. That's another level, like you say, of lack of trust, or like someone is not convinced that the team are being productive, obviously, and they want to know what tickets are being moved across the board on a daily basis so that they can measure that and probably use it as a productivity measure or something like that.
Keji Adedeji: 9:19
Yeah, exactly exactly
Lily Smith: 9:20
yeah, again, very sort of controlling and very if that means that we're making progress, not looking at the out. You know the outcome, yeah, the outcome exactly.
Keji Adedeji: 9:32
It's like all of the cards could be in the right place and you're reporting, fine, but they ship that thing and the website broke and therefore we lost millions in a day. What's more important at the end of the day?
Lily Smith: 9:44
The thing that I find just so funny about that story is I remember as well having boards up on walls in offices and, you know, doing the physical movement of like moving something from one sort of status to the next. But I just can't imagine working there. Surely there's no one working like that now. Everyone must be working virtually, surely.
Keji Adedeji:10:08
Yeah, I think, certainly since the pandemic with teams becoming, I know there is definitely a movement to kind of let's all go back to the office, but I think most teams are probably some form of hybrid now. So, yeah, surely physical boards are a thing of the past. I can't imagine that that team still got a physical physical board. I'd be really interested to know if, uh, or like, that organization's still doing that so what's another?
Lily Smith: 10:32
another one of your examples of uh the crazy big organizations.
Keji Adedeji:10:38
I mean, I've got a bit of of a frivolous one. That isn't uh, I'm not, I don't really, I'm not really sure that I have an explanation for it, but, um, I found this one quite funny and this is the one about the fish, the fish story.
The fish story so when, when working for a transportation company once upon a time, their business development team was tasked with, uh, finding alternative sources of revenue beyond you know kind of the transport, and so they were doing a lot of partnerships, so I think they were doing a good job for the most part. They were doing lots of partnerships with other transportation companies and kind of online partners who would help to surface their tickets in searches for various types of transportation, eg trainlinecom, that kind of thing. But then I learned this story that they basically partnered with a fish company to be a partial distributor for them, so they'd be transporting fish in the coach carriages where people's uh, people's suitcases etc would be. I just found that really, really baffling. Like, at the end of the day, how much revenue really was that generating? And is it really on brand? Is it really the goal and the focus of what this company is trying to do, which is make transportation easier and more accessible for hundreds of people I'd need to translate this one to american.
So in the the luggage compartment of buses, of long haul buses, they were transporting fish next to suitcases.
As an alternative source of revenue and I just found that really insane. And obviously there was a clear goal there and you know, having seen some of the other things the team did, they understood the goal. But what happens where we you know that particular choice was made, what were the controls that were not in place? So talked about kind of a lack of trust existing in companies. But sometimes we do need to have guardrails in place. When we give our teams goals and we set our strategy and we set them goals, we do need to kind of put some guardrails around that kind of what are we and what are we not, because otherwise you get things like we're transporting fish in haw carriage.
Lily Smith: 12:45
I mean, I kind of think it's genius.
Keji Adedeji: 12:50
Yeah, you're right, is it? Is it genius or is it folly? I actually don't know. I just found it hilarious, yeah.
Randy Silver: 12:58
So, if we're going to root cause and as well, what caused this, this is where the metric becomes the target Right. It has nothing to do with with actual is this the right thing to do? What caused this? This is where the metric becomes the target right. It's has nothing to do with with actual. Is this the right thing to do? It's just more partnerships, and revenue from partnerships is the only goal.
Keji Adedeji: 13:15
Yeah exactly.
Lily Smith: 13:16
Yeah, and not necessarily like you say, on brand, on mission, maybe On mission.
Keji Adedeji: 13:22
You know it's revenue at all costs and we kind of forget about what is our brand, what is our mission, what is actually our strategy, because I'm sure the strategy didn't mean that. So how do we, when we do set strategy for our teams, how do we set the appropriate guardrails for them? So I've always liked the kind of even over approach to certain principles. So you know, we'll choose this, even over, this kind of thing. Instead, we'll do this, but not at the expense of this. So having that kind of conversation in teams when we're talking about our strategy helps our teams to go okay. This is the goal.
Lily Smith: 13:57
But we know that there are boundaries within which we can operate as well yeah, it makes a lot of sense and I think probably a lot of examples of that in in probably less extreme ways of sales people just going off the rails and just selling whatever they think they can get away with selling um and then coming back this isn't going. I've sold this quick. We need to build it, or you know we need to fulfill this or whatever.
Keji Adedeji: 14:26
So yeah, and it's it's not, you know, this isn't just a domain of of big companies and large organizations. I've worked in small founder-led organizations where there is a strategy or you know, know the beginnings of a strategy, and then the next shiny new bid comes along, or the next customer, who is really big and is really kicking up a fuss, is like, oh, but we would really like to do this thing, and so you find that the organization starts to stray away from the thing we said is our area of focus to the shiny new bid that we should go for, or this big thing that this, this particular customer is going to pay us a lot for, but in the end it's kind of like it's going to cost us in the long run because it's it's moving us away from our strategy. We're trying to build a SaaS solution, but right now we're operating more like an agency and you know it's not. I don't think that it's the domain of purely large organizations where you start to see that kind of strain away from what is the core of what we're trying to achieve. So kind of shiny thing here, that kind of doesn't really fit with what we do at all. Nice, shiny fish.
Randy Silver: 15:31
Keiji. One of your other examples goes in the other direction of this. As you said, we can have the conversation about this over this, and one of the ways we do that, sometimes formally, is through checklists and forms and things like that. But those can also go very, very wrong, are?
Keji Adedeji: 15:50
Are you talking about the, the document that had like 61 pages. Is that the one?
Randy Silver: 15:54
I'm sorry not only 61 pages. You said it had seven sections, but tell us about the last two sections.
Keji Adedeji: 16:02
Yes, so basically, sorry, I'm trying to find my notes on it. Yeah, so there was a 61 page solution specification document. It had seven sections in it. The sixth section and the seventh section fit at the bottom of the 61st page right, and those sections were the success criteria section and the handover to service section 61 pages and they spent less than half a page on what the success criteria was and, oh sorry, actually didn't have anything in it. I'm just reading my notes on that. It had nothing in it and the handover to service section had three bullet points in a solution specification document. And so you know, I've been in these companies where they have the fatigue of running projects that have failed multiple times and then they put in processes. You know, we'll do these retros of why is this thing failed? Why have we gone so over budget? Why is it just? Why have we just had to write it off completely? We'll do these retros and then we'll put in like new processes and there'll be new forms to fill in and all that I'm like. But let's go back to the fact that we we did specify this. We spent 61 pages specifying this and we didn't even put anything in the success criteria and we had three bullets for how we handed that over into into, kind of into the business.
This is the root cause. And why is that not being? You know why does that repeat again and again? Because we just put in new processes and the, the bureaucracy takes over the goal and the, the thing that we're trying to achieve like the bureaucracy becomes the reason for the thing. We can't do this unless we've written this document. We can't do this unless we've filled in this form. But people go through the motions.
They end up going through the motions of the thing rather than really doing the intent of the thing.
Lily Smith: 17:44
Yeah, do you think as well that this could be another thing where, like, I've heard a lot about how amazon work and, randy, you probably know all about this because of your back in your Amazon days you know where they pride themselves on these massive, long PRD, like product requirement documents that they write that go into like really great detail about what they're building and why they're building it and all of that kind of stuff. And then I imagine, similar to you know, know, as you were saying earlier, people like reading about this, the Spotify squad model, where they're like we must do this because Amazon do it and they're really successful, so this must be the way to work. Um, I wonder how much of it is kind of to do with that yeah, I think.
Keji Adedeji: 18:32
I think in some cases it is to do to do with that, except they missed the key point, which is that Amazon probably spends more time on the the why we're doing the thing and what we're trying to achieve, and then the actual, you know, solution specification bit is is probably not the part that takes up the most of that. Those documents, I think it's. It's a bit that. I think it's also a bit where there is that kind of lack of product management capability and understanding, where organizations work predominantly in project mode and so they have these solutions architects and then they have the, you know, the IT teams who are responsible for coming up with solutions, and so they need to have the BAs go off and do a bunch of systems mapping.
And I'm not saying that these things aren't valuable, but those activities are the thing that take up the bulk of the, these documents, and so people get very invested in we've got to specify the solution without really understanding the problem that they're solving or the goal like.
And once we've specified the solution, what's it going to achieve and how will we know that it's done that they'll spend a lot of time in that space rather than spending the time on the problem space and the goal space and the outcome space, and so a lot of teams are invested in, but this is how we work and this is what we do and this is my job and this and you know I'm not having a go at people this is absolutely the condition of the environment that they are working in, and so that's the thing that needs to change, rather than, you know, humans deliberately trying to do a bad job. No one's deliberately trying to do a bad job. In fact, all of these teams, everyone works really hard and they're super invested in and trying to do good work, but the system is is the thing that needs to be tore down. I'm getting a bit anarchic here. Aren't I Anarchist here?
Randy Silver: 21:52
How do we deal with that? So when you're in a role in an organization, you're in leadership roles. These days, you want to provide the guardrails to make sure that people know what to do. They have a certain amount of communicating, prioritization and uh, functional and non-functional requirements and things like that in the organization, making sure people are talking to each other and getting the right idea, but you also want them to have autonomy and trust to go. So how do you balance those and create an environment where people can succeed?
Keji Adedeji: 22:19
I always go go back to the beginning and the first principles of this, which is we can't know what to do until we are sure about why we're doing it and what we're shooting for. I think in a lot of organizations that is fundamentally missing, and so everyone's kind of trying to do their best but they're rowing sometimes in the same direction and sometimes in different directions, and it's not that anything anyone is doing is wrong, but because they have a lack of clarity it can then cause a lot of problems in organizations. So I'm always trying to, you know, if I'm responsible for it, I'm trying to provide that clarity for teams. If I'm not responsible for it, I'm asking the questions to try and get to help me understand what is it that we're trying to achieve, what is our strategy, what's the vision, what is the goal post that we're heading towards, and then we can talk about like, how do we get there and work? You know, work through that process. So that's one part of it, and I think a lot of the challenges a lot of organizations has stems from that. To be honest, that kind of lack of clarity about what it is we're actually trying to achieve and helping teams understand that and the discipline around. Once we do have a clear idea of what that is the discipline around not, you know, running off to do the next shiny thing that kind of crops up that doesn't align with what we said it is we want to do and achieve Then the other part of it is, you know, around helping teams build that capability.
Um, if we can set them in the right direction, tell them what our vision is, tell them what our goals are and the strategy and the guardrails surrounding that, then how do we help build the capability to support them in doing that? How do we make sure they have the right tools to do that? It's all well and good saying that our team should go do discovery if we don't give them access to customers and we've got part of the business that are protective about teams having access to customers. It's all well and good saying that our team should be evidence and data driven, but we don't actually have the capability, the technical capability, the data structures in place to allow them to do that. So it's about giving the a, the, the skills for the humans to be able to do the job, and then the environment and the tools for the people, for the humans to be able to do the job, and then I think the the other part is like the, the culture and the safety around being able to fail.
But that fundamentally means that you have to change the way you work from we do a thing, we get the thing out the door, and that's success If we care about we get the thing out the door and then it has this impact, and this impact is a thing that we care about teams achieving. Then we can create that space to allow teams to try different ways to achieve that thing, rather than we've launched a thing or we didn't launch a thing and that's failed, or a project has failed and therefore it's failed. And I think a lot of the battle scars I've seen people in teams have and around that trust has been because of that perception of failure and how it's been received in the organization and then how that manifests in all the ways that trust is not there. So you know you've got to fill in all these documents and all the other myriad ways where it's clear that there's a lack of trust in the organization like that, that you've got to get to the root of so we've only covered a couple.
Lily Smith: 25:35
I think you're going to have to write like an article or something about all of the others, because we've only got time for probably one or two more. But yeah, what other of the crazy things?
Keji Adedeji: 25:47
Yes, I was going to say redo the calendar one.
Lily Smith: 25:52
So this is like a pet peeve of mine. But yeah, talk to us about calendars.
Keji Adedeji: 25:58
When I wrote this one down. I wrote it down as the one where Google doesn't know what they're doing, and by that I mean you know you've got Google big, pretty big company. It's created a calendar system where you know we all get the visibility of each other's calendars you, so you can see the availability of people where you need to have a meeting with them, and then in organizations they tend to put their kind of rooms and stuff like that in there as well, so you can look for the person you want to talk to, check their calendar, see their availability and then see what rooms are available and you book a meeting with a room. Boom, done right, simple.
Except in this organization they didn't do that. If you wanted to book a meeting with a meeting room, you had to email reception, tell them when you wanted to have a meeting, who you wanted to have a meeting with, and then they would book a meeting for you and find you a room. Except they then didn't update Google Calendar with that meeting or the room either. So then you'd end up in this back and forth with them about all the different people you wanted to have a meeting with and what rooms were available. I was just like how many hours of an organization's life is spent in this process that I'm having right now with this organization, with this reception. I've probably spent a good day, you know, kind of over the course of a day, at least 30 minutes of my time, maybe even more going back and forth, just trying to organize a meeting with some people when there's literally a system that allows us to do this.
I never did get to the bottom of why that was like there's going to be some kind of organizational trauma that's happened. Why someone was like that's it, we're locking down, we're locking down google calendars and all the meeting rooms and so everyone has to go through reception. Something happened and I never got to the bottom of what it is, but it did make me think about in, particularly in large organizations, where you have these little sinks, these little sinks of people's time and effort and motivation, and that's happening. And then my, you know that happened to me in a microcosm. Now, just multiply that by like all the people who've had that experience in the organization, and how much demotivation that creates, how much waste and inefficiency that creates. It's just about how organizations end up in this place where they put in these like processes to to have some kind of control over something, and there will have been something that made that happen. But how do you, how do you help organizations shift away from that?
I'm not sure that I have the answers to that one, because I think all different types of organizations have their version of that. You know kind of. There's another one that I I kind of had heard recently where there's a team member who's part of a project and basically is two days of their week on this is spent on this project and all they do in those two days is sit in meetings. Some of those meetings, yes, they might have something that they're contributing in. A lot of those meetings they just they're just a kind of silent participant. That's two days of someone's week. They feel they're not adding value and like, and how how many of that kind of person exists in particularly large organizations? It's just, it's not, it's cray cray.
Lily Smith: 29:06
I wonder how much of this is as a result or a consequence of businesses growing really quickly and then not adapting their, their processes and their tools for the size of organization that they are and then just throwing people at the problem.
Keji Adedeji: 29:28
Yeah, I think that happens a lot where, yeah, the speed of growth overwhelms a company's ability to kind of keep up with it. Often, yeah, you see throwing people at a problem a lot of the times. But I think I've observed this throwing process of the problem a lot of the times. So it's just okay, something's not going right. So let's, let's put in a very rigid process so that we can be sure that it will go right next time and we can see every aspect of it. That's going on and it just introduces more complexity. And then the next time something goes wrong, it's like, okay, but we all need to get together and come up with a new process for how we solve this thing, which introduces another layer of complexity where perhaps maybe we just need to take away some of the layers of process rather than introducing more.
Lily Smith: 30:18
And I think you know, possibly like applying a sort of product mindset to it almost feels like operational debt or, you know, technical debt, but it's operational.
Keji Adedeji: 30:29
Operational, exactly, exactly and it's just, you know it's. It's overwhelming and when you, when you go into organizations like that, it can be overwhelming to even start to have the conversation like where do you even start to have that conversation, even figuring out which department is responsible for putting in that process, so that you can try and have a conversation, even figuring out which department is responsible for putting in that process, so that you can try and have a conversation with that, with them about it can be particularly overwhelming when you enter a large organization and I think it can kind of wear people down and people just accept it, but everyone's a bit worn down by it and it is a it's hurting organizations, productivity and it's damaging people's sense of autonomy and feeling like they're grownups sometimes in the workplace.
Randy Silver: 31:12
So, Keiji, there's two ways of looking at this. One is that companies are just absolutely batshit cray-cray, as you say. Companies are just absolutely batshit cray-cray, as you say. The other is I find this strangely reassuring, because I've seen this stuff too, and I'm sure most of the people listening have seen this stuff too. So it's not you. This is dynamics of organizations at scale. This is a lot of very logical, smart choices that got added up and turned into cruft of organization that don't make any sense anymore. But we're not nuts right. This stuff really does happen in lots of places. We're all nodding our heads together about this.
Keji Adedeji: 31:56
Yeah, absolutely. We're not nuts. It happens everywhere. Everyone. You know their, their version of this list somewhere and ultimately there's not, you know, in organizations there's not some, some evil council sitting there going. How can we make things so batshit, cray, cray for everyone, like no one is sitting there going? How can we make work really difficult for everyone else? Everyone is there genuinely trying to, you know, make things better in some way. These things manifest not because people are trying to do bad stuff. They manifest because people are trying to do good stuff. But what happens is our fear gets in the way, that lack of trust pervades because, um, you know, we've, we've had a few things go wrong. There's that fear of failure. So how do we help organizations move past this? Well, I think one is acceptance, as organizations get big things just get a little, you know, a little skewy, and there are going to be examples of things like this. The second is having empathy for kind of the place that everyone's coming from, which is that no one's deliberately trying to make me feel like I'm going crazy in an organization. No one's doing that. So how do we do it? We have one conversation at a time. So, like you know that example that I gave you about the Jira board. Like I had many conversations about that bloody Jira board, many conversations, and then I found the nut that cracked it, which was just helping them kind of understand that you trust these people. You don't not trust these people. You trust them. You trust them every week when they release something and you trust them with, like, the most important thing, which is the money. Right, they release a thing. If it fucks up, that's like money that you're seeing not being made. So if you trust them with that, how can you not trust them with this? And it was that. That was the thing that got through in the end. I probably said it in more diplomatic terms than that at the time, but that's the thing that got through in the end. But you know, I did like knock my head against the wall for a while, just trying to get to the bottom of that problem. And so there was that problem. I solved that one. Did I solve the Google calendar problem in that organization? I did not.
And you pick your battles which of the battles are going to that are going to be most impactful? And how do you bring people along on that journey with you? So you know, I've been in organizations where they didn't think that discovery and research was an important thing and that was a battle worth fighting. So you figure out the ways to influence people, to convince people, to bring them along with you to demonstrate, to kind of show them. You know, I think we ended up doing some research. We went off and talked to some customers. We, you know, I think we ended up doing some research. We went off and talked to some customers, we did some gorilla testing and then we came back and we, we talked to people that showed them the evidence of that and it was like, oh yeah, this does really make sense. We know, we don't know the customers and you know we started to win that battle.
So it's just figuring out, kind of, what are the things that are the most important, what are the things that are going to be the most impactful? You're not going to win every, you're not going to fix all the cray cray, but fix the most important bits of the cray cray, I think. And the only way you do that is by talking to people and, again, and have an empathy for, like, where they're coming from. Why do you I'm being curious, you know, doing our products, putting our product hat on, being curious like why, why is it like this? Help me understand, tell me, tell me who was scarred, who was scarred once, that made this thing. You know that made this, that made this decision happen. Having that curiosity hat about why a thing exists rather than railing against the fact that it it does exist, I think can be a sanity uh engine. When you're in this, when you're faced by these kind of what seem to be crazy things.
Lily Smith: 35:22
Yeah, I think what's really interesting about all of this is when we come at these problems, these kind of operational problems, with a product mindset, like we're so well equipped to deal with it, and prioritize, like you say, choose your battles, empathize with the situation, ask the right questions and basically just hang on to the things that really matter and don't give up until you've got a good outcome. But yeah, like Randy said earlier, it's it is really great to hear that everyone goes through these sort of struggles. And you know, like you said, it's these examples are from big organizations, but I have seen some cray cray, batshit, cray cray stuff happening in small organizations too. But thank you so much, Keji. It was so nice chatting to you today and it was quite cathartic. So, yeah, it was good. It was good going through some of those examples.
Keji Adedeji: 36:19
Thank you, thank you for having me. I'm uh, I'm glad that we we made it happen. I know it's been in the works for a while and I'm glad that, um, the topic resonated. I wasn't sure when I was thinking up my topic if it was something that people would identify with, but I'm glad to hear that I have not been the only one.
Randy Silver: 36:46
I guarantee you, Keji, people will identify with this episode.
Keji Adedeji: 36:50 Yeah, no, it's been great to talk to you both.
Lily Smith: 36:52
The Product Experience hosts are me, lily Smith, host by night and chief product officer by day.
Randy Silver: 36:55
And me Randy Silver also host by night, and I spend my days working with product and leadership teams, helping their teams to do amazing work.
Lily Smith: 37:10
Louron Pratt is our producer and Luke Smith is our editor.
Randy Silver: 36:55
And our theme music is from product community legend Arnee Kittler's band Pow. Thanks to them for letting us use their track.
