Hi everyone, My name is Patrick Akio and if you're interested in effective product teams and delivering more value, this episode is for you. Joining me today with many years in product on a coin mod and I like this episode because it helped me a lot. We discuss how to create more effective teams, setting and working towards goals, and All in all, delivering more value. Enjoy.
I was looking at your LinkedIn actually withdrawal in the bank and we saw that your title on it is now owner of Product. Yeah, yeah, that, that is actually my role. Yeah. It's a very fun role where I get to make all of the product owners at Kulu a little bit better everyday. So it's very much about the role itself and how do we enable people to be the best POS they can be. And what do we expect of these people? You know, what does it look like
when they're doing that well? What does it look like when there's improvement needed? What kind of thought leadership is out there that we need to take on board? Sounds like a whole lot and can be quite complex. Is it something you do like as sole person so responsible? And how do you set quality and how do you measure what quality is in the first place? I mean, that's a hard question. I think everybody still is responsible for their own work
and choices. What I really strive to do is give them all the tools they need and all the, well, theoretical background. I am quite big on really understanding that theoretical background. And with that, I believe people should be able to, yeah, take the right steps. For their products, you mentioned that that theoretical background. What are usually some of the misconceptions or things that you have, let's say, interesting discussions?
On something that I love seeing is, well, there's two things. Sometimes there's these organizations or people that say, oh, yeah, we do scrum, but we do it a little bit differently or oh, we deviate from the framework because we don't do real scrum or something like that. And then if you ask about it, like, OK, but what do you mean? Like what deviations? Talk to me. They're actually not deviating from the framework at all.
Like specific example being when I asked this, people go, Oh yeah, well, we do refinement a bit differently. But The thing is in the Scrum Guide, the word refinement is there a whole of one time. And the only thing it says about it is that it's something you do consistently, and you break big things up into small things, and you add detail along the way. And whatever detail that is, there's some examples, but it
differs per context. So those are some misconceptions that I see have entered the chat that are not really in the framework at all. And I think it's super interesting to have those conversations because people end up having this image of what it should be that is more limiting than actually giving them. Yeah, the right point of view to
make the right decisions. Like another example is when, you know, teams talk about their stand up or their daily and they go, Oh yeah, what have you done yesterday? What are you going to do today? Are there any blocks and dependencies like those three questions? And that's also not the goal of that session at all. You know, the goal of that session is, hey, what's the progress towards the spring goal?
And of course, if you have like guiding questions that are going to help you with that might be interesting. But for many teams, the whole goal becomes answering that question, like, hey, what did you do yesterday? What are you going to do today? That might not necessarily answer the question of what the progress is towards the goal of this piece of increment, right? Yeah. So I find that super fun and interesting to talk about.
So that's like the number one example and the other one's actually the opposite to that, where teams or individuals or companies may say, Oh yeah, we follow scrum to the T and then you inspect a little bit and they're like, Oh yeah, no, we have sprints of varying length every time we look at what a good length would be where, you know, these deviations that are really crucial to the framework. So that's just really fun to to
see happening. And I truly believe that going back to, hey, but what is this framework trying to achieve with different parts or ceremonies? And if you make deviations that still achieve that same goal, go for it. Like, I don't care if you make deviations that lose sight of that goal entirely, that might not be the best thing. Interesting. So that's, yeah, that's something very interesting that I've found.
I've also noticed my own opinion on some of these things changing throughout the years because an example there is the whole, you know, stand up or daily is for the developers and technically a product owner shouldn't even be there. And I agree with that to some extent that, you know, if you're there, you're going to have an effect on how that conversation is going. And there is a big chance, especially in less mature teams, that it turns into a reporting
session towards the PO, right? Like, hey, PO, we did this like, OK, well, what are you telling me? At the same time, this whole framework was created for Co located teams. And if you're consistently together all day and you already have that trust and that commitment and those, you know, the core values of the whole framework, if those are set, then you probably don't
necessarily need to be there. But in this hybrid work environment that a lot of people have now, I understand that many teams do take this moment every day to also build connection and talk about their lives and create that mutual trust that you do need to, yeah, be a good and functioning team together. Yeah, interesting. I, I wonder how, let's say this may be lack of theoretical knowledge, how helpful or harmful it is. Because I think in the end,
every team is kind of unique. It's just a group, group of people that get bunched together and they call you a team. And then you indeed need to have the time and attention to build those relationships, to actually have the trust as a team and commitment and understand each other's values in collaborating together. But I do see all the deviations. I also, if I were to tell you what I'm doing. Oh yeah, I would love to hear. I would also say it's. It's probably not perfect, but maybe it's.
It doesn't need to be though. I also don't think it needs to be no. No, it is about incremental improvement also in that regard though. And I think as long as we all strive to also improve the way we work together and improve our understanding of working together, because it's not necessarily, oh, we need to have these meetings and we need to follow these specific guidelines. I think it's more about understanding what those guidelines are trying to
achieve. And I think for many teams doing deviations, there's good reasons for it. But sometimes if it's been a long time, you forget. So as long as you're doing it for the right reasons, it's OK. And sometimes it's just also not the time yet, right? Sometimes you have these teams that have a lot of things they could be doing Better Together, but you can't change that all in one day. In fact, I think that would be a very bad idea 'cause then an overhaul. Yes. Yeah, yeah.
Yeah. But in in elevating then product owners, is it usually this let's say way of working or how we work that needs a bit of tweaking or have you seen other kind of aspects that can also use guidance and improvement on that part? I think, you know, there's the environment as well. OK, what? What is an organization allowing someone to do? For instance, in some organizations you have the role of product manager and product owner separated.
I don't know organizations of course like disclaimer, it might work in some situations. But if I look at the role of product owner in the scrum guide, it specifically says, hey, you should be able to set the direction for the product, like to decide the product goal to tweak it to own it. Like that's your thing. I have many questions on how
that would work. If there is someone right on top of you that sort of does the same thing, what does that really mean for the mandate that you have and the real decisions that you can take? Cause the the hierarchy how you say is PO and then PM is above the PO or how does it usually? Yeah, so 'cause it's. Very different from what I. Yeah. So, so that is what I've seen in some organizations. That's why I'm bringing up the
the example. In my opinion it is 2 responsibilities within the same role because how can you truly take ownership of the product goal if there is someone that's very close to you trying to do the same thing? I you know? The more space there is between those two, the more possible it is to have two people focusing on direction setting. Like if you talk about this product management vacuum, there's some sort of really big goal that a company wants to achieve because, well, that's
why they're in business. And then there's also a software product usually in our space that needs some sort of direction setting. In some organizations. There's a lot of space between those two where it's still possible to have like an intermediate goal and then split that out further to different products, etcetera. In other areas, they're so close together that there's really no point in assigning a separate person.
So I would really look at how much space is there for someone to take ownership of goal setting and achieving results. Yeah. I, I mean with all kind of shared responsibilities for me, it's interesting because then people say, OK, I'm responsible for this and the other people say, OK, I'm responsible for that. And then whatever's in the middle just doesn't get picked up right? Yeah, eventually.
I don't know who told me this or if I've picked it up somewhere, but I've heard someone say once the best way to starve a horse is to assign two people to feed it. If something is a shared responsibility, very often either there's a lot of like, conflict, or neither of them do it because it's like, Oh yeah, but this is shared, right? That's not really my thing. Like, oh, I'm sure the other person bet the horse. Yeah, exactly.
I'm not, I'm not sure if I shared that before we before we started with this recording, but I, I mean, I used to be software engineers to identify as a software engineer I guess. But since January, I've taken up a product management role and I've been having a lot of fun with it. But what I probably underestimated or I had an idea of how much it would be is how much I am aligning with people and communicating. And I honestly think that my biggest role is to bring clarity.
That's usually how I describe it. I try and blink clarity. And if it's not clear either for the development team or for the stakeholders or for the users, then somewhere, somewhere I, I don't think I did my job as good as I should have. Oh, that's a question though, because ideally there is this space where you're not the only one trying to achieve this, right?
Like, yes, it's, it's maybe the difference between accountability and responsibility where I do honestly believe you're describing one of the accountabilities of a product owner. But I wouldn't say you'd have to do all the tasks that are necessarily related to that, like delegate and create a culture where both stakeholders and developers and anybody else that you need to create a piece of value are interacting with each other and creating clarity together.
That's yeah. I think that's fair because also sometimes I would find myself being the bottleneck and being in the middle and being like, OK, I just need to tie people together and then have them in the same room. And then it would sort itself out. And usually it would. This is when people describe the role of product person as a bridge, right I go. I'm a bridge between IT and business.
I I'm frowning a bit about that because I think that is, I understand that that's how you explain it at a party 'cause it's a very easy way to explain it. But I think it is also harmful in a way because a bridge is usually a very narrow thing that can become a bottleneck. So indeed, if you take the same analogy, the bottleneck that you described is very quickly created. And if you're the single person going back and forth, what if you didn't get something? What if you misinterpreted
something? And then it becomes this whole game of telephone where one person says one thing and the next person kind of like, misunderstands it and it keeps rolling. So rather than a bridge, you, you'd almost. Yeah, you'd almost want a completely different analogy where you're trying to create an environment where people play together, right?
It's like, oh, let's create a play date for the developers and the and the stakeholders to get together and understand each other and what do they need to understand each other? And that's not usually someone in the middle to keep translating for them forever. And that's also my preference that people just talk to each other. However, I've also been on the other side and from the development side, I always wanted to talk to stakeholders.
But I've also been in teams where people just said, I think it's easier if you just chat with them and then come back to us with requirements. And that's a very hard one and can be very harmful as well. Yeah, I've definitely seen development team members, but also business team members, just any team member be like, oh, but it's so much easier if you just do it. It might be easier, but that does not mean that it's the best way to the most value.
And at the end of the day, your role is to maximize value. It's not to make sure everybody has an easy time. It's the same thing with diversity, right, 'cause my background is in diversity, diversity management and inclusion. It doesn't mean that it's easier to work together with a group of very diverse people. In fact, it's a lot harder and there's more friction and more everything. But research has shown that the
outcomes are better. You create better outcomes even though it is harder to get there. So I think, yes, this is the position that people will put you in, but don't let them. Easier said than done. Yeah. I think something you mentioned triggered me probably was the diversity aspect as well in thinking of, OK, I've been in product teams and from the development side, for example, the smallest team I've been in was with two other colleagues, so a development team of three.
And I found myself being really productive, and that was also very early on. I love that word. It was very. Yeah, really it was. But it was a really good learning journey. I felt really effective as well in kind of product teams that you've seen in your past experience, what what makes a product team usually really effective from either side in
just delivering value? Working towards goals and it's very cheesy, but it's very true because I've seen so many teams where if you ask like, hey, tell me about how you doing certain things. If a team highlights, oh, we are so productive or we are so efficient. Those are two words that always are a bit triggering to me because productivity that's output driven, you are just
pushing as much as you can. And the same with yeah, I think effectivity is a way better word because that raises the question of what are you trying to achieve? And if you're trying to achieve a certain outcome, you know, what are sub goals under that or how can you cut it up to make it a bit more attainable to test your hypothesis before you go
like old eggs in the basket. So I think it's really working, goal oriented and having everyone on board with that approach as well, 'cause I think what you described before that there's sometimes team members that, yeah, really like in a very black and white way, just want to type code. I know that that's a very stereotypical way of looking at it and I don't believe that, but that is something that sometimes pops up. Then it is very hard to reach this goal oriented. Yeah.
Product way of working. Yeah, yeah. Yeah, I get that. I mean it's something that I, I wouldn't say struggle, struggle is the wrong word. I try and do and I I definitely from past experience like having a clear goal and not many priorities, but one or two and stick to that specifically because then I can actually focus on a few things. I don't have to contact switching, whatever we're building.
So from the product side, I really try and advocate for that and make sure that happens specifically. Now I have the challenge of people are very, I have a very multi disciplinary team and people are not as comfortable picking up work from another discipline. So then when I have a shared goal, it has a user experience, a user component to it. Then, yeah, it might be that it's only a couple of the disciplines within the team and then the other people are like it, but I don't have work.
And then I have to figure out, OK, what are we going to do in the future and accommodate for that work. And that's something I've been struggling with. Yeah, I was actually talking about this exact example with Martin Domain as well when we got together at a meet up a few months ago. And yeah, it is a struggle. That's the short answer. I was hoping you would have
like. I was hoping the same thing when I was talking to Martin, but we both came to the conclusion that, you know, it's a struggle for the team and it's also a struggle for you as a, as a product person. Because what you would love to tell them is, look, I care that you have these feelings, but, you know, try to help anyway.
Like do what you can in terms of, yeah, doing some research for them or being their rubber duck to figure things out, but at one point it doesn't actually help to have more people on the case. So I, yeah, I get it. And I think something I would not recommend is then having two Sprint goals, 'cause that's something that I've seen teams do. And the downside of that is that you always have this duality of, OK, but this is number one.
No, this is number one. And you know, when there's multiple number ones, there is no #1 So I would still have, hey, this is the goal that we're trying to achieve. That doesn't mean you can't do anything else, but it does mean that when, when shit hits the fan, we're all gonna focus on this thing whenever we do. So I think, yeah, that's the way I look at that. And I would try to also give these teams a lots of ownership on what they are picking up.
Like, of course, it is your role to make sure that the backlog is ordered and accessible and people can read it. But I would ask like, hey, do you necessarily have to paint the whole picture of you're going to work on this, you're
going to work on this? I don't think that's the best way to do it. Ideally you'd have, hey, this is the sprinkle, guys, what do we need to or well, you collaboratively come towards this is what our sprinkle is going to be. Then guys and girls, like what do you need in order to achieve this? Like tell me which backlog items are going to contribute to this? And very likely you have some capacity leftover. You don't necessarily have to feel that in that exact moment.
Maybe, you know, try to contribute to this goal 1st and when you come to the conclusion it's not possible, look at the backlog. What else can you pick up? But then that doesn't have to become the goal in itself. Yeah. I mean, one of the thoughts I had and I haven't acted upon that is OK. Let's say I have data analysts, data engineers, front end and back end in kind of this multidisciplinary team, even
data science sometimes in there. Is it in the right approach that we have that we do have all these disciplines in this team, even though some of the work might be very front end and back end oriented if the data part has already been done, or the best part is if it's like a whole new slew of things. But then it's a lot of work and everyone works on it at the same time. Because then you have the aspect of more of the data side as well as the user components, front
end and back end. But in reality I've noticed that more of the work is usually front end or back end and data runs in front of that, and data analysis and data science run even before that. So like, is this the right team structure? Yeah. I think it's a question of how you define products as well. Because in an organization that is trying to do something with more than like 8 developers, you very quickly get into the space of how do we split this portfolio?
Like who's going to focus on what? And you could decide to make that split on specific data products that other teams need in order to achieve their goals. Doing that too much, though, you create a lot of dissonance between teams and between the goals you're trying to achieve. So when you do that, it is super important to always keep in mind, OK, but what are we trying to achieve by having this product? Like, what's the goal of this product? And that could be a data product
that internal teams use. At the same time, it could also be a question of slicing like if you are used to a very technical way of slicing where it's OK, first of the day a thing needs to happen, then the, I don't know, the infra thing needs to happen, then the back end thing that needs to happen, and no then the front end thing needs to happen. It is likely that you have these conversations a lot.
And if it is at all possible to make that sort of like integrated, like I remember this picture picture of a hamburger where like each layer is the different sort of disciplines. And you don't want to only eat the bottom piece of bread, right? You you want to have one bite. That's a little bit of everything. And yeah, I think that is also a possible way to relieve some of this because I agree you're never going to fully get that
out. Interesting. Yeah, I mean, one of the first things that I did when I, let's say, joined this assignment was I was going to be responsible for two teams and one had the data ingestion side and also some of the visualisations, and the other had also the visualisations, but more in depth. And then I was like, yeah, but if we have a new, let's say, advanced data set, then I need the ingestion and then I need the visualisation, and then I have a dependency and everyone
was new. So then we're like, OK, let's merge everyone together, do as much knowledge sharing as we can with the existing people. And we have since then still stuck with that and it's a bigger team. But now I do have the aspect of, yes, sometimes the data work is just not there. And then it's more of the visualisation work. And now this idea of maybe like, I wouldn't call them a data platform team, yeah.
But maybe looking at where we can slice to actually optimise and make sure maybe something runs ahead of more of the visualisation work is very interesting to me. Yeah, yeah. So I think it's either a portfolio question or it's a like specific epic by epic slicing question. Or like I said, it could also be like a team attitude kind of thing. If teams are very used to having this very much like AI work on a
piece of work. And then I give it to you like a very hand over very linear way of working. Well, it could work in some situations, but if you can work that structuredly, I almost wonder if Scrum is the right way to do it. Because the whole idea behind Scrum is this is made for teams that work on very complex things. And the only thing that you really know for sure is that you don't know anything for sure. Like that's the that's the thing, right?
I'm very curious to hear your thoughts on this as well, because I have, let's say this product management mantle, but I have a lot of technical baggage with me in working in product teams and having alignments with product managers in the past already. And I, I can't imagine a world where I wouldn't have that because I really rely on that in kind of a gut feeling and what I think is right in way of working
in the past. Also what I actually keeps the product simple and, and kind of free of weight of code because that's a, a big thing. I'm not a fan of thinking of features. If we're actually, if I don't think genuinely it has value, we're not going to use it. But also from a technical perspective, I think we built something, we're not using it. I have no problem throwing
things away. But then if I would look at myself in a different universe without that technical baggage, I don't know how I would do that. Basically, that's the hard part. Yeah, I see a lot of PM Sprout donors having. No tech. Background, No tech background and also not really having been in the team from the development side and experienced that. How did they do it? I have no clue. So I believe it's really about being able to have the right
conceptual insight. Like I've been product owner for data science teams where you know, they say things and like, I have no idea what that is, but I'm going to file it away as I don't know, approach X. And later when they get back to that, there's a connection to be made. So it's about the ability to to make things simple, especially if you don't understand them. And I think that is a very awesome skill that makes a very good product owner.
Well, if you're able to put that to work in the right way. And yeah, I think this is a bit of speculation, but I do believe most PMPOS have an interest in tech. I see a lot of people that, you know, for, for myself as well, My backup option has always been, you know what, if this doesn't work out, I'll just go to school for a bit of coding and I'll contribute to the field in that way. I have no idea if I would actually be any good, but that
is my backup option. Like if I, if this ever goes down the drain, I might, you know, I might actually end up on the other side of the table. I like that a lot. Yeah. I I've not really met any product people that are in software that have no interest in software. That's really fair, right? Yeah, absolutely. Doesn't mean you have to be able
to do all the things though. You just have to be able to conceptually understand what people are talking about and connect the dots and ask the right questions. Maybe also a very cliche thing, but if somebody has this whole technical story, it's a very common thing to be like, OK, but how is this going to affect our users? Or how is this going to affect our cost of ownership?
And I think by asking those right questions you can always create an understanding, even if you don't have the back on yourself. But to challenge that, then I've also been in situations where people say, OK, we have to move to this architecture because what we're doing now is not sustainable. And then having a very narrow view of what we actually have and still asking questions. At some point, it comes down to trust, right?
Do I believe and do I put trust in my faith in either this person or this team because that's going to make sense. Or are we going to go down a rabbit hole and in the end have a sunken cost and this is going to be a a bad future ahead of us? Yeah, but it's about mutual
trust, right? Because yes, there should be a trusting relationship with APO and the team, but the other way around too, 'cause when a product owner or product person is asking these questions, they're not trying to trick you into not doing it. They're trying to understand so that we can truly make the best decision for the product. And that is something that I sometimes see going wrong
between brackets. Where teams have had experiences with a product owner always saying, OK, but how about you do it in less time? Can we do less? Can we do less, Less, less. And so. Right. Yeah. And then teams get this image that all product management's trying to do is make them deliver hacky things. But that is should not be the goal, let me put it that way. And that trust is also created between each other.
If you are in a team that has that experience, you know, bring it up, talk about it, see what they need to believe that you're different. Yeah, Yeah. Interesting. I always, I mean, not always sometimes got the feeling that, yeah, we're just churning out features and we're not looking at what we actually have and trying to optimize for that and just going to the next new feature and whatever's new, we just build on top of it. And then sometimes I leave the organization and I wonder what
what happens with that. And then I find out, OK, the platform actually died off or yeah, it wasn't, it wasn't budget anymore or did didn't deliver the value that I actually intended to. Only fruit projects actually make it for the long haul. And then there's just this like unending budget behind it. And I'm still wondering the same thoughts basically. Yeah, There is a point though where like I completely agree that you shouldn't just be pushing features for the sake of pushing features.
But there is often in practice also a point where you're currently, you're entering a team that is doing this. Sometimes it's a good idea to say, OK, halt everything. We're first going to decide what we're actually trying to achieve, right? There are also teams that are working on features that are so valuable that it is worth it to kind of stay with this train that they're already on and slightly just try to steer it in a different direction.
So I wouldn't necessarily say that I it is the worst thing in the world, right? As long as we're all aware of, hey, this might not be the best way and we're slowly trying to change it. Yeah, yeah. I like that it's not just putting the brakes on everything and being like let's stop, stop everything. That's. Also not maximizing value.
And this is what I mean with like going back to the core theory, because your role as a product person is really to get the most out of this team and to solve the right problems and yeah, halting everything. And like, this is an example where if you feel like the the book tells you to, OK, no, this is not how we're supposed to work. We're supposed to work very differently. By making that change, you might actually not be delivering Max value. And yeah, that that's a train of
thought that I use a lot. Like, hey, OK, really going back to the basics of it, what will now be the maximized value that we can deliver? It's interesting also in which product phase you then are, because I, I found myself in a product phase where, OK, we're tailoring towards these users, but they're actually not on the platform yet. So if we talk about optimising things and making things more effective, if they're actually not using it yet, then what's
the point? We do need kind of a minimum viable feature set for people to actually find value in the tool that we're building. So that's the mode we're in, but it took me a while to figure that out. Yeah. Yeah. And then it's fun because then you actually have more clear what with what intent what you're building.
And then when people actually do use it, then you can have a reflection moment and see how you can optimize or what the next value point would be. Yeah, 'cause you can work together with people that are going to be future users in order to like, I don't know, get some preliminary feedback. But like you said, until they're actually using it, they're, they're doing that on a a belief.
They're they're, they're giving you feedback because they believe in the future value that it's going to bring them. Yeah. I'm also curious to hear your thoughts on kind of Rd. maps and budget discussions, because I found myself kind of inheriting a road map, let's say, that was already specked out to the end of the year.
And then whenever something would change, because obviously reality changes and timelines move, I didn't want to, honestly, maybe this is my personal kind of frustration. I didn't want to be managing these timelines and moving things and being like, OK, this is not gonna do. So everything moves and it's like this cascading thing and I don't even know what the future's going to look like.
So eventually, and I'm really happy with this, I just got it down to convince people that I just want and prioritize list. That's it. That's our road map. And there's not timelines, but I'm not sure if I can do that for the future, if that's sustainable, or if at some point I actually do need to give out timelines because people really want timelines, especially when it.
Comes to some organizations, but the way I look at Rd. maps is that it's a visual representation of your priorities at a given moment in time. And you know you can pretend that there is no point in ever giving timelines because they might change etcetera. But given the right organizational context timelines that are an indication but will likely change are better than no
timelines at all. And I specifically mean, you know, when other teams also have to free up some space or you're talking about if, if these are the plans for the next year, what would that look like if we have another developer on our team? Like, how could we get to that point quicker? You can only have that discussion if you do put a timeline on it.
And I don't see it as a commitment to be delivering it at that time, but I see it as a, hey, if you asked me today, this is it. And ideally, if you keep that updated daily, weekly, sprintly, whatever, it's actually not that
much work. But I guess it also depends on the tool that you use to visualize it, 'cause if you feel like you're spending a lot of time like moving around little things that never truly align and they click into place and yadda, yadda, yadda, make the tool that you're doing that in something that works for you, right? Not something that takes extra time and you push it to the end of the quarter and then you're like, oh, right, I have to do this again because that's that's.
Whatever testing from you. Yeah, yeah, yeah, no, I'm, I'm really happy I got it simplified. Yeah. At some point I do feel comfortable giving out a timeline, but that's after we've done a bit more, let's say, research, actually talking to users, actually understanding the problem.
Because if I I came into a point where I saw items on a road map where I didn't even know what they meant, they were just either acronyms or full out sentences with the timeline already without both the research timeline as well as then the development timeline. I'm like I don't know how much research this needs nor do I then know what the development effort is. And I cannot have both already in a timeline and then manage those when things move.
In its core, it's a stakeholder management tool, right? Having a, a product rope map 'cause you're trying to paint a picture for people like, hey, what can you expect? Maybe, possibly And there are very different ways of looking at it. I'm personally a big fan of a very optimistic rope map and just changing it as we go along. Other people really building a lot of slack and they, you know, the. Estimate and double it. Yeah, double the estimate or always add something on.
And sure, you could do that. But at the end of the day, it's about doing it in a consistent way, Yeah. Are you then also not a fan of like under promising and over delivery? Depends on the context. I just feel if you, because yeah, if you tell people like, hey, if everything goes according to plan, this is what we might be able to do. Depends on your audience, right?
If you're trying to achieve the goal of getting people excited for what you're trying to do, then you might want to focus on the exciting parts. If you're trying to, well, if you're actually afraid it might not go well, then well, maybe you want to promise a little bit less 'cause everybody, the whole under promise, over delivered. It's something everybody does. So it's almost become the expectation.
So if you tell a stakeholder like, Oh yeah, well, we might be able to do this, and then every time you give them more. Yeah, exactly. Expecting more next time, yeah? So they'll be likely a bit more relation. Management. It's yeah. That's very fair. That's. Like do it every time that becomes the expectation so. Yeah, Yeah. That's really fair in elevating, let's say, product ownership within your organization.
I'm very curious to see what you do for the education part when it comes to people that either want to go more wide when it comes to certain expertise, maybe get really good at the soft skills side of facilitating or indeed stakeholder management, or want to go deep in a certain aspect usually. How do you tackle the education part? Are there any trainings you would recommend or any specific
literature? Because I do never recognize that you fall back on this true understanding of theory a lot. Yeah. Yeah, so I wish I had more time to read, let me put it that way 'cause I have like a long to be read list. And I also rely a lot on the community within my organization right now because there is about 40 product owners and some of them will be better at one aspect, others will be better at another. And they also read books. They also have their resources.
So I try to rely on that a lot. And we also when we discover something out there, we try to bring it back and we try to say, hey, this really helped for me. I think last week. Oh no, earlier this week we took a look at Bain has this like value pyramid. And we looked at that with a group of people said, hey, how could this be useful in our context? How could like, is everybody using this? Nobody was using it, but let's say we did use it like let's play a game.
What could what could be useful here? So to actively keep exploring, hey, I found this new tool. How what could that mean? And maybe you're not going to use it at all, but at least you had a new spike of inspiration for wait, what am I doing with my product? So that's something that I really try to do. To facilitate the right conversations in a way. I like that a lot and it shows instantly that you're not the
bottleneck there. Oh, yeah, no, that, that would, that would not be a good thing If everybody was waiting for me to teach them things that that would no, because 40 people, yeah, that's a lot. Yeah, Yeah, that's a lot of people. Interesting. Do you miss because this is a a different role, right? You were part of a product team. You had a, let's say, specific ownership of a product and now you're elevating other product
owners. Yeah, I do. Have kind of skin in the game, but yeah, in a different way. I see the product ownership and the product role as my product in a way and the community that I'm fostering there. And that really helps because, you know, there are two, I do the exact same things that I would be doing with the product, namely, you know, inspect what we're doing, adapt based on that, be transparent about what I'm trying to achieve.
Yeah. Have hypothesis on if we have this session, it will improve this thing and test that and get people involved, get feedback, lots of feedback. So it, it, it's a less tangible product, but it is, it feels like my product. It's not something anyone can click. But yeah, I didn't have that either when I had a data science product like that was also not clickable, but definitely had users and people that got value out of it. And that is also how I see my
current role. Do you miss the the team aspect there as well? Sometimes, but I, yeah, every time I feel like, oh, I would love to like, what is it that I love about working with a team? It's creating this piece of value. And I'm doing that too, and doing it together with people. And I have lots of people that want to help me with this. Yeah. I, I don't feel like I'm doing it alone. Yeah. I can see that. That's that's really funny. I would have expected that it
would be a bit more lonely. That's what people usually are fearful. Like I have people in my circle of, of network. Yeah. And they for example. Like had a product kind of roles or? No, not even product, but they would be, let's say an individual contributor and then have more of a, let's say, leadership role, but it's still 5050. And all of a sudden they're design director, for example. And then they're like, yeah, I'm responsible for elevating all of design like me and my colleague.
And then all of a sudden it's completely different ball game. But how you describe it, it's actually yeah, it is a different responsibility and accountability, but it can be just as fun depending on how you frame it. I'm a big fan of servant leadership. At the end of the day, I can put all these things to work, but it's the people themselves that are going to have to come to the insights or, you know, improve the way they're doing things.
And I that's also how I view the product role in a development team. You're trying to create this environment where everybody can make the right choices and we're together, we can really create impact. And that's the same that I do now. It's also why right now I am very happy that I'm not all of their like, I don't, I'm not their line manager. So I really am able to stand next to them.
Just like in a scrum team, there is no hierarchical structure or there shouldn't be. And if there is, you're creating some, yeah, some incentives that might not push you in the direction that you want to because a a developer or somebody else on the team always has to feel that freedom to completely disagree with you, right? And to have that friction and to create better things through it. And that's also how I view my relationship to everybody else on the on the team. Yeah, Yeah.
I was wondering that. And if there's no incentive structure, then you can have conversations you might not have had otherwise. Yeah, yeah, for sure. Yeah. And it's not impossible, right? As long as. Challenging for sure. But as long as everybody, if there is a hierarchical structure and everybody on the on the team is aware that that might be a conflict of interest, you can, you can work around it like it is individual cases as well.
But be aware that that's something you're introducing if there is a hierarchical structure. Yeah, absolutely. Yeah, This conversation has been a lot of fun. I think I've been very reflective. I've noticed in thinking about my own situation, like kind of what I can do better in this conversation of elevating product owners as well as effective product teams. Is there anything that's missing that you would still like to share before we round off? That's a good question. Yeah.
I think I've said it before in this conversation, but it really comes down to what are you trying to achieve with your product and get everybody on board with that and to not try to change everything from day one to also understand the current context. Yeah, I think those are important things. I like those. Those are simple, yet very, very effective. Yeah, it is the Keep it simple stupid. That's the Yeah, that's the whole idea behind it. Yeah, for sure. Then I'm going to round it off
here. Thank you so much for listening. I'll put all on the socials in the description below. Check her out, let her know you came from our show. And with that being said, thanks again for listening. We'll see you in the next level.