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.