Roadmap or Alignment, what's important? | Holly Donohue

In episode 17 of Talking Roadmaps, Justin Woods interviews Holly Donohue, CPO at Purple. They discuss the significance of roadmaps versus alignment in product management. Holly shares insights on balancing strategic planning with team coordination, leveraging her experience in startups and scale-ups to enhance team dynamics and product delivery. The conversation delves into practical approaches to improve collaboration and continuous improvement in product teams.

Holly is CPO at Purple, embracing her passion for building products and developing teams. Holly leads multi-disciplinary digital teams to create world-class products. She has worked across diverse industries building product strategies, teams and processes to deliver commercial and customer value. She is never happier than working with a startup / scale up, putting in gentle structure and driving focus.

Holly uses her rebellious spirit and thirst for learning and knowledge sharing for good, transforming ways of working and maturing product, design and engineering teams based on a foundation of collaboration and continuous improvement. Holly co-organises ProductTank Manchester, believing in the importance of giving a voice to the product community and the opportunity for knowledge sharing and is a regular speaker at conferences and events.

“The important thing is the conversation around it, not the document itself”

— Holly Donohue

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 Andre Albuquerque, VP of Product at Kitch, Founder of One Month PM and much more. So watch out for Episode 18!

• Transcript

  - Hello and welcome to the, "Talking Roadmaps Channel." My name's Justin Woods and I'm one of the co-hosts here. And today I'm joined by Holly Donohue, one of our special guests. If you're new to the channel, we're here to talk everything roadmaps. From tools and techniques to industry experts and expert practitioners such as Holly as well. If that sounds interesting to you, please do like and subscribe. If we say some interesting things during the session, feel free to pick those out and put some comments there. And if you have some questions to myself or Holly as well, feel free to put those down below. Also, if you'd like to get in touch to get onto the channel, that would be fantastic. We're always interested in hearing different perspectives on roadmapping. From people that absolutely love them to maybe some people that have had some challenges with them in the past. You know, we're here to hear all of those different perspectives. So this session is really for those people that are interested in the art and the science of roadmapping, and it really is a little bit of both. And today I'm joined by Holly Donohue, who's the current Chief Product Officer at Purple. Holly, welcome. And tell us a little bit about yourself.

  - Thank you. Yes, I'm currently working for Purple. I've been there for two months now as Chief Product Officer, as you say and whilst I'm there, so I'm not the first product person there, but I'm the first product leader there. So we have a couple of product managers there, couple of UX designers, and I'm really there to mature the team and bring in new product management working practises. And before that I was working for Co-op Digital as a Product Leader. So I was working with the digital teams there. Obviously the multidisciplinary teams, primarily on the website. And before that I also was working for Aquila Heywood as a Product Leader, and they're a FinTech company.

  - Awesome. So a really good kind of experience in different industries, but also a long experience in product management and now time to be able to put a lot of that experience into shaping a new team. Which I love. It's something similar that I did at former companies and it's great to be able to kind of get in, build a team, build that culture. So I'm really excited for you. That's fab. And you may have a guest with you as well today. So apparently she likes roadmapping too, is that right?

  - Yes, so my cat, Amy, may well make an appearance. I think she might have wandered off now, but she does like to join calls such as this, so I'm sure she'll show her face at some point as well.

  - Love that. Absolutely. Well, you know, we love animals and we love product experts on the channel alike, so fantastic welcome to her as well. Holly, I kind of wanna get straight into the nuts and bolts of it. Obviously being a talking roadmaps channel, we love to talk about roadmaps and where they're used well and maybe sometimes where they're not used well. I'd love to understand, first of all, kind of being a product expert and a product leader, what your thoughts are around the purpose of a roadmap? What does that really do for you in your function?

  - Yeah, so I see roadmaps as being the current view of how we're going to deliver the product strategy. And it's all based on what we know today. So it's based on the best information that we have right now. And I think a lot of the purpose of it is a communication tool. So it's really around understanding what we're going to do, but then being able to actually communicate it to people internally and as well as an external audience if you're in B2B as I am so to your customers as well. And I don't see it as an artefact in isolation. I think it needs to sit alongside of the artefacts. So I like to use a product pipeline. Which I can talk a bit more about in terms of actually understanding a bit more the logistics of how the work is moving through the team by, through an upstream process in terms of validating is this the right thing to do in a downstream process? And also a delivery plan, which is really the kind of short-term view of what are we actually going to be releasing over the next say, couple of months. And that helps when you've got dependencies within internally with other teams. So with marketing, with customer success and with sales, so that you can really start to make sure that you're ready when you're actually going to be releasing something. So it sits alongside all of those tools in order to help you communicate what you're going to be actually delivering. And I also quite like to see it as thinking about, it's a moving tool. So it's not something that's meant to be set in stone. It's all around and that's why I keep saying, this is based on what we know today because it's a learning tool as well. So it's a really good opportunity to be actually testing with your stakeholders and with your customers, is this the right direction? And the right thing to be doing? So you can kind of use it as a prototype almost in that way as well.

  - Yeah, that's, I mean, what a well-rounded answer, Holly. I'm nodding furiously with you here, but I mean that makes total sense. You know, the fact that it's not the be-all and end-all of things that it fits in with a product plan and not in isolation. I think that's something that I learned quite early on was that, you know, the roadmap is often what the stakeholders want to see, but it's not everything that they should be seeing and it's just something that is for communication and alignment, but it sits in the context of a much wider set of documents or artefacts that support it. I really love that answer. And you also mentioned some of the different audiences of that. So in your experience, have you had different views or what are kind of the different audiences of your roadmap? 'Cause you mentioned a few.

  - Yeah, and actually I liked what you said around stakeholders will often ask the roadmap and I think that's really true because that's the language that they have. A lot of stakeholders won't have come across different terminology of say a delivery plan or a pipeline. So I think if somebody asks you for a roadmap, have a think about what are they really wanting to see? What information do they really need? Because it might not actually be the roadmap, it might be something else. So in terms of audiences, you know, I think, and it depends on B2B, B2C audiences as businesses as well in terms of your audience thinking. And there are some commonalities as well. But certainly in my context, sales are going to be a really big audience because they're gonna want to know, what's coming up in the pipeline? What can I sell? How can I, you know, meet my sales quota? And how can I get my commission? So they're gonna be really wanting to know how can I keep this customer happy so that, you know, I can actually meet my targets? And customer success is another big audience because they're going to want to know, are we going to be addressing this thing that my customer is asking me about constantly and making sure how can we make sure that we retain customers and what's playing into that? And of course you've got a lot of functions which are going to be supporting you actually releasing those features. So marketing are gonna be there wanting to help you get those messages across to customers and help you get customers using your products and bringing leads into the company. And you've also got your support team as well, usually probably part of customer experience and they're gonna be wanting to know what they're actually going to need to support and how can they make sure that if something does go wrong, that they can get that resolved. And of course I think the products and engineering team themselves are a big audience for this. You know, this is a really good way of opening up that conversation with engineering teams around what's coming up? What do we need to start thinking about? And involving them early in that process is really advantageous because you want to be understanding what the key technical risks are. So at Purple we work with quite a lot of new technology that's still emerging and evolving and perhaps isn't always quite where you want it to be or quite where you think it is. So we've got a lot of technical risks that we carry. So we want to be making sure that we're involving engineering really early before we actually start development work to understand what's the feasibility? What's the technical feasibility of what we're proposing? Is the technology there in order to be able to deliver the outcomes for the users that we're expecting? And of course customers, I forgot that kind of important, making sure that we're actually communicating that to customers as well.

  - Yeah, absolutely. And what a diverse set of stakeholders. And one of the things again that I kind of learned sometimes the hard way is that the roadmap that we create is the one that we think we want to show, but it's not often the one that they want to see. And so you know, that you've mentioned a wide spectrum of different stakeholders that including external. One roadmap's not really necessarily gonna serve all of those people in the way that it needs. I love your empathy with the engineering teams. Often they're getting really stuck into the minutiae of things and your roadmap is their opportunity to take their head up and look above the parapet and see where we're going because often they're so stuck in the day-to-day. And that can be really motivational for those teams as well. So I love your empathy for the different stakeholders that you need to serve.

  - Yes, that's why I kind of look at having different artefacts as well, which were kind of variations of a roadmap. So with the engineering team, I like to use a pipeline process which will have actual separate columns of where ideas are sitting in the columns. So that can distil up into your roadmap, but it also gives you visibility of, it's a Kanban board so it gives you all the advantages of having Kanban in terms of having work in progress limits and being able to manage the flow of work and see where you've got bottlenecks and see where you've got work queued up. So by having that Kanban board view of your roadmap, essentially you can have that conversation with engineering. So you might have, in my current company, we call the column solution validation and that's where we want to be. That happens before we're committing something to development and before we're agreeing to prioritise it in the queue for development. But that's where we're actually checking for feasibility and we're also making sure we're checking for viability and desirability before it gets to the point of actually agreeing that yes, that's now gonna be in the prioritised queue of work for development.

  - Yeah, I'm really glad you mentioned that actually, because I think that level of transparency and those statuses can be so valuable in terms of communicating expectations with the business on what your flow is. It's not just in development or in a to-do in development done. This is kind of like, "Look, we're gonna be doing some work up ahead of this and this is really important." And just those labels can be so vital to communicating those expectations and reinforcing your process. We might explore that one a bit later actually. 'Cause I think that's really interesting. We've talked about, again, lots of different audiences here. From your experience who's kind of been the owner of that roadmap, who owns that?

  - I'd say the product team own it in terms of making sure that it's updated and maintained. But of course that doesn't necessarily mean that the product management team have the full kind of say in terms of what actually gets on there. I like to set up companies up in a way that the product team are the recommenders, but then you'll have a product SteerCo or product boards or product council. I've heard it called many different things, which are usually a set of senior stakeholders. So it's your exec team and you want representation in there from sales, the sales team, from customer success, from marketing and obviously the CEO to actually steer what's getting onto that roadmap because you want to have those voices in the room because if you're starting to think about what value will each piece of work deliver? And starting to think of that in terms of what customer value will it deliver and what value to the business will it deliver? If you're starting to talk about the value to the business that it'll deliver is that will increase sales. You want your chief revenue officer to sign up to the fact that if you're gonna build this, this is going to, he's going to deliver sales or she's gonna deliver sales. So you want to make sure you've got those voices in the room to kind of have those debates and conversations.

  - Yeah, and I love the fact that you're pulling those people together into a room to be able to talk with them. You know, sometimes there can be a bit of shuttle diplomacy between the different areas and you do those individually, but sometimes when you need some big decisions or just that feeling of bringing people together. I often hear that product managers are the glue within these things. And that's kind of a example of kind of one of the things I've heard and really liked. You know, it's one of those metaphors that we are that glue that brings people together that sometimes wouldn't speak without us bringing that together.

  - Yeah, and it helps to get, your buy-in to the... It helps to get the buy-in from all those different areas. So then further down the line when you're having those conversations about why you are doing certain things and you're not doing other things. If you've got the buy-in from those senior stakeholders because they're all in the room together and signed up to that plan, it just makes those conversations a lot easier as well.

  - Yeah, exactly. And so it sounds like that's, again, another important part of your roadmap. Which is actually we're starting to learn is more of a roadmapping process. The roadmap is one view of that, but actually you've got a whole process together that sounds like a really important thing that again, some new product managers or new people to roadmapping might not an issue think of. It's not an isolated slide in a PowerPoint. It's actually a whole part of a process and the communication pattern that you have to.

  - Yeah, absolutely. You need to be thinking of how is that work gonna flow through the roadmap? It's very easy to kind of see roadmaps as this static document, but really there's the whole kind of machine behind that making that roadmap work and actually deliver what's on there. And I think, you know, products, teams or products and engineering teams can often be described as a black hole of communication because unless you are actively really going out there and really putting in the effort to communicate out that roadmap, it's very easy for it to become invisible. So I think one of the really key things is that you really have to actively think about how am I going to bring this roadmap to the different stakeholders around the business and externally so that they've got visibility of it? Because then they're not gonna come to you very easily. It's all about how are you going to put that message out there.

  - Yeah, that's it. And the ownership is really on us to communicate in a way that resonates with them, not in a way that we kind of create the deliverable or create the view and expect them to interpret it in the same way. There's been some recent conversations on the channel about things like MVP and what that actually means and you know, we can throw around the word roadmap and expect other people to understand what it means, but to many people it looks like a delivery plan and that's obviously where a lot of the problems can happen.

  - Yeah, and I think I've really tried to come away from using that term MVP as well because I find it has a completely different meanings to different people. So in the product team, MVP means the minimum products that you could be used. Whereas to sales, they'll see it's a minimum saleable product. And those two things aren't necessarily the same thing. So if you just kind of use MVP, people already have completely different interpretations of that. So I find it's actually not a useful term. It's better to, you know, the principle is right in terms of thinking what's the minimum we should build in order to test? Of course actually you really want to be thinking what's the minimum we need to do to test before you build as well? So how can we actually validate this strategy before we build? But I think if you just use MVP it immediately misaligns people. So it's better to, I train these iteration one and this is what is in iteration one rather than a generic term that actually doesn't tell people what's in it.

  - Oh, that's gold right there, Holly. I think that completely makes sense 'cause a lot of these buzzwords get bandied around and then people think they understand what they mean. But there's, you know, outside of maybe product, there was a different interpretation of that and it is not the minimum saleable product 'cause if it was, we might call it that. So iteration is a really lovely way of being able to put that and maybe disambiguate some people's perceptions of that language. That's gold right there. Thank you for sharing that with us. So we've talked about the ownership of the roadmap being that the product function. And that's not just a product manager, that's a number of people there. In terms of who maintains the roadmap. What are your thoughts, Holly? Does that sit with the same function too, in your mind?

  - Yeah, so I would say, and I like to kind of say the product managers would own the roadmap. So it depends slightly on how your product team is structured. So most recently the product teams I've been working on the product team, each product manager has effectively had their own very distinct part of the product or distinct product. So it's easy for them to own their own part of the roadmap for that. If you've got multiple product managers working on the same products or restructured in a different way, that might be harder. But I like to say that the product managers are the ones who really have ownership of making sure that that roadmap is maintained. So even me as a product leader, I wouldn't want to be the one having ownership of that because then I become bottleneck. And actually it needs to be the product managers who are hearing the feedback, they're in the details, they're looking at the data, who are able to actually maintain that. Understand what needs to be going through that process in terms of recommendations for what we're working on next. So then they have that full ownership of keeping that roadmap up to date.

  - Really nice. Yeah, and I think that's important. That's one of the things that we love as a product manager is that ownership and the accountability of something. So giving that to your teams and empowering to do them is really nice. But maybe aligning teams across the portfolio to a common strategy and approach. What do you think the relationship is between things like a vision strategy and objectives to a roadmap? In your experience, what's been that relationship?

  - I think if you're in a really mature function, 'cause we always have to talk about in an ideal world and in reality, so think if you're in a really mature function, then the problem roadmap is how your vision and strategy is going to come to life and come into existence. So in an ideal world, you have your product vision and your product strategy all documented, all publicised, and you know, everybody in the company is aware of it. And then your roadmap is your ideas and hypotheses around how you're actually going to deliver that vision and strategy and what you're going to do next in order to deliver that vision and strategy. So that's in, you know, a really mature function. I think in reality, certainly in my experience of a lot of people I've spoken to and places that I've worked myself. You might be in a position where you don't have a vision strategy documented right now or it's maybe very too tied into the business strategy. You know, there's lots of different scenarios. So it's about thinking about how can we make the situation that we're in work and then bring it then into the next step of maturity. So how are we going to grow it next? So, you know, you might have a roadmap that doesn't tie into a vision or strategy at the moment. So it's about thinking about how can we start to make sense of what's the most valuable thing to be delivering in the context that we've got and making sure that we're not ending up with a bit of a scatter gun approach where we're kind of pulling in lots of different directions and trying to do lots of things at the same time. So, you know, it's about kind of how can you then use that roadmap to go, "Actually, what are we going to focus on?" And almost start building up that strategy in a different way. In an ideal world it flows down, sometimes it goes bottom up.

  - Do you know, I was just gonna say, and in fact in my experience, it has often been bottom up. And I haven't worked for many startups, but certainly a startup is built around, they create a product first and then they need to think about retrospectively what their company strategy is as a result because a company isn't necessarily its product. And I've also worked for some large companies where they haven't really had that visibility of a strategy, but I've needed to create one for my team to help them feel like we're moving towards something and then almost try and put the scaffolding back up at higher levels to say, "This is what I think the strategy is and are you wanting to buy into that and adopt it at your level?" Because you know, often we're trying to drive our teams with a clear approach, but the higher levels don't often have that visibility. So I love the fact that you brought that up.

  - Often the challenge is you read books or you read blogs and you know, it's all great. You're gonna have your vision and strategy and then that will feed into your roadmap and it's all gonna be really lovely. But I think often the reality is very different. So it's about just understanding, you know, it's really good to have an idea of where you want to get to and what you want to achieve, but then it's thinking about what are the steps in the context that I've got with the knowledge and beliefs of the people that are around me? What's the next logical step for us to actually move forward towards that and knowing that you're not aiming to get to perfect, you're just aiming to get to better than where you are now.

  - That's a great quote right there as well, isn't it? You know, do we not trying to get to perfect, we're just trying to get to better. And I think that's one thing again that really warmed me to product management or at least creating your own roadmap is to leave things in a better place than when you found them. And to have that feeling of progress is just a wonderful perk of the job. Holly, on your roadmap, what are some of the things that you like to see on it? So what are some of the key elements or some of the content of a roadmap? What have you seen that's worked well for you?

  - I like to use the Now-Next-Later structure. So you know, that's where you have your ideas and things that you're going to build structured within what we're going to be doing now and the, in the most level of detail and have got the greatest certainty because of the usually things that you're actively working on. Next, you've got kind of a slightly less level of detail on those and then later might just be themes or kind of very rough ideas. And you know, I like to work towards having those ideas being outcome driven as well, and outcome first. So what outcome are we going to achieve? Rather than it being a specific feature. And the reason for that Now-Next-Later structure 'cause there's been so much debate about do you put dates on roadmaps? Do you not put dates on roadmaps? You know, it's because in an agile world, in an agile ways of working, we know that things are going to change and we actively want to kind of welcome that change as well. So you know, ideally we're not changing things that we're working on now because ideally we've already made those decisions further up the pipeline and it gets, you know, the further towards actually building something you get and whilst you're building the more expensive it is to stop doing something. But we want to be able to have that flexibility that if something changes or if you're in a regulated industry or even anybody can be affected by GDPR or by accessibility for example. If something changes like that, you want to be able to flex and enable yourself to meet those new needs. You know, might get a new competitor or you might discover a new opportunity or a new unmet customer need that you think is a really big opportunity but you want to be able to harness that quickly rather than having to wait for, you know, a year's worth of locked in roadmap to deliver before you can even start thinking about that thing. So that's why I like to have that Now-Next-Later structure because dates on a roadmap are just an illusion, really. They're kind of a best guess of how long it might take to deliver. You don't know what technical issues you might hit whilst you're building that. So it gives you kind of that illusion of confidence. Yeah, we've got this great roadmap for year, we know exactly what we're doing, but the reality is things are going to change and you know, there's gonna be always something new that you're going to need that you don't have visibility of at the start of the year. So I like that kind of Now-Next-Later structure, but again it's knowing that in the context that you're in, your organisation might not be ready for that Now-Next-Later structure. So you might have to do a bit more of a day driven roadmap and you might need to step people towards it. So you might be able to start saying, instead of giving you exact dates for the whole year, I'm gonna give you dates for this quarter. Roughly next quarter, this is what we think we're going to deliver, but I'm not gonna say when in the quarter. And then roughly in the second half of the year, this is what we're going to deliver and I'm not going to tell you when in that year. So you can kind of start to move people towards that Now-Next-Later structure if they're very kind of stuck in that date-driven world.

  - Oh, that's such great advice for folks that are new to roadmapping or maybe that are having some problems with their roadmapping. Almost being too prescriptive about the future but not catering for the uncertainty of things. As you mentioned, you know, we don't live in a perfect world and things change all of the time. There's things changing in our global landscaping economy all of the time. And it almost sets us up for a fail. So to be able to say these are the things that we're experimenting, things that we've got some clarity on now, I really like that approach. The other bit that you shared, which was, it's an evolution of expectations within the company. Sometimes they may have not had a product leader with your experience come in. They're used to seeing a roadmap in one certain format and we need to help them transition to that new way of being able to communicate that. That's a really important part and that's not something that a single document can do or a couple of iterations of that document. It's actually gonna be an ongoing handholding with them. So I love that you've mentioned that 'cause I think that's something that a lot of people will have challenges with is evolving the rest of the business into that way of thinking.

  - It's good to think about it just like you would in agile where user stories are not there to be the artefact in themselves. They're there to spark a conversation with the engineering team and a roadmap is just the same thing. It's not there to be an artefact in its own right and sit there looking pretty on a shelf by itself, really. It's there to facilitate a conversation and the important thing is the conversation that happens around it rather than the document itself.

  - Holly, I couldn't agree more. It's not the artefact, it's not just a single slide. It's the process and the conversations that come as a result, that's phenomenal. You mentioned the Now-Next-Later roadmap and I'm a big advocate of that work as well. We've spoken to Janna Bastow who is kind of one of the founders of that that approach as well. Are there any tools that you like to use internally or externally to be able to manage and visualise that roadmap? I think we've all used a gamut of them in our past, but any favourites for you that you use to help manage that roadmap?

  - You know there's lots of product management software tools out there these days. So you know, I've used quite a few things like Aha! and Product Plan in the past. I've not used Product Pad yet, which is Janna Bastow actually, but maybe one day, and they can be really useful for, they're designed for product managers so they put tend to put things in the format that you need and it can make it very easy. And a lot of them also do have that Kanban view now. So if you're wanting to actually show a pipeline with your upstream process and downstream process, then a lot of them come with that facility as well. A lot of them come with facility to actually gather feedback through a portal, whether it's internal or external feedback. So, you know, that's all really useful tools. I'd say sometimes though what I find is you can get all of this, you know, great stuff and make it look great in your tool, but nobody will ever come to look at it. Even though you can publish it online into notebooks. And I've tried lots of things in terms of emailing it to everybody, emailing them a link and nobody actually opens a link. So I think the thing to bear in mind is those tools are all great and can be really useful to help the product team manage it. But again the most important thing is the conversations and the communication that are happening around that. And actually the more removed it is from what other people use, the less likely people are going to, the other people in your business are going to actually use that tool. So what I've been doing more recently is actually trying to bring the pipeline board or the roadmap to where people are and to the tools that they use. So in my current company we use Monday a lot. So I've actually set up a Kanban view in Monday of our pipeline because it's easier for me to get other people in the company to go to that tool 'cause they're already using Monday. In another company we used Teams a lot. So there was a lot of kind of really it's called Patches is a really big company. I was thinking where are my stakeholders? What tools are they using? 'Cause we would've loved to put it in Miro for example even, but trying to get some of our stakeholders into Miro just wasn't going to happen. So like right, we know they use Teams a lot. They love the planner view on Teams. So even though as a product team, I don't like that tool. I'm going to put it in that call because that's where my stakeholders are and they're gonna be familiar with that and they're gonna be comfortable with that. Whereas if I put it in Miro, I know it's gonna cause friction because that's an unfamiliar tool and they had low views of it and didn't like it 'cause it was different to what they were used to. So I think sometimes it's actually just kind of working with what you've already got and looking at where are my stakeholders, where's my audience? And trying to put it in the tool that your audience are familiar with, even if that might not be an ideal tool for you.

  - That's wonderful advice. I absolutely love that. You know, being a product manager, we don't often have the tools that we want to use. We often, the first roadmapping tool that people use is Excel or PowerPoint 'cause that's what's accessible to them. But then saying that we bring the roadmap to your stakeholders because it's their understanding of what you're doing that's important. Not your convenience of creating the roadmap. So I've not heard that before, but that's really resonated with me. Rich Mironov was on the channel a couple of episodes ago talking about the fact that these tools are great, but often, you know, the links aren't shared or aren't viewed. And so bringing those roadmaps to your stakeholders in their language in a way that they're going to be able to access it the most is really the purpose of that roadmap is communication alignment. And if you are not communicating or aligning on a system that they know, then that completely makes sense. And it's also, you know, the different tools that we have. I'm often asked, you know, what's a good roadmapping tool? And it really depends on where you are in that journey. You know, there's nothing wrong with PowerPoint or Excel in order to communicate it at the beginning. A roadmap, a well-formed roadmap is better than a no roadmap or a roadmap that's created using a tool that sets you up with dates and a fail. So it's really about evolving that together. But Holly, that's a really wonderful way of thinking about it. Bringing the roadmap to your stakeholders is where you've found really great success.

  - Means that they're gonna be more engaged in it because it's something that if you introduce it in a fancy tool that's very unfamiliar to them, it's harder for them to get access. You're already creating friction and you're already creating people to feel a bit sceptical. Especially if you're in an organisation where you're doing transformation. You're effectively introducing a change just by introducing a different tool that people aren't used to. And that can create bad feeling and friction. So you want to try to minimise that as much as possible. And what's actually not important is the tool that you are using, but what is important is the content of that roadmap and having those discussions. So, you know, focus on the thing that's important, which is how do you make the best chance of getting feedback into that roadmap and people engaging with it? And you know, actually the tool you're using is kind of less important.

  - Absolutely. Absolutely. And viewers may find that surprising for me having worked for three years for a roadmapping tool and being a consultant in that space. But a tool is there just to expedite process and it's the process that really is people following and communicating. So I completely agree with that. You know, I think where we've got some problems that a tool really can help with. Maybe that's lots of dependencies or a large portfolio that needs some synchronisation across it, fair enough. But yeah, what you've just described really deeply resonates with me. So I love that of a Wednesday morning. We mentioned, so some of the best practises in roadmap. What are some of the biggest mistakes you've seen people make in roadmapping?

  - I think not sharing it. I think assuming that because the roadmap exists, people know what's on the roadmap and not actually actively sharing it. I think it's that thing again of expecting people to view it and you know, it's like kind of, "Oh well, I've set up a notification so if something changes in this tool, it'll email that person." Like, well I know I for one I always set up all my email inboxes, so system notifications just go in another folder 'cause I don't wanna see them 'cause I'll just get spammed all day with them. So, you know, I think assuming that people will know that the roadmap's there, even if you're not actively sharing it. I think the really important thing is to actually actively go to those team meetings. So go to the sales team meeting and take your roadmap and go to the customer success team meeting and take your roadmap because it's not going to get there by osmosis. And making sure that you've got that shared understanding of what's going to be delivered and when. And again, using those terms like MVP. Yet the MVP's going to be delivered by this date. You are actually not setting a good enough expectation there because we've already said around people have different interpretations of that meaning. So don't leave things up to ambiguity. Make sure it's really, really clear. This is what's expected and when. This is what it's going to cover. And I think the other thing is, and it's not really a mistake, it's probably a maturity thing again, is where the roadmap is all based off gut feel or it's based off the hippo's opinion. And it's funny now I've kind of become more senior in my role, I'm very conscious of I need to make sure I'm not being the hippo now. So really making sure that the decisions that we're making are based off the best information that we have. So the best data that we can get, which might not be very much. You know, I've worked for many organisations, including ones you'd expect to have really good data. Which actually don't have great data. So making sure that those decisions are based off what you can get hold of at the time and making sure that the decision is based off the best user input or feedback that you can get at that time. And again, to start off with that might be via sales team or a customer success team. Hopefully every time you can get to that to the point where the product team are speaking directly or the UX team is speaking directly to customers and doing that research. So I think it's kind of, again, it's that thing not aiming for perfect, but aiming for what's a bit better from where we are now and making sure, "Right, okay, how can we make this a bit more objective?" And making it a bit more objective might even just be the act of writing down, well what value do we think it's going to deliver? Even if that's just based off desk-based research. But starting to bring that into the decision.

  - I love the conversation around, you know, just again, circulating with the people. It's a communication document or a communication tool and an alignment tool. Sharing it with these people and getting that feedback and just making sure that it's visible. You know, we all get received notifications, especially from these tools, but it doesn't mean that you can't assume that just because you've sent an email to somebody that they've read it and understood it in that way. So Holly, I love that sort of thought around it. And what sort of anti-patterns do you see maybe on some roadmaps in the past? So some bad practises or bad habits that you've seen people adopt with roadmaps? Are there any of those that come to mind?

  - The thing that springs to mind on that is the whole, it's on the backlog saying, so this is where people come along and say, "Where's my feature?" Or, "I want this feature." And, "Yeah, we'll put that on the backlog." And that feels okay at the time. But what happens is you end up with building up this growing expectation where to you being on the backlog is something that means to you, yeah, it's probably, we're probably not going to do it or we're not gonna do it anytime soon, but to the person it means, "Oh great, it'll be the next thing they work on." So I think, and again, it's an ambiguity in communication. It's making sure that it's really clear actually, "This isn't going to get done." So it depends how progressive you are as an organisation, as to how comfortable they are with this. This is going in the bin. Another kind of the interim step often is this is going in the ice box. So having a concept of an ice box where you put ideas in there, which you know you're not going to do this quarter and then you review the icebox, say on a quarterly basis and then you look, are there any things in the icebox that we need to now bring into the next quarter? We used to actually call it a bin and then we used to call it the rummaging in the bin session. So we'd have a rummage in the bin every quarter and we didn't bring one single thing back from that bin. There wasn't a single thing that we thought was more important. And once you've done that a few times, people are like, "Oh yeah, we never go back in the ice box." And we didn't need to do the rummaging in the bin session anymore because people became comfortable and our exec members became comfortable that actually we're not throwing things away that are important. But if you can do that and you can set that communication. It's a difficult conversation of actually, "We're not going to be doing that this quarter. And these are the reasons why, because actually we need to focus on X, Y, and Z because that's our strategy. That's where our biggest opportunities are." This remembering that, acknowledging that the thing that that person's suggesting is valuable. You know, this is a valuable thing to do. This thing is more valuable and that's why we can't do this thing. Or the thing that you're suggesting has this cost and it means it's not going to have a big enough written return on investment. But often, most often the ideas that people are suggesting are valuable. They're just not the most valuable thing.

  - And that's so important, you know, getting the business to feel listened to, but helping them to understand the priorities and that it's not that it's not a good idea, it's that we need to keep focused. And there's a real art behind that as a product manager to have those conversations. So is there a pet hate that you don't like to see on the roadmap or that you don't want to see on the roadmap? Something that's kind of really kind of irked you before and you just say to your teams, "Actually we're gonna do this differently."

  - It's the thing that's I've come across the most is that kind of we're gonna lock it down. I think I worked for an organisation where it was constantly, right, we've locked in the roadmap, it's locked in for the next year. And every time I used to should and go, "Ooh." because I just knew that it wasn't locked in at all. I knew that and things did change and there was always gonna be something else that came along partway through the year that was more important and needed to, shouldn't have everything out. But then that meant that you were late delivering the other thing even though we'd agreed that was the most important thing. So I think, yeah, that idea that you've got a locked in roadmap just doesn't ring true for me because we know that things are going to change and we need to have that flexibility to learn as well because we want to be able to deliver iteratively. So that means we want to be able to deliver something and learn from it and possibly go back and deliver more on that and possibly do another iteration, but we won't know until we've done that as to whether that's the case. The other thing I guess if you're scheduling things, that's probably a good point, if you're doing iterations and you've got like iteration one back to back with iteration two, back to back with iteration three, back to back with iteration four. Great that you're breaking things down into small deliverables, that's brilliant. But have you got that learning cycle in for making sure that what you've learned from iteration one is then feeding into iteration two? Because it sounds like you've not got that feedback cycle and if you're just delivering iterations back to back without actually having any way of learning from them.

  - And what we're setting ourselves up for a fail. 'Cause we think that's what stakeholders want to see, delivery, delivery, delivery. But actually by showing them that's your process or by showing them that process, they think that is all of your process and that's really detrimental for us. It does us a disservice, I find. So yeah, that's a great answer, Holly, thank you. What about being a product leader and yourself? Is there any advice on roadmapping that you listened to or any kind of resources that you use or recommend?

  - Early in my career, I know we're saying Janna Bastow was a guest on here and I think I remember reading an article that she wrote that really shapes a lot of my views I think. So, you know, I think that's how I learned was spending quite a lot of time reading blogs and reading probably less books. I did read a lot of blogs on roadmapping. Speaking to other product managers about how they work. I had the privilege of working with some really good coaches as well. So understanding from them and trying to get the most information out of them that I could as well and asking them lots of questions. So I think it's kind of pulling all those things together and then, you know, I think it's that thing again, there's no perfect way of doing it. And if you read a book or a blog, it will often describes this is how it should work in an ideal world, but there isn't a perfect way of doing it. So it's about taking on and understanding different ways of doing things and then trying to find the way that works best in the organisational context that you're in. And experimenting with it. And you know, I've definitely learned now that whenever I introduce things I always do a framing where I say, you know, "We're trialling this and we want your feedback. We can change how this works." So that you're setting that expectation that this is going to evolve. Especially if you're in an organisation that perhaps isn't used to evolving processes or kind of consciously evolving processes, just kind of setting that expectation up front that this is something that you're introducing is going to evolve. And I think it's, yeah, so I think it's kind of just gathering information from different places and I'd also say kind of, you know, focusing in on one thing at a time because I know a lot of product managers, especially early in their career who try and read everything about every single topic. So I think, you know, say going right, I'm gonna focus on roadmaps and for the next three months I'm gonna read a lot about roadmaps, I'm gonna try a few things out. That's why you really get the value and really get the learning.

  - Bringing that test and learn process of product management to our product management process and just seeing what works and resonates. Yeah, I think that's lovely and so important. You know, and focusing the control onto just, we're going to evolve one thing at a time and see where we get to that and maybe over a three month period or a quarter, that's where we're going to focus. I think that's wonderful. Holly, you mentioned something previously that I wanted to pick up on, which was kind of your pipeline. Tell us a little bit more about that 'cause that's intriguing to me.

  - The pipeline process is a Kanban board and it's at an epic level. And we have different columns. So those columns are different to every organisation that I've worked in. So what I'll usually do is sit with the products and UX teams and perhaps the engineering teams. It depends on, you know, the structure of the organisation at the time. But you want to bring those people together and go what are the key steps for work to get from an idea to done? So downstream is usually fairly common. You're usually gonna have a dev column depending on how kind of agile you are. You might have a test column or not. And if you do, that's okay, that's just where you are. So we've actually got a pre-release column because we have a week after some things deployed where we make sure that all the columns are aligned and we need to give people advanced notice. So we have like a bit of a breathing space when we're release of a week, which is our pre-release column. We have like a beta column for things that we've got in a beta process at the moment. And then personally we have a measuring column before you get to done. So every piece of work has to go through that measuring column before you can say it's fully done. And then that's the downstream but upstream that kind of changes. So you know, you might have columns like idea validation, so that's where you're figuring out is this aligned to the strategy? You're starting to just pull together the top level data that you have on an idea that might go to a product SteerCo or board or council for review. And then you might look into a bit more information. So where you're assessing the feasibility, viability and desirability of something. So you might be pulling in research, you might pulling in data, you might be doing some quick spikes or proof of concepts to test technical feasibility. We work with quite a lot of hardware 'cause we work with the internet things. So you might be, for us, we might be getting lots of pricing from suppliers to understand from a customer's perspective how much might it cost. You might be doing kind of t-shirt size estimating to kind of understand is this gonna be something really big and is the return investment gonna be good enough or is it gonna be small? So you're kind of trying to understand that effort versus value. So you might be using RICE prioritisation at that point. So Reach times Impact, times Confidence divided by Effort so that you can kind of get an idea of how things are comparing to each other. And you might be doing some front design at that stage as well. So you're kind of looking at what are the different stages that something needs to move through? And because you're managing it as a Kanban board, so you'll have multiple ideas in each stage, but you want to have a work in progress limit so that you've only got as many ideas as you can handle as a team going through that process. Which means that it forces you to put things in the ice box or in the bin if you're going over your work in progress limits. But that means that you can measure your lead time. So how long it takes to get from an idea to all the way through to something being released. And when you can start to measure things like that. It can be really helpful in terms of looking at your efficiency and how fast is your feedback cycle ultimately, 'Cause that's what you're looking at is how long does it take for us to get to an idea and deciding that we want to build something so we are actually being out and us learning from that. So it's about optimising for that feedback cycle.

  - Such great guidance and that transparency with your stakeholders helps them to understand that we can't build everything. We can't prioritise everything. We shouldn't be working on everything and there is a limit and a finite, a level of resource that we're working with. Holly, that's incredible. Thank you so much for sharing that with us. So I think we're looking to wrap up the session. So I really loved chatting with you there. I'm wondering if you could just distil for us kind of your philosophy on roadmapping into just a couple of sentences? And often that's the most difficult question we ask.

  - I would say progress over perfection. And I think I'm borrowing that. So I learned that when I was at the Co-op. I learned that from Adam Warburton, but I don't know if that's from him or if that's from somebody else. But you know, I think progress over perfection I think sums so much up in terms of just thinking about it in terms of what can you learn? So start somewhere and just improve on it. You don't have to get everything perfect and learn by doing and make sure that you're getting that feedback and learning from everything that you're delivering.

  - Holly, thank you so much. I just wanted to give you the opportunity just to kind of pitch what you do at Purple or whether you're hiring for new people or whether you wanted to share us a little bit more around there. I just wanted to give you an opportunity to tell us a bit more.

  - Yeah, of course. So at Purple, we talk about making physical spaces intelligence. So as most people are gonna be product managers in software listening to this. It's really easy to explain in terms of think about Google Analytics and all of the information and data we have about the software products that we use. At Purple what we're doing is we're giving that providing that information for physical spaces so that our customers can understand how their physical space is being used. What's the customer experience? Start to optimise for a positive customer experience and also have that option to re-market and re-target people with offers that are relevant to them as well. And we also have a side where we look at indoor location services as well. So that's effectively Google Maps for indoors. So particularly thinking about at the moment, we're very focused in healthcare, but this is applicable to lots of different sectors. But you know, thinking about a hospital and a visitor being able to navigate themselves around a hospital or even staff and, you know, contract staff, being able to find where they should be within a hospital. And we also have an asset tracking part of that, which enables you to use different tags to put those tags on equipment or on patients. So somebody with dementia so that you can actually track where they are. So if somebody goes wandering off, you can find where they are. And again, with assets if somebody's pushing a trolley with medicine with a thousand pounds worth of medicine around, you know, where in the hospital that is and you can set up alerts for it to tell you where, when it's entering and leaving areas. So it's all around making spaces intelligent.

  - Amazing and probably that, you know, for what Purple do no more relevant and important than this day and age that we're going through right now in terms of hospitals, tracking people as they or being able to see assets as they come in back into the office and who's using what and capacity. That sounds incredible. Holly, thank you so much for joining me today. I've absolutely loved speaking with you. I really enjoy the different guests that we have on the show and being able to understand more around your experiences. Folks, if you've really enjoyed today's session, we'd love it if you could like this. If something that Holly or I have said that's resonated with you, please do feel free to share that with people. And again, if you'd like to get in touch, feel free to just drop a comment down below or reach out to Phil or I on the channel and we'd love to see if we can have you on speaking where Holly has done today. Holly, thank you so much again for joining us and have a good rest of your week.

  - Thanks, it's been a pleasure. Thanks for having me.