Intro: [00:00:00] Welcome to the Agile Book Club. Here are your
hosts, Justyna
and Paul.
Justyna: I was just thinking Paul, that maybe there are ghosts, .
Paul: Oh, Justyna .
Justyna: I was close. It's holidays. It's, it's possible
Paul: there is that.
Justyna: Um, but you know, I went for the run, uh, on Sunday. Mm-hmm. . At night. I was never so scared in my life because all of those Halloween ornaments all over the places, all of the ghosts, a lot of the pumpkins, I never run 10 kilometers up under five minutes per kilometer.
My speed was like 4 55. I was just so
Paul: fast. Wow. Wow. That is impressive.
Justyna: Normally I do like, you know, five 40, but I was just, you know, under so much adrenaline and stress because I'm [00:01:00] always afraid when it's dark, little bit not, not so, you know, confident outside. And I knew that I have to practice running at night.
And whoa, Halloween, the
Paul: best scores now running at night in the city is very different than running at night in the mountains, which is what you're going to be doing right. Yeah,
Justyna: but it's a very small, it's a very small city that I'm living in and a lot of little side rows, but yeah, you are right. You are right.
It's totally different. I did two weeks ago, the 29 trail run in, in Brussels, in the forest. Mm-hmm. . And I was so proud of myself that I got lost on new ones. Congratulations. During
Paul: the. Oh, getting lost will just destroy an, an ultramarathon. My very first one, my very first one, they had had, uh, two distances.
They had a a 50 K and a hundred K, and at some point the 50 K and a hundred K paths crossed and they were using the [00:02:00] same markers for both of them, and like 40 or 50 of us went down the wrong trail. And because we are now on the hundred K trail, and there was a marker every few hundred yards. We were constantly being reminded that we're doing the right thing and we were 10, 12 kilometers off course before we realized it turned around and went back and you know, adding a half marathon to your ultra marathon is not a great start.
no .
Justyna: I dunno. You know, I, I think like, at that level, I would be just so tired in the road. I would just sit and cry.
Paul: We, we, we gave up, we, we all, um, we all ended up in a big group and we all just, um, ran down together to, to the sun was just rising. And so all this happened in the dark, of course. And we ran down to the next village and just caught a bus back to Crackle.
Justyna: Ah,
Paul: so it doesn't fall. It was, yeah, it [00:03:00] was around Ji.
Justyna: Oh wow. Yeah, yeah, yeah. That's, that's, that's definitely
Paul: the thing. So it was when I did my next ultra-marathon, I actually downloaded the, this might be a tip for you. I downloaded the whole route, um, to my gps and I got one of these, these mini gps that you, you can strap onto your, And it had the route on it.
So it, it, now you can get, um, probably even apps that will do this for your phone. Mm-hmm. . And so with a glance, I could see if I was too far off the route. I mean there, there were, there were some like rounding errors and such that would show me a little bit off the route, but there was no way I could go 12 kilometers in the wrong direction without.
Justyna: Mm. Yeah, definitely. I will do it. I, I've, I was already using your last piece of advice and order different lights, uh, to actually see in front, see around me and, uh, and I've been testing, [00:04:00] testing that as well, so,
Paul: yeah. Okay. Well, when is it, when is it? This, this, uh, ultramarathon?
Roman: Yeah,
Justyna: it's, wait, I have it in my calendar 3rd of December.
So second December. I go to France because it's in France, actually in Leo. And then we leave at 10:00 PM and hopefully I arrive in the morning.
Paul: So the race starts at 10:00 PM. That, oh, I love those. For the, for those, uh, for the shorter ultra marathons that, that you can theoretically finish in 10 or 12 hours.
I like it when they start at night because you'll see it's a wonderful feeling to be running for like eight hours in the pitch blackness in the mountains or in the forest, and then watch the sun slowly rise and the air start. Oh, to warm up. Oh, .
Justyna: Oh yeah. I, I, I can already see it with [00:05:00] my imagination. Yeah.
So definitely can't, can't wait
Paul: for that. I did, I did one, um, 50 K that was just around the island of Gozo, and it was beautiful because it skirt, I always had the ocean on one side of me. I went all the way around the island, but it was, it only took about less than 10 hours to do, and it started in the morning.
Hmm. We didn't get that experience, but I'm kind of glad for that cuz there were a lot of places where you could fall and die on that route and I wouldn't want to run it in the dark. Mm.
Justyna: Yeah. I, I I think that I will view on, on that one, but you know, recently I also experienced, uh, like used one of your met thinking method.
I'm not sure if I should call it like that, but you taught me once that when you have a problem that you want to tackle, you go outside for a walk and you walk. Very slowly. Mm-hmm. like one step for 10 seconds just to see how [00:06:00] your brain works and what comes to your mind. People look at you like you're crazy.
Mm-hmm. . Yeah. I don't care. But it is. So it was amazing. And then I was trying to make it also with like slower bine and breathe out and I was just thinking like my mind is just, uh, Really processing a lot, but like calmer and like, you know, getting to this, uh, flow.
Paul: Wow. Cool. I've, I've, I've shared that technique with a lot of people.
None of them ever did it.
Justyna: But I have to be honest with you, I went for the walk and I started walking slower when I was in the fields. . Yeah. Yeah. So only birds, dogs, and, uh, random farmers. Uh, could, could, could see my, uh,
Paul: performance. Yeah. I've done it along the river. But you definitely don't wanna do that in the city where you're just going to irritate people,
Justyna: Oh yeah. If they want to pass you and, uh Oh. [00:07:00] Hmm. That would be irritating us as
Paul: well. Yeah. I've got a new pedestrian rule. Remember we have my, my set of rules for, for a well-ordered Yes. Another one that happened to me twice today, and it, it just bugs me to no end is when you're walking in a straight line on the right hand side of the sidewalk and a person is walking towards you in a straight line on the right hand of the sidewalk.
Everything is fine, but at some point. They want to go into a shop or into a door or to a car, and the only way to get from where they are to that point is to just abruptly change direction and just plunge right into you. Like, ignore that you're there and you have to dodge out of their way. When, when I'm in that situation, and it happens, because I, I have an office on a reasonably busy pedestrian street, I'm off often walking forward, and the quickest way to get in would be to cut somebody off.
I just keep walking straight and when they pass me, I turn left and go into my office. How hard is that? But [00:08:00] people get, Fixated on what's important to them. Like they're, oh, there's my car, that they don't even notice that they're going to step on me to get to it.
Justyna: Yeah. I love your pedestrian rules. I remember when we were walking and you were telling me about the pedestrian rules. I have only one. That people always have to walk on my right side. That's all what I need. Every single run I do, I run , just passing people, so they're on the good side. I can run 40 kilometers, but if I would've to run on the other side, I
Paul: cannot because to you, all people are horses.
Yes,
Justyna: And some people when they notice and they ask me why it's that, and I said, yeah, because of horses, they're like offended. I said, I'm sorry. I'm honest. , I'm just so used to, and then I tell them, if you would take your watch to the, on the other hand, how would you feel? That's how I feel.
Paul: Yeah, that's a good [00:09:00] point.
That's a good point. So if you spend a a sufficient amount of time leading horses, Then you could actually find that you spend more time walking along next to somebody who's a horse than walking along next to somebody who's not.
Justyna: Yes. . Oh, yes, indeed, indeed, indeed, indeed. Yes. So
Paul: shall we introduce our guest?
Yes. So today we're gonna be speaking with Roman Pitchler. He's written several books. I think he's got three books out. But we're going to be talking to him about, uh, his, his recently revamped second edition of Strategize and. And I'm looking forward to it. You've all heard the, heard the review. We've got a lot to talk about.
And, uh, he's gonna be joining us any moment now. So, uh, please join us in, in welcoming the author of Strategized Roman Pitchler.
And so I, I, I think I wanna start at the, at the very top. I think I wanna start at the very top and, and just, just [00:10:00] clarify something for our audience that, that we might not have addressed as well as, as we could have. And that is, who did you write this book for and what do you expect them to get out of it?
Roman: Who do I, uh, who did I write this book for? Well, I wrote this book primarily for people who are responsible for a product. So, uh, people who would traditionally be referred to as product managers or in a Scrum context as scrum product owners. Um, but I, I'm also hopeful that people who manage more than our product, the product portfolio are likely to benefit from it.
Or people who manage less than a product. a product capability, a feature. Um, and also people who look after a product management team ahead of product. But the primary beneficiaries are people who are in charge of an individual product
Paul: and, and. What would you expect them to be able to do differently after applying lessons in this book?
How [00:11:00] will it, how will it change their lives and careers?
Roman: Well, hopefully it'll help them consolidate their knowledge around product strategy and product road mapping practices and help them acquire, uh, new pieces of knowledge, um, you know, fill in some gaps, go deeper. Um, my experience suggests that, um, You know, product management is, is quite a diverse profession and in many ways not as mature as, say, um, software development, software engineering, or sales or marketing.
But particularly in the space of a product strategy, uh, I, I, I think the maturity that we have across the profession isn't particularly high. So I do hope, but at the same time, , uh, at least for me, uh, product strategy plays a central role in, uh, making the, the right product decisions, making effective product decisions, and achieving product success.
So I hope that my book helps people. [00:12:00] Improve their ability to ultimately create products that, um, are, are meaningful and valuable to users, customers, and, and their
Paul: companies. Thank you. You know, I, I work with a lot of product people at various levels as a product coach, and one of the things that I see very often, in fact, all the time, I've, I've never met a product manager who didn't tell me that.
They know they should be committing more time and effort to strategy, and I've certainly never met one who didn't say, I wish I had more time to talk to my users or explore the competitive environment. And yet for some reason, especially in corporations where there is just so many challenges that are, the product has to deal with.
Strategy, despite being considered by most people, the most important part of the job is the first work to get cut. Do you have any advice for product people who know they should be doing more strategic work, but [00:13:00] just can't seem to find the time?
Roman: Yeah, I, I do, and I think I, I write about it at least briefly in the introduction of, uh, strategize the, the second edition.
Um, so. It's not uncommon that product people deprioritize the importance, but not so urgent. Work and strategy and discovery activities are part of that, so we can, uh, put off product discovery work. We can put off product strategy work for a few weeks, a few months. And we may not feel notice any immediate impact, but sooner or later, uh, you know, um, the work that we're not doing, um, will, will become noticeable.
Um, a competitor might leap frog. Um, the development team might not have had the opportunity, um, to do any technology research work. And so we're being caught out and an emergency, uh, is something we need to deal with, uh, has manifested itself or possibly even, um, developed into a [00:14:00] crisis. So the advice that I have, that I have and that I give to product people, uh, the people that I, uh, that I teach, that people that I, uh, coach is, uh, ring fence some discovery and strategizing time.
Block some time in your calendar at least half a day per week as a rule of thumb. In, in addition to that, um, setup regular. Um, collaborative strategizing workshops where you review the product strategy and the product roadmap together with development team members and the key stakeholders and, uh, don't make the mistake that you sacrifice, um, the, the time, uh, the essentially strategizing a discovery budget.
That you've set aside. Um, but I mean, in a way, something similar is hap is true and, and happens when it comes to learning and development measures, often, you know, those, uh, those activities, those tasks are deprioritized in order to attend to more urgent, um, um, uh, duties. But the, the other thing that I'd like to [00:15:00] briefly mention is that, um, not all product people are empowered to make strategic decisions.
So, you know, as somebody who works as a product manager or scrum product owner, I might, uh, want to, uh, spend more time on product strategy, but, uh, I may not be authorized to make, um, the necessary strategic decisions. And if that's, uh, the case for any of the listeners, then I think, you know, there's probably, um, Uh, another action required, and then I would then recommend engaging with the decision makers in the organization, trying to influence them and, uh, increase their awareness.
Why it is important that product people have what I call full stack empowerment, are not only authorized to make tactical decisions and look after, say, a product backlog or the, the detailed requirements. But also take charge of the product strategy. And sometimes working with, uh, agile coaches and, and Scrum masters, uh, can be a great way to, uh, foster some, some organizational development and change in that space.
You know,
Justyna: if [00:16:00] I understood correctly what you've been saying, like if you are the product manager that works more like in the features factory and you are not empowered to make the strategy, Then what would you advise to that person Actually to, to, to do, like they see the problem, they see that the product is not going into any direction, but at the same time, they are getting the pushback from the management saying like, you don't have the authority to make the strategy, and they are just put into the features factory.
What, what to
Roman: do. Mm-hmm. , you know, it's a great question. I think it's related to, uh, what I just touched upon, a lack of empowerment, uh, a lack of full stack ownership. Um, and so the question is then how can you bring about, um, An appropriate level of empowerment, how can you increase your decision making authority?
And one way to do this is to engage with the, uh, decision makers in the organization and try and influence people in a positive way and explain why it is, will [00:17:00] be helpful and desirable for the product people, uh, to be empowered, to be allowed to make strategic decisions, or at least have the final say on.
Product decisions. And, uh, another approach is to align with Scrum masters and, uh, agile coaches. Uh, I mean, the job of a Scrum master is to create an environment where people can succeed. Uh, and that's not tr not only true for the development team or the development teams, it's also true for the product people.
Um, so yeah, it's a common issue. I find, uh, that product people don't always have the necessary level of empower. Um, another thing that, uh, comes to mind, uh, that'd be then, uh, a third, uh, um, a third option is to, um, uh, increase your knowledge around, um, the product strategy. I remember talking to, uh, someone on one of my training courses a number of years ago, and, uh, the person complained to me, In one of the breaks about, um, her management and said, well, you know, I [00:18:00] wish my management would allow me to take charge of my product roadmap.
And so, you know, after, uh, talking to her for a little while, I, I stopped and said, well, excuse me, but have you ever created a product roadmap? Well, do you know how to create a product roadmap? And she looked at me slightly so price and said like, no, why? And so I said to. Well, you know, I know it's be kind of nice for your management to, to be encouraging you and be supportive, but, you know, if, if your boss doesn't feel that you have, um, the, the knowledge what it takes in order then to, um, take charge of the product roadmap and make the right road mapping decisions, it'll be, it's, it'll be very hard for the person to trust you.
So maybe one way then is that you read up on product road practices and you just, you know, Take a product roadmap format or template you're comfortable with that resonates with you, that seems, seems to be okay, and experiment with it and create a roadmap and, and present it to the decision makers and, and thereby show that you're interested, but also capable, at least to a certain extent.
[00:19:00] Um, so, you know, that's another way in a to, to ultimately empower yourself.
Paul: I like that. Yes, indeed. Uh uh, um, one of the biggest challenges that that PMs have is pushing back. And one of the things I liked about your book, which I think was great advice for PMs, is you can't push back if you can't make a well articulated case.
And you can't make a well articulated case if you haven't done the work.
Roman: That that's right. Yes. And, uh, you know, it's an interesting thing, but for me, strategizing means, um, Being selective about what we do. Um, and that means saying no, saying no to many options, saying no to many things that potentially we could do, but we've, uh, intentionally decided against, at least at this point in time.
So, yes, it is important to, to do the homework and it's important to have, you know, I think it's important to have a systematic approach to, um, Make, [00:20:00] make the right decisions. You know, things around who should be the users and customers. Uh, what target group should the, should the product serve? Um, what is the value proposition?
What is the main need it should address? And, you know, what are the business goals and the standout features. So for me, those are crucial pieces of information that I need to get right so I can then make the right decisions that I can make informed decision.
Paul: Thank you. A lot of this book is about, and I know it's aimed at, at a number of product people, but a lot of it is about how a product manager can direct the strategy and implement a strategy for a particular product.
But at the same time, at a lot of organizations, you've got quite a hierarchy. I've, I've even been organizations where they have six levels of product, associate product, junior product product manager, lead product manager, direct group, product manager, director of product, VP of product. What have you. And uh, and I wonder if, if you.
Help to articulate especially what aspects of strategy should be completely within the responsibility [00:21:00] of the product manager for the product, but also how these, how the hierarchy of, of product leaders can contribute to a, a coordinated strategic approach to product develop.
Roman: Yeah, sure. I can try and say a few, few words about this.
I mean, for me, the job of a, a product leader in the sense of somebody who looks after a group of product people, uh, ahead of product. Uh, so somebody who manages, uh, a product management team is, uh, not so much to make strategic product decisions, um, but rather enable the, the people, um, who. You know, a part of the, the group, a part of the team, part of the product management group, um, to, uh, make the right strategic decisions for their products and own their products in, in, uh, in their, in, in their entirety.
So, you know, have that full stack ownership that I briefly mentioned. Um, and for me, somebody who is in charge of a, a product, like a product manager, a scrum product owner, should. Really [00:22:00] fully own the product strategy. So should ultimately be empowered to, uh, decide on the target group, uh, the value proposition, standout features and, uh, business goals, and should be empowered then to translate those needs and, um, business goals into more detailed, into more specific and ideally measurable product goals or product outcomes.
Um, and capture them maybe on a product roadmap. So that's the level of empowerment I'd be looking, uh, I'd be looking for. Now, I'd also like to point out that. I'm not advocating, uh, an image of a, a product manager or square product owner who is a little bit like a, a product dictator and, you know, is this fully empowered person and, uh, you know, the only person who then ever is, is allowed to make any strategic decisions.
I think that'd be wrong, . Uh, as product people really rely on the collaboration, we rely on the input of development team members and, and stakeholders to help us make the right decisions. So it. Balancing a collaborative approach with the right level of empowerment. But I do think [00:23:00] that product people need both.
They need the level of empowerment and then, you know, product people benefit from a collaborative approach. Something I, I, you know, think quite strongly emphasize in my book, getting regularly together with development team members and stakeholders and involving development and team stakeholders in, uh, creating a vision, setting goals and validating, um, uh, a strategy and, and, uh, developing the strategy and the roadmap.
Um, so I think it, it takes those two parts, um, or it requires those two parts. Um, another aspect is when you think about working on, on large scale products, where you often have a group of product people collaboratively, uh, collectively managing a product, jointly managing a product, I think it is, uh, helpful then to have the person who's in charge of the overall products, um, Um, you know, also in charge of the product strategy and the product roadmap.
But the other product people, whatever, um, specific roles they may play. You know, if you call them feature [00:24:00] owners or product, product area owners, or if you use the say safe model and you have a product manager and then you have tactical, so, so called Safe product owners, uh, that these other product roles also have an opportunity to be involved in strategic uh, decisions.
And contribute to those decisions. So again, that allows the person in charge of the product to leverage the, the, their knowledge and expertise. And it ensures that the decisions are clear and that people are more likely that they, um, not only understand those decisions, but those, but also follow them through and, and implement the strategy and implement the roadmap rather than maybe just paying lip service to those plans.
Mm-hmm. .
Justyna: And you know, like one of the key message from me from strategize was, If you don't have the vision, if you don't have the strategy, like what you put in the backlog, it's basically, it doesn't make any sense. And I really liked what you also did in the book when you were saying about validating your strategy over the time, that it's not [00:25:00] like the artifact that you create, hang on the wall and say This is the strategy for the next 20 years.
Could you maybe for our listeners tell a little bit more about your ways or tools to validate if. Product strategy is moving in the right direction, or where is it actually going to?
Roman: Yeah, sure. So, um, So, you know, I think it's important whenever you create a, a new strategy, be it for brand new product or be it because you want to make a bigger change to an existing product, uh, that might be to extend the, the life cycle of a product and take it to a new market or market segment, for instance.
It's important then not only to create the strategy, uh, or new strategy, but also then to systematically. Assess it and see does it contain any leap of faith assumptions or does it contain, contain any major risks? And if so, then, um, prioritize and choose the risk or biggest assumption. And then think about how can you possibly [00:26:00] that risk address that, uh, assumption.
And I, I prefer to talk about risks, but for me, you know, risks and assumptions are closely related. Assumptions means, uh, there's uncertainty. A risk means there's uncertainty that could cause a damage . Um, so yeah, choose the biggest risk, and that might be that the value proposition is not strong enough.
It might be that we've chosen the wrong target group, or it might be that a technology, uh, That we have in mind, um, say machine learning in order to provide the product is, may, may not work out or that, uh, a business goal is not realistic because maybe there's an issue with the underlying business model or an element of that underlying business model.
And so depending on what risk we're dealing with, or uncertainty we have to address, that'll then help. Us choose the right, um, validation technique and, uh, hopefully apply that validation technique. So, you know, for something around the value proposition, it might be direct observation, it might be, uh, an interview with selected users or customers, uh, for something around say, uh, technology piece, like machine learning.
It might be creating a throwaway [00:27:00] prototype or spike. Spike. Um, but then I think once. Uh, the product has been released, be it, uh, as an mvp, a minimum viable product, a brand new product, or be it as a, as a new version in case of the life cycle extension. It's, uh, still valid to continue monitoring if the strategy is working and, uh, you know, continues to be effective.
And, uh, that's done by the use of, through the use of key performance indicators. So in a sense, there's an. Um, period of validation that is required for a new strategy. That might just be a few days, so it might be several weeks depending on how, how much innovation is present, how much uncertainty is present.
And you could say then, then there's a continued monitoring or, you know, regular inspection process that needs to be applied in order to make sure that the strategy is still valid, that it's still effective, um, and look at, uh, look for opportunities to, uh, evolve it and, and improve.
Justyna: Yeah, and, and in your whole [00:28:00] answer, I think that you used one of the word that sometimes can bring to people like little goose bones, which means KPIs.
Could you please tell us a little bit more, like for product managers, product people, product owners, like what is the set of advice that you would. Tell in order to select appropriate KPIs for their product.
Roman: Yeah, sure. I, I think you're absolutely right. Um, KPIs are super important, but you know, sometimes there's quite a bit of confusion around what are they and how can I choose the right ones for my product.
So the, the model that, that I like to work with, that I've created and that I describe in the book is, To derive KPIs from two sources. The first source is, um, the product strategy, uh, and specifically the needs and the business goals. Um, and so, you know, based on the needs that I've, uh, Stated and the validated needs, I should say, and the validated business goals, I think about, [00:29:00] okay, you know, what metrics will help me, uh, determine if I'm making progress towards meeting those needs and meeting those business goals.
And then the second source are the, uh, product goals on the product roadmap. And in fact, you know, I suggest that, uh, You know, uh, I recommend capturing metrics on the product roadmap in order to ensure that the product goals are measurable. And, uh, if that's what you do, you can then simply copy the metrics on your product roadmap into your set of KPIs.
Um, and so those are the two sources. And then, uh, uh, another, uh, Uh, uh, I guess, uh, another source, another way to compliment your set of KPIs is to think about indicators that measure the product health and the team health. Um, so those will be quality related indicators such as, um, um, coding complexity or, uh, refactoring potential, uh, number of open books.
And, uh, team related ones [00:30:00] such as, uh, illness, uh, turnover, um, or, or, you know, generally absence. Um, it may be also team motivation. Uh, you know, I mean, you know, all the other customer and finance related KPIs. You know, think about things like customer kpi, like say engagement or, uh, market share. Uh, that will also user feedback.
You know, they might all be showing that the product's doing really well at the moment. Um, you know, similarly, the financial KPIs like, uh, I dunno, cost are monthly recurring revenue might all be very positive, but if then, um, the software quality suffering and, uh, technical debt is being built up, or if the team is, uh, you know, uh, struggl.
Because people are overworked and, uh, you know, there is no sustainable pace at all, then, you know, there's likely to be trouble around the corner. And, and so I think it's important to, to add those health indicators, um, to your set of KPIs and generally try and keep the number of KPIs to around 10 to [00:31:00] 15 as a rule of thumb.
So I don't measure everything that can be measured, but. Try and measure what is helpful for your product, again, based on the value proposition, based on the business goals, based on the product goals, and then add selected health indicators.
Justyna: And you know, I think that you used the metaphor in the book when you said about the car dashboard that you of course can select every single.
Metric about your car, but what you carry is the pet and, and the, and the speed. So yeah, I think that indeed that's, that's a good rule of time. And also you mentioned in the book the product scorecard for kpi, uh, for KPIs as a, as a tool for validation. Would you tell it a little bit more about that idea?
Roman: Well, I've, uh, I've, I wrote about a product scorecard in the first edition, but in the second edition actually, I, uh, I removed it, .
Justyna: Oh. So I read the first one then. Wow. I was so sure I was reading
Roman: the second one. , I've, I've removed it from the second edition because I felt, I, [00:32:00] I, that you know, Usually product people have, first of all, a number of analytics tools and, you know, have then, you know, standard tools within their company.
That enterprise, in order to visualize metrics and and KPIs and then having an additional product scorecard often isn't really necessary. So I didn't really think it, it added that much value. What I've kept, so is the idea of trying to create a balanced set of indicators. In balance, in the sense that you not only look at financial and customer indicators, KPIs, uh, which are the most common ones in my experience, but you, but you also add, you know, what I call now health indicators, uh, people and, and, and product related indicators to really have a, a well rounded, uh, picture of how well your product is doing of the product performance, the, the product's ability to create value.
Justyna: Okay, so, so now I know that I had the first edition. That's my fault, . But thank you very much for, for the, [00:33:00] for the clarification. But there was part of the book that I really appreciated and was on the product, uh, roadmaps. And I think that that's, every single product person should read that or be aware of it, and.
I have some questions because, uh, now I'm also struggling with working on the portfolio roadmap, and I was just wondering like, what are the. I don't want to say the best advice, the best tools, you know, to do it, but, uh, how do you approach the process of building the portfolio roadmap?
Roman: That's an excellent question and uh, it's not an easy question for me to answer, to be honest.
So one of my intentions with the second edition was to strengthen the product portfolio part, and I was, uh, or. You know, offer more, more advice, more recommendations around product portfolio management and product portfolio strategy and product portfolio roadmaps. And, um, I, I did quite a bit of research, but [00:34:00] based on the research I did and based on my own experience, um, I didn't really feel that the material that I had was strong enough to, um, really expand on it.
So I decided rather, Uh, keep the focus of the book as it was. And in fact, you know, I've kind of deprioritized the whole product portfolio, um, content from the first to the second edition. So I, um, yeah, I just really tried to focus it on, uh, working with single products. Um, and, and it's not only that, I think there's, in a way, maybe a lack of general understanding how to best.
Approach product portfolio strategies and product portfolio road mapping. But also that I find that a lot of companies and a lot of product people struggle with the strategy and the roadmap of an individual product. And obviously if we then look at a group of related products, say, I don't know, um, You know, productivity tool suite, like Microsoft Office for instance, things get more [00:35:00] complicated and I have to ask myself, okay, um, do I need separate roadmaps for the different, say office members?
Um, do I need separate strategies or could I maybe work with one overarching product portfolio strategy, or should I use both? Should I have an overarching product portfolio strategy? And then individual strategies, say for office and not office, word, PowerPoint, the Excel, for instance, just to. You know, use the three core members as an example.
So things get, get quite, uh, get quite complicated and I, I really generally recommend to, um, develop a solid practice strategizing and road practice for individual products. Before you then, uh, try and apply any, uh, any he any strategizing and road mapping, um, skills to, uh, a group of products. A yeah, a group of products, a product portfolio.
Um, but. You know, having said that, it can still be useful when you have a product portfolio, say like Microsoft Office, and you have [00:36:00] three, uh, products like Excel, PowerPoint, and Word that are pretty closely related that you then, uh, um, display their roadmaps. Um, Together, and that's where product portfolio roadmap comes in.
It's just really a, um, a way to depict or describe, um, you know, the roadmaps of several products together. But that can be nice because it can, can make it easier to spot dependencies, it can make it easier to visualize, uh, say, shared goals or. Shared, um, dates or timeframes, uh, if you want to use dates or timeframes on your roadmap.
Um, but it can become overwhelming in my experience once you go beyond say, four or five, uh, products on a, on a product portfolio roadmap. Um, and so then I sometimes recommend when you have a, a larger product portfolio that you use a product portfolio roadmap really only for those cohesive members, and then use individual roadmaps for.
Um, other, other products, uh, other members say, [00:37:00] um, outlook comes to mind, or what else is in the Microsoft Office portfolio? Um, notes, isn't there? Something like notes? Mm-hmm. , you know, where aren't any Oh, thank you. Yes. Yeah. So, but there aren't any, any kind of close connections to the three core products that we've talked about.
Excel, PowerPoint, and Word. Um, so then you have a combination of a product portfolio roadmap and individual roadmaps. Yeah, , that, that
Justyna: helps, that helps, you know, you know, as complex as, as, as the issues. I think that, that, that brings some, you know, clarity, not like, like kind of the blueprint on like, you know, where, where to focus on how to, uh, approach.
So
Roman: thank you very much for that. Oh, it's a pleasure. As I said, I mean, it's, it's still an area of, of. You know, I'm, I'm very much interested in and it's, but it's, it's also an area. I mean, I've also looked into ecosystems because for me that's related to product portfolio management. But again, I feel it's more like an evolving, uh, field within product management rather than at least the books that I read.
And, you know, again, reflecting on my own practice, the experience that I have. So [00:38:00] I felt it was just a little bit too early to offer solid advice. Mm-hmm. , that fits with the rest of the book, but
Paul: still some very useful guidelines. Thank you. So taking it back to the product level then, um, The, the two primary tools that, that, the day to day tools are that guide, the, the product development are the, the product roadmap and the, the product backlog.
And the backlog lives mostly in the domain of the product teams, whereas the roadmap lives mostly. There's overlap, obviously, but mostly in the domain of the, the internal stakeholder. Maybe external stakeholders for specific kinds of roadmaps. How do you ensure that those things remain properly in sync and that the backlog doesn't drift away from the roadmap over the course of whatever your, your, your planning, um, cycle is?
Roman: Yeah, I think that's a, a very important concern and for me. [00:39:00] You know, as important or as it help, as helpful as it is to have a dedicated strategy, a dedicated roadmap, and a dedicated, uh, product backlog, and, uh, have separate plans and maybe use separate tools in order to, um, capture and visualize those plans.
It's really important to ensure that they're aligned and that they stay synced, that they stay aligned. The way I do it is through goals and outcomes. So I, I say that any, uh, product roadmap goals and outcomes must be aligned with the, uh, needs and the business goals, say to them, the product strategy. And then I align the, uh, product roadmap and the product backlog by literally copying the next product goal on the product roadmap into the backlog, removing any backlog items that do not help meet this goal.
And then I add, uh, Features, if there are course grain features on the product roadmap, uh, I, I add them to the backlog. I copy them across, into the backlog and ask myself, okay, what other [00:40:00] capabilities and deliverables have to be provided, have to be implemented in order to meet this specific product? Um, and then, you know, you start deriving epics, start prioritizing my product backlog, and then get the high priority items ready for the upcoming.
So it's essentially through those goals. Um, and, uh, that's at least part of the answer. The second part of the answer will be to regularly review those plans. Um, and the, um, rule of thumb that I like to give is to, uh, Um, review the product strategy and product roadmap on a quarterly basis, uh, in form of a collaborative workshop involving development team representatives and key stakeholders.
Um, and by reviewing the product strategy, I would take into account the development progress and any bigger significant product backlog changes. And, you know, by reviewing the product strategy, I would take into account any bigger product roadmap changes. And so that, Bigger changes in the backlog can inform changes in the roadmap and bigger changes in the roadmap [00:41:00] can then trigger changes in the product strategy.
And that's a, I find an effective way to keep those plans aligned and make sure they don't go out of sync. And so that ultimately strategic decisions are being translated into tactical ones and strategy guides, execution and insights from the tactical work, from the execution of delivery, of the development work helps inform strategic decisions and helps us evolve our product roadmap and, uh, our product strategy.
Paul: Thank you very. You know, I, I've had one thing. It, it's, it's not directly related to the book. I don't think you address it in the book. I don't think anyone has, but it's very rare that I get to talk to somebody who's got this much experience in the product space. And especially you student and I were talking about this, this earlier.
The nice thing about being a product coach is that you get to talk, or, or as you are being, being a consultant, you get to see so many different problems and so many different ways of approaching them that an individual con. It doesn't get to do over the course of their [00:42:00] career, and so you might have some insight on this and that is that one of the big challenges.
Product management is the cognitive overload, the enormous amount of data that a product person deals with on a regular basis. And, and I think this, this data falls into a few different, I I think of them almost as living in multiple time zones simultaneously. So why you're doing your strategic work. You are, you are at the, the knife's edge and you are getting.
Up to the minute data about what your competitors are doing, what your customers are doing, what's happening in your marketplace. At the same time, you're living in the present and you have to be concerned about delivery and staying aligned to the product strategy and the roadmap and delivering consistently.
And then you also have this kind of, Omni viewpoint, this kind of over overall evolving intuition about the problem spaces and competitive spaces, and somehow you have to [00:43:00] keep those things separate but complimentary. If you understood the, the questions as I posed it, I wonder if you have any advice for product people for compartmentalizing all of this data and avoiding the the, um, What's the word I'm looking for?
The, the, the, the cognitive biases such as recency bias from interfering with the development of, of any of these three spaces.
Roman: Yeah, sure. I mean, I, I think Paul, you're, you're right. Um, product people, um, One of the big challenges in is in product management is the amount of information that we need to deal with, as you mentioned.
I think it's related to the diversity of tasks and the amount of different tasks that we have to attend to. Um, and so, um, you know, what I think is really helpful is to, um, [00:44:00] is, is, is to, to really be clear on, um, How you want to add value, how you want to create value with your product. And you know, that goes back to having a strategy, having a validated product strategy and, um, and using that strategy in order then to guide the detailed product decisions.
Um, so for me, I mentioned this earlier. The product strategy does strategizing generally and creating and evolving a product strategy means, um, involves saying no and, uh, it, it mean, it means focusing. And I do think that focus is a good thing. Uh, you know, we can't do too many things at once or if we do so we spread ourselves too thinly and, uh, You know, wear ourselves out.
It's not, uh, good for us as individuals. Um, it, it also, it's not good for our organizations. It reduces our productivity. We keep task switching. Um, we, uh, lose, uh, our ability literally to focus. Um, so yeah, I do think it's, it's very [00:45:00] important to say no and be, be, be, be, be clear on what is, what is crucial, what is critical, really, uh, for my product to create value.
And that allows me then say to collect, uh, use the right KPIs and collect the right data. So one of the issues I had many years ago when I started working with, um, the, uh, person in my business who helps me with internet marketing and seo, is that, you know, she recommended to me to look at all that data.
And I say, well, yeah, Cindy, uh, I, I appreciate you suggesting that. Uh, but why? Why do we use all those metrics, ? Why would I need to look at all that data? How does it help me? I only wanna look at data. If I see a business impact, if I see a product impact. Otherwise, I, I'll choose deliberately to ignore it.
It's like, yeah, other people might look at this, but if it doesn't help me, I don't wanna waste my time on this. So I do think that, you know, being an effective product person does require. Us to say no. And again, as I said, for me that should be, should start with a strategy. And it should be [00:46:00] guided by a strategy.
It should be guided by, you know, what, how do we define value for a product? And what is our approach to creating and maximizing that value that should really guide all our work. Um, I mean, the thing around cognitive, uh, um, About bias is, yeah, cognitive bias is, um, you know, I think all human beings suffer from that.
So it's not only us as product people, not only us in product management. Um, but, but one, one way to, to deal with it is to bring awareness to it and, um, you know, reflect on our, uh, thinking processes and, uh, on our ideas and why we maybe, Hold certain beliefs and, um, you know, why we maybe evaluate data in a certain way.
Um, and the other, uh, um, suggestion I have, and I think, uh, I, I made that recommendation in the book is to, uh, evaluate data collaboratively together with, uh, key stakeholders and development team members. Because often then the biases, [00:47:00] um, uh, uh, balance each other out. Um, or, you know, I might overlook a piece of data because I have a confirmation bias.
But somebody else might say like, Hey, you know, why haven't we discussed this piece of data that looks really interesting? Let's, let's dive into this piece of data here. Um, so yeah, those, those will be my thoughts. ,
Justyna: thank you. I, I think, you know, thank you. I think that it's really, really useful. That helps.
The previous conversation that they had with Paul regarding the cognitive load and how to deal with that and. I believe that our listeners got already a lot of value from, from our interview and all the answers that you gave. But is there anything else that we didn't ask you and you think that, uh, it might be important for our listeners to know?
Roman: For me, uh, strategizing, uh, and in, um, creating, developing a product strategy and product roadmap? Uh, Uh, important skills, [00:48:00] but the skills like many other skills in life and many other product management skills that are worthwhile. D um, developing and honing and deepening. Um, and at the same time, sometimes do require some patience and some, um, persistence, some, some endurance in order to, to develop them.
It's the right level, so, Encourage the listeners, um, you know, to reflect on their own strategizing skills and honestly think about is there an opportunity to deepen their knowledge and improve their skills. So maybe close some gaps, uh, in their knowledge and skill. And at the same time, uh, not to put themselves under pressure, not expect too much, too quickly.
Um, But you know, really, you know, uh, have a targeted learning objective and say, oh, maybe, you know, I'd like to try out outcome based, goal oriented roadmaps. And, you know, I experiment now with this, um, roadmap format for the next, say, three months or something. Or maybe I'll like to get better at. Joining up my product backlog [00:49:00] and the product roadmap and, uh, use a product in my product backlog.
And that's what I'm gonna focus on now and that's what I'm gonna experiment with. And I'm gonna read up on it or gonna watch some videos or, you know, I dunno, you know, take some e-learning courses or, you know, uh, live instructor, let training courses, whatever it might be. Read some books, block post articles, you name it.
Um, But so, you know, in order to really kind of deepen your, your knowledge and understanding around, uh, strategizing and road mapping, if, if that's what you want to focus on . Um, so yeah, really, really kind of, you know, um, uh, look at strategizing and, and roadmap mapping as a, a, uh, a journey. A journey of of, of, uh, learning.
And, uh, you, you. Continue to deepen your, your understanding and your skill set in that area. That's, that's what I'd recommend,
Paul: Well, I hope you enjoyed our conversation with Roman Pitchler and, uh, if you wanna get the book, there'll be a link to it in the show notes, but we had a rather long interview. [00:50:00] This is gonna be a long episode, and so we're going to wrap it up pretty tightly here. Uh, although Houston, I think you've got an announcement for us.
Justyna: Oh yes, I have the announcement because you know, if you are tired of listening to our ideas, we actually have a space for you when you can bring your own ideas. So as you probably know, me and Paul, we are the organizers of the yearly ACE conference, and in May it will be that. 12 edition and if you have something to share, feel free to submit your talk proposal or workshop proposal in our call for papers.
I can guarantee you that we are going to read it, that we don't do the call for papers just for the sake of doing it, but actually. Part from our keynote speakers. All the speakers are from the call for papers, not only our friends and family , because that would be a boring conference. So feel free to go to the dot com and submit your proposal.
Paul: And two things that [00:51:00] ACE does that I'm really proud of that I'd like to just highlight here. One of them is the Fresh Faces Program, which was Houston's idea, and we've always tried to nurture new talent, but a lot of people are really intimidated by the idea of getting into public speaking, but they know it would be good for their career.
And while. We, of course, are very concerned about the quality of the content that we provide. We also feel that giving new speakers an opportunity in a platform is a, a service to the community. And so the Fresh, fresh Faces program encourages people who have never spoken before. Let us know when you submit that you're interested in the Fresh Faces Program, and we will do our best to support you to make your first speaking experience a good one.
And the other thing I'm proud of, and this is not something we've always done because. We barely broke even. We even lost money in the early years sometimes. But as soon as Ace started actually making a profit, we started paying all of the speakers and very, very few tech [00:52:00] conferences do this. We don't pay them a lot, but the idea is that we, we should, we demonstrate by sharing our profits with the speakers that we value.
What they're bringing and we value the time that they're giving us. It doesn't matter whether they're some big name keynote speaker or a novice speaker. We even once had a woman come. And, and do a presentation with her child. And we paid them both, which I think might technically be child labor. Don't tell anyone
Um, but in any case, so, so those are two incentives to submit your ideas. If you've got an experience worth sharing. If you've got an idea with sharing, submit your ideas to the ACE conference and we will consider them regardless of whether you have public speaking experience or not. So we've got a lot more, but we're gonna save it for the after show.
For those of you who don't know on the regular podcast, the after show is the show we do after the show. It is more relaxed. We talk [00:53:00] about work stuff, we talk about book stuff. We talk about agile and lean product stuff, but we also talk about a lot of other stuff. It's, it's a more relaxed show. It usually runs.
30 minutes to an hour unless we go crazy and go super low. Oh, yes, . And, uh, it is available to everyone who helps to support the cost of this show. Even, even if you're just a buck a month Patriot subscriber, you have access to the a after shows. I mean, obviously the ones who give us more than that, the more you give us, the more we love you because, That's just the way Commerce and the heart works.
But, um, but even for a buck, you get the after show. So if you wanna hear more of us, you can go to our Patreon accountant and, and, and support the show and there'll be a link to that in the show notes as well. So thank you all so much for being with us today, and, uh, if you, if you're not a Patron subscriber, we'll see you again next month when we are going to be reading.
What are we gonna be reading next month? Yes,
Justyna: the next month [00:54:00] we are going to read Leadership By Design A Guide to Transform as a Leader by aga. And I think that it's great idea because we never had a polish out on the podcast.
Paul: Well, there aren't a whole lot of Polish authors who write in English, but um, yes, I'm excited about this too because I mean, it's kind of.
I'm not Polish, but I live in Poland. Usin is Polish, but she doesn't live in Poland. But, um, but yes, indeed, we haven't showcased the work of, of our local community. And uh, I'm, I'm happy about this one too because I, I think it's time we did something a bit more generalist. We've done a lot of product stuff.
We've done a lot of, lot of, we did some culture stuff, but I, I like the idea of everyone, whether everyone who's a change agent, everyone who's a scrum master, everyone. What, what, what was. Leadership. What was the definition of leadership that, uh oh Helped me here? Houston, that Apri,
Justyna: uh, came
Paul: Miles. [00:55:00] Mills, yeah.
April Mills. What was April Mill's definition of leadership.
Justyna: One of things that she said that the leader is the person who, like, as a leader, I will do what I can, where I am with what I have every day, and that everyone who impacts someone else. And the circumstances has a capability to be the leader because there is interaction with them.
Yes,
Paul: exactly. I, I, I think we, we all can imagine a better space than the space that we're in. We can all can imagine how we can contribute. To making the spaces that we're in better. And so leadership, I think is, is one of those topics that is absolutely relevant to everyone, whether leadership is a formal part of their job or not.
And so I think it'll be a great way to kick off the new year with a discussion about leadership and, and a new book about leadership by one of one of our own local authors. So join us on January 1st [00:56:00] and between now and then, have a wonderful holiday season.
Justyna: Have a wonderful holiday season. Goodbye. Bye bye.