Do we need dates on a roadmap? | Petra Wille
In episode 19 of Talking Roadmaps, Phil Hornby interviews Petra Wille, a seasoned product leadership coach, on the necessity of dates on a roadmap. Petra shares insights on building outcome-oriented teams, the challenges of traditional roadmapping, and how to effectively coach product managers. They discuss the practicalities of flexible timelines and the importance of focusing on product outcomes over deadlines.
Petra is an independent product leadership coach and author who’s been helping product teams boost their skill sets and up their game since 2013.
For the past four years, her work has focused on helping product leaders build outcome-oriented product teams.
Petra is dedicated to sharing her knowledge with the broader product community. In January 2021, Petra published STRONG Product People: A Complete Guide to Developing Great Product Managers. The book has already generated a lot of buzz in the product community with Martin Eriksson (Founder of ProductTank and Co-Founder of Mind the Product) calling it “the book we all needed on how to coach and empower our teams.”
To help even more product leaders become good coaches, she developed the #52questions coaching card set in 2016.
Alongside her freelance work, Petra is the co-organizer of Product at Heart in Hamburg, Germany.
“Flip the conversation on dates, how long a heads up do you need?”
Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
Next up we have Steve Johnson, he’s a product success coach and founder of product growth leaders. So watch out for Episode 20!
-
- Welcome to Talking Roadmaps, the channel where we talk about everything good, bad, and ugly about roadmapping. Today, I'm joined by Petra Wille. Petra, please introduce yourself.
- Hey, Phil, thanks for having me today on a lovely Friday afternoon. Introduction, yeah, well, I am a product leadership coach. I'm based out of Hamburg, Germany. And I'm focusing on, as the title already says, working with product leads and helping them to become actually a great product coach themselves for their teams, for their product managers, and for whoever else they're actually line managing. And that's what I'm been, yeah, focusing on the last five years. And before of that I did a lot of head of product roles, interim style, and helped product people in coaching situations as well. So I slowly transitioned from the product management coaching into the product leadership coaching, and that's what I'm currently focusing at.
- And we also need to do mention your lovely book here, "Strong."
- Yeah, that's actually the result of this work with product leads, because I don't scale so I cannot help all the product leads on this planet. So I thought some of the things that are repeatedly topics in my coachings need to make it to a book, and that's why I wrote this little piece.
- That's why I'm a trainer and coach as well, because it gives me more leverage than being in a company. So I get the concept completely. So, obviously, we're a YouTube channel, a podcast, so I do mandatorily have to say, please do like, subscribe, hit that bell icon, join us in the comments below, maybe kind of get in touch through info@talkingroadmaps.com 'cause we'd love to have you on the channel. We'd love to hear from you and kind of join us here, maybe where Petra is at a future episode. So Petra, I know we're gonna have a bit of a coaching skew to today's conversation and I'm looking forward to it, because I think I'm gonna learn something that maybe I can implement in my own coaching practise. But let's start with some really basics then. What's the purpose of a roadmap?
- There's always in concerns here and in product management the answer is, it depends. I really do think it depends on the company you're currently working and to the context of the company. And that is the first thing, you need to figure out what the purpose of a roadmap is in your given context. Because I see so many people saying roadmap and assuming that everybody has the same perception of a roadmap, but this is most likely not the case. So that would be step number one to really figure out, okay, what does roadmap mean in this company and in this context that I'm currently living in. And then the next question is how, well, what is missing? So having a basic understanding of what the world outside of your company is seeing as a roadmap. So, I like this quote of Janna Bastow, I think she always says like, "a roadmap is a prototype of your strategy", or something like that. And that is, for example, a framing that I really love, but not all companies are ready for that view on roadmapping. Some already love a really loose now-next-later roadmap, they're happy if they're just some themes on there and if learning is baked into this roadmap already. So they're really interested in what are the next things that we want to de-risk and understand and build. Where others still think in really deadline-driven, output-oriented roadmaps. And all of us know, I think we want more of the first and less of the latter, but it really depends where your company is at and sometimes it's a bit of a change project to actually go from one perception of a roadmap to the other perception.
- So you kind of talked about a few different kind of styles almost of roadmaps there. Who's looking at them? Who's the audience for it?
- Again, it depends on your company's context. So a lot of companies that I'm working with are using it for several purposes. So it's alignment with key stakeholders and payers, alignment towards the team. So that's yeah, in alignment, so to say, what are we working on? What do we want to achieve? What are the things that we want to learn next? And then it is often alignment with higher management, your line management, senior leadership and all these things. So it could be upwards, sidewards and inwards, so to say. And that is what roadmaps should be doing. And some teams and in some companies they prefer to run several levels of roadmapping for these several target groups. So maybe the team has a bit more detailed view on things and if you talk to senior leadership, you have a high level version of it. I'm not saying that you should have totally different versions, that's not helpful, but maybe the zoom level is slightly different or the details you are talking about while talking about the roadmap is slightly different. But yeah, I think that is, that is something you always should look into. Who are these target groups? How are we catering these target groups differently? And then obviously, who's already as well interested in roadmaps are teams that do the aftermath of the things that you're doing. So, marketing, because they know that they need to run this campaign once your product changes are live and they need to know when they should start working on planning this campaign or on rolling it out. So these sales, may be because they need to update sales collateral, all these kind of target groups might be interested as well.
- Marketing is often quite date-driven. So, how do we align that with, so to say, less date-driven roadmaps perhaps?
- That's actually a super easy one. I coach people to flip the conversation. So if they are asking for a roadmap, I ask, how many weeks and months they need a heads up before the actual thing goes live, which is putting them in reflecting mode because then they're like, hmm, good question, let me go back and think about, okay, is it one week, is it four weeks, that we need to actually plan the campaign and get it out there? So what is the production time of the actual campaign? And once they come back with that, I just assure them that whatever happens, I will give them this four weeks out, six weeks out heads up that they need because I can't promise on any dates, but I can promise that we have a heads up right in time so that they can still do their job well. And that usually helps so that they don't need to work with the deadline on the product and engineering roadmap, so to say.
- Interesting, yeah, 'cause I was having a, a debate with a product marketing leader who said, well, when we do our roadmaps, they're absolutely quarter-by-quarter, date-by-date because marketing is very date-driven. I was like, I can't, I'm trying to understand how do I bring that more flexible kind of more realistic often timeline to that audience. And I love that flipping the conversation around.
- It not working for trade fairs and stuff like this because a trade fair has a date. So, if they're planning for something like that, then I need to be flexible with my planning. But usually the other approach works fine for most of the things that they're doing.
- Yeah, I guess there are some things where there's an externally driven and set date, trade fairs is an example, maybe a legislative cliff like GDPR coming in, things like that where you've just gotta hit it. We've talked about purpose and audience, who owns it and who maintains it then?
- Again, that depends a lot of, if you work in a truly empowered product team, it's a team effort to create the roadmap, to always keep it up to date and to really use it. But that's rare that you have to remind these teams because that's just what they do, right? So they need some visibility as well. They understood that the roadmap is the prototype of a strategy and usually then if it's a truly empowered team, a strategy that they created themselves. So, that's the easy bit. If you're still more in the order taking feature team approach, yeah, then it's up for a discussion, who is actually owning it, because then the team usually does not own the roadmap or at least they have to align it with the other departments or with the senior leadership. Then it's a discussion to have who actually owns the roadmap and who actually updates the roadmap. Hopefully the team has a big say even in these environments and hopefully the product people have a big say in these environments, and hopefully they get to a point where they can put learning initiatives on the roadmap as well. De-risking, so where are we currently de-risking? Discovery stuff. Plus slowly transitioning in the way of planning more with outcomes on their roadmaps. So what is the outcome that we ultimately want to achieve for our customers and for our users? And not so much what are the features that we are going to deliver. And yeah, depending on that maturity level on roadmapping, I think it depends who owns the roadmap. Hopefully, ultimately, the teams, the whole product development team including the product person. And if that's not yet there, then it's a discussion that you need to have.
- Now, you did talk a few moments ago about different levels. Is there potentially any different ownership of those different levels of the roadmap as well?
- I have not seen this being beneficial. So I would say, because the thing is with the roadmap comes a story and the story is the main part to how you're actually presenting it, how you're talking about and how you, how, yeah, how you're telling the story of, what will be improved in the life of the users in the future, right? And the person owning the roadmap needs to think about all these levels and all these perspectives, and has to think about how to tweak the stories. Think about holiday pictures. So if you've been on vacation and you show the pictures to different target groups, your family, your friends, or your parents, you're always slightly tweaking the stories, maybe more party picks for the friends and not so much party picks for the parents. And I think it's a similar thing, but it's you, you've been on vacation, it was your learnings, it's your experiences, it's your story to tell and then you tweak it to the audience. And I think talking about your roadmap is something similar. At most companies there is a bit of portfolio planning somewhere, so where teams aligning what they do and that could either be done with things like OKRs, so teams are sharing the same goals and objectives, which is lovely because there's less conflict if that is the case. And that is a totally different discussion. So, who makes sure that alignment across teams, across departments is really happening? But as already mentioned, it is usually done by, yeah, shared goals, aligned goals, and that helps to align the roadmaps automatically, magically, because then everybody is working towards the same goal and the same results.
- Perfect segue there, Petra, because the next thing I was gonna ask you is, how does a roadmap link into vision, strategy, objectives? You know, what are your thoughts?
- Yeah, my thoughts is, it's a bit like with a math equation, so you need to connect the dots. I really like how Martin Eriksson is always framing it in his Decision Stack talks that he gives or in the Decision Stack because it's always kind of the how and the why. So, if you want to go a level up, then you are asking let, if let's say you look at a roadmap and I ask the team, okay, but why are these the things that matter to you for the next few weeks or sprints? Then the answer should always be, yeah, because we try to optimise for that goal or drive this particular objective. And if I ask them, yeah, okay, but why are these objectives your objectives? They should say something like, yeah, because we are having a product strategy and these objectives are tying into that product strategy. So it's a logical, you can close the logical loop between all these different things and that is super important. If you create a roadmap it need to be an answer. But why OKRs or objectives or strategy? And how? So, it's the how to the strategy bit. So if you ask, if you see a strategy and you think about, okay, but how will you make sure this becomes a reality? Then the roadmap should be highlighting some of the answers to that, maybe not all the details because as said, hopefully learning is baked into your roadmap so you will learn along the way, but it should at least give you an idea of how you will put the strategy in practise, and how this will contribute to the objectives everybody's currently trying to optimise for.
- So that sounds like a concept almost up-chunking as we go, maybe we can down-chunk it, are there other artefacts that kind of link into it as well?
- Definitely, when I look at the teams backlog and I ask like, okay, but why are these things in your backlog? Then hopefully I can find these things on a roadmap. And again, then the roadmap to objective. So that should work in all directions, yeah.
- So let's think you a little bit about the design of our roadmap then. What are the key elements? What are, you know, we've got this artefact, what's on it?
- Ah, yeah, there's so many versions of that. So first of all, I always try to tell people there's at least two things. One is the story and the story that comes with the roadmap should come in various length and for, as already said, tailored to various target groups. So, and in the coachings it usually is way easier for the people to start with a story because words are so easy to tweak and once you found a story that you want to tell and things that you need to explain so that others can see the same bright future, that you as a product person can already see then putting it in some kind of writing or visual is usually the easier bit. So I always advise my coach if they're stuck with creating roadmaps or the product leads, I'm helping to understand how they could coach road mapping a bit more. Then I usually advise them to start with a story that the product person wants to tell. So, what are they up for? Why are they doing this? How are they tying it back to the product strategy, to the company strategy, to a company vision, to the objectives and create a medium-length explanation to that but then make it shorter. So I always ask them to do a 75 seconds elevator pitch, so to say, because that's as study show, the attention span of a leadership person when they're listening to something online. So, that's what you get. You have the 75 seconds if you're presenting your roadmap, no matter if it's your team or if it's the leadership team, you need to make sure that the things that you want to make sure land, land in 75 seconds. And then you could add detail. So, start with a medium version, then bring it to 75 seconds, and speaking 150-words in writing, approximately. And then you still could create a long version, I usually say like it's an 80 minutes, like a TED talk. An 80 minutes version of talking about the roadmap. That's maybe something you use every once in a while in a planning meeting with your team or something like this, because they need all the detail and what has happened so far and you need to remind them about the product discovery that you conducted together some weeks ago or something like that. So you need a longer version. And once you created that story then it is easier to find the visualisation of your roadmap that works for you. I like to work with what I call, and I can send illustration later, I call it the Onion Roadmap, so to say, which is without a timeline because most of the roadmap visualisations are still a bit of, in the timely manner, so to say. And even if there are no deadlines on it, people could still easily ask this question, okay but this bar is that long, does that mean that we will be finished in September? And to avoid to have this discussion. I like this Onion Chart where you can just like talk about how things are growing like trees and rings, and then the rings represent the value you're adding per, yeah, iteration for your user or for the company that's the size of the bubbles, so to say. And that is usually avoiding this, when is it finished, when will you be done with that, when can we release it? And people still see that you have a plan. So you can still say, we thought about it, we have a plan. That is the order in which we will be tackling things and we know approximately how much value this adds, but it's not in a timely manner. So that is one thing that I really like doing, this Onion Roadmap, so to say. Or I love, again, shout out to Janna, the "Now", "Next", "Later" approach where you just like put themes on or opportunities even on these three buckets of what are we investigating now, building now, learning now and what will be next and what are the things that we will doing in the future. Or, plus, adding maybe a not, we are not doing this because we already discussed it, we already discovered it, it's not an idea. It's basically something, an idea we need to kill, a not-to-do list is as important. And some companies still love to do a bit of a Gantt chart planning, especially when it comes to staffing because sometimes that's helpful for the teams. So several teams that I was coaching in the past told me, yeah, but even if we don't share this outside of our product development team, we still do a bit like a Gantt chart-like visualisation of it just to see, okay, that's the week when everybody's out for the conference and ah, okay, here a lot of people are taking holidays so maybe we should not over commit on the things that we are planning. So that is more the staffing part and then teams like to do a bit of a sequencing and sense making of if their planning is solid. But I would always advise, don't share the Gantt chart-like structures outside of your team, that only leads you down a rabbit hole.
- It is a bit like team velocity, right? As soon as you share the velocity external to the team, they start trying to compare teams and equate it to mandates and it's like, no, that's not what it's for. This is an internal planning tool and technique to allow us to have confidence in what we're saying we're going to do and can do.
- Exactly. And that's, it's the same with this really detailed planning roadmaps. So if your teams need it to have a good visibility about the staffing situation and who's in the office and available, and who's basically somewhere else, then maybe do it. You could still do it on a flip chart or digital whiteboard, you don't need to over tool it, so to say. And always start with pen and paper, even if your company is using a super magical roadmapping tool, which might be good and necessary if you're working in a larger organisation. I still would say start with a story, then draw it on a flip chart or on a piece of paper, then see if it works for your team and then maybe put it in a more detailed structure or a tool.
- You just started talking about tools, so I may as well ask you, do you have a preferred tool?
- As I'm not a practitioner for the last 10 years, I don't have a preferred tool and my clients really are working with, you name it, they have it. So, no, I don't have a strong preference for any of the tools.
- So okay, let's go into kind of the good, the bad and the uglier bits. What do you consider to be best practise in terms of roadmapping?
- A best practise and that's pointing out some things, again, is really tying it back to your bigger company strategy and objectives, that is important. Really asking this, why are we doing doing it and how will we make this a reality? I think these are two important framing questions and then not only creating the roadmap but creating the story that comes with it is super important, and find a visualisation that works in your context and that caters you well while telling the story, I think that is important. Plus, figuring out what the expectations are towards the roadmap within your company. Because as said, some use it still for staffing planning, some use it for alignment across teams, some use it for telling the story and how they will make sure that the strategy comes to life. And all of this I think is important to understand and then to say like, okay, that's the thing that the roadmaps in our company are actually needing to solve.
- In fact, it's just occurred to me, most of the use cases we've talked about so far have been internal, what about external roadmapping?
- Ooh. Yeah, not enough companies are brave enough to share their roadmaps with outside of the companies, only a few do. And usually, so at least some of the companies I was working with that did that, the users are way less critical with roadmaps you're sharing than usually the internal stakeholders. If you're explaining that well, they're really forgiving and they're super happy for the transparency and they're usually grateful to see what the company's actually working on. And especially if you're a startup, so to say, it can be actually a tool in customer acquisition to tell them, hey look, maybe the product is not yet super good but we are having a roadmap, we know what we are doing, we know how we could help you with covering more of the use cases you're having or something like that, but it will take some time. So for startups it's even a growth opportunity sharing their roadmap, but not enough companies are brave enough to do it.
- It's interesting 'cause it's something that I've always done, but I've always been in B2B, and I do wonder if there's a B2C/B2B difference there.
- Mm, I had teams in B2B and in B2C and I shared the roadmap publicly as well. In B2C, it's way more maintenance then because then they have questions about the roadmap items and all these kind of things. They use different lingo. So if you're working B2B, the lingo that you could use to talk about roadmap is a bit of standardised, in B2C with millions of users, it is way harder to share the roadmap because wordings, yeah, wordings and lingo are not aligned across UNT users all the time, so that was my observation.
- So, I'm just wondering if maybe that's why B2B, we do it a little more often, maybe not quite as public, not fully public, but in those customer meetings, in those acquisition meetings as part of that journey.
- Yeah but is your experience the same that they're way more forgiving than some of the internal stakeholders?
- Absolutely, in fact, the sales team were usually the most problematic members of the team. They would push back and say, we can't possibly do that, we can't possibly not have dates on there. And then you showed it to the customer and the customer said, cool, I can see the direction you're going and I'm on the same direction, let's get on with it.
- Yeah, yeah, yeah. That is a totally different, the question of how to make the sales team happy with the roadmaps you create.
- Again, they're one of those different audiences, right? You know, we've got, we've talked about senior execs and development operations people, you've got sales and I think they're certainly different to the customers in terms of as an audience.
- Yeah, yeah, totally.
- Okay, so we've talked about best practise. What about the biggest mistakes you see people making on their roadmap?
- Assuming that everybody knows what the roadmap is here for. So that is I think the biggest mistake because everybody's joining a company at some time saying like, we are now in a roadmapping process and then people are doing things without any alignment and without discussing, okay, what is the purpose of the roadmapping process? What are we here to do? Is it alignment? Is it planning? Is it, why are we doing this, right? So that's one of the biggest mistakes, I'd say. And then the other mistake is doing things just because they have been done like that in the past. So if you have this, still massive Gantt chart, deadline-driven roadmaps and you just keep on with that and just take it and run with it and say, tell your teams but that's how it's done in this company and that's how we need to do it. So that's another mistake. And coming with that, another mistake is being the only one fighting the old-school roadmap, so to say. So if you want change for the better within your company towards roadmaps that are a bit more flexible, that are a bit more outcome-oriented, that are a bit more forgiving when it comes to learnings and stuff like this, then I think it is important to find some allies in your companies that are willing to support you on the journey. Because otherwise it's super frustrating and hard to fight the deadline roadmaps. Yeah, and then the conversation, I often see this kind, you're not allowed to put deadlines on roadmaps, for example. And that again, because there is this trade fair every once in a while. So, should you avoid them? Yes, definitely. But is it forbidden to add it to a roadmap? Definitely not. Too far out planning is something that people are, yeah, tempted to do if they're roadmapping. So why not having an annual roadmap or we have quarterly roadmaps and stuff like this. You always could question the cycles of planning. The shorter the better, the more continuously and ongoing the better. Yeah, so, that's some of the things that I see people doing.
- Yeah, I felt the coach coming out there, Petra. It's like, well, you bring those other people, get them behind you, taking you on that journey with you to help you get there. Definitely, definitely good advice. So we've been listening to your advice on roadmapping for the last few minutes. Whose advice do you listen to?
- Ooh. That is a tough question. So there definitely are a few mentors when they're reaching out, could be giving me some feedback, that's people I'm listening to definitely. And then I have some dear colleagues that are either in the same field, so looking into coaching for product people and how to tackle that. It's pretty meta these days. So it's not so much talking products, it's often talk about how to teach product or how to explain certain concepts in product, and people that are also investigated and these things are people that I talk a lot with and to, and where I'm really, yeah, happy if they provide me with any feedback. Plus coaches, obviously, so clients are having, my clients are having feedback as well that I love to hear, that I love to act on. Yeah, I'd say that's the two groups, mainly.
- Any of those experts you have kept a name so people can look them up online?
- Yeah, as already said. So, I love what Martin Eriksson currently does with the Decisions Stack and he's talking a lot about product principles as well and how they can be the guard rails for your work. So I think this is important things and I always love what Teresa Torres is publishing on continuous discovery. Janna does great things on roadmapping. So does, I liked, C. Todd Lombardo, had a book on roadmapping as well. Yeah, and then I'm always keen to hear, obviously what Marty has to say, and his take and views on product management and what is currently going on. But equally important, the voices, I haven't mentioned this before, I'm one of the organisers of Mind the Product Engage Hamburg and we always try to bring new voices and people that are currently actually doing it because it's a thing with all of our thought leaders. We are not practitioners anymore so we see a lot of companies, we see a lot of what they're struggling with, but we are not doing it day-in and day-out with the tools that are currently the tools to use. Of course we have opinions, but I think it is even more important to listen to the voices that are currently doing the job and are currently struggling with product management. So that's always, yeah, something I'm thriving for, to surround myself with some people that are still doing the job.
- So if you had to give some advice to someone you were coaching today, they were developing their first roadmap, what would the key piece of advice you'd give them be?
- I would advise them to start seeking all the documents in the companies that provide their direction and hopefully clarity. If clarity is not a given, and that's the case in many, many companies. So you find like 12-strategy documents from different departments, for example, then starting to have this conversation about, okay, clarity is not yet there. Maybe somebody else in leadership could help me gain this clarity before I start building my roadmap. And then again, so find these documents, surround yourself with these documents, see what that actually does, bring your team along, make them see the same things. And then discuss what you as a team could add to the company's vision. Which of the problems that you see out there are maybe worth tackling for you as a team? Find your spot, find the things that you can contribute to and then talk about how you could actually do that. So that would be I think my main advice because you never start on a blank page, nobody, because usually we are employed by companies and they usually have strategy documents somewhere. Not all of them good, not all of them providing clarity, not all of them aligned across the board, but still you should start from there and see what you already get and if you can work with that.
- I think I'd add, not all of them shared, as well. They're often created at the senior level and then I go into a company and say, do you know the vision and strategy? And they say, no. And the leader in the corner says, but we have the operating plan. Well, your job's to share that with them next week then. How are they supposed to make decisions?
- That's another great thing. Once you created it, you need to make sure to talk about it. You need to explain it over and over again. I know it feels so hard being like a parrot and repeating it constantly but it's the same with strategy, right? It does not make sense to create a strategy and then put it on a shelf. You need to talk about, it needs to be lively, people need to remember it at least partially, and in which direction everybody's headed.
- So, now the hardball question for you, Petra, if you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?
- You create a roadmap to bring clarity to your thinking and to be able to talk about what you're actually planning to do as a team and how this is tying back into the larger company goals. And to do all of that, you have to understand where the company's headed, what problems are there and worth solving? And then you need to make sure that you still are able to learn while you are actually executing. So I think that would be the short summary of roadmapping from my end.
- Here's your chance to give your pitch for how people can get in touch with you, how you can help them, where they can find you, and so on.
- It makes sense to get in touch with me if you're looking to improve your product leadership skills, so to say, everybody who is in a product leadership position or in a senior product role and wants to learn more about how to run the team well, how to build the team, who to hire, how to onboard the people, how to coach several, yeah, particular product topics. And then that's me. You could buy the book first, that's the cheaper version of me and see what's in there. And if you then still want to understand a bit more about a how to apply it in your particular situation because that's what usually is the hard bid, because you have colleagues, it's maybe hard to tackle some of them then it might make sense to reach out. And you find me online, on Twitter, it's Loomista on Twitter, on LinkedIn, obviously, and then strongproductpeople.com is the domain where you can find a bit more about my talks and the resources that I'm using, and about the book.
- Petra, it's been wonderful having you here today. We really loved listening to you. Just a reminder for everyone out there, do like, subscribe, share, join the conversation below, get in touch if you'd like to be on the channel. Petra, great having you-
- Thank you, Phil.
