Are timing, timelines and deadlines all the same? | Andrea Saez
Episode 12 is our next episode. In this installment, I interview Andrea Saez. Andrea is Senior Product Marketing Manager at Trint. But that hides her vast experience working to create tools that enable product people to roadmap better at ProdPad and Airfocus. She's passionate about product, growth strategies and communication. She's a true believer that words and details make all the difference. From writing to hosting events, she loves having the opportunity to learn, talk, and engage with customers and apply product-thinking to scaling companies.
“Know the difference between timing, timelines and deadlines”
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 Nick Black he’s a founder and Chief Product Officer, who isn’t a fan or roadmaps so you can expect a lively discussion. So watch out for Episode 13!
-
- Welcome to Talking Roadmaps, everyone. I'm really pleased to be joined here by Andrea. Obviously we are gonna explore everything around Roadmaps from the good, the bad, the ugly, and get her opinions on it. Andrea, can you introduce yourself?
- Hey everyone. Thanks Phil for having me here today. My name is Andrea and I'm a senior product marketing manager at Trent.
- But that kind of just belies a lot of things behind the scenes and-
- I am a fan of Roadmaps. I love Roadmaps. I have a background in building product tools, particularly Air Focus ProdPad. I was there for six years, so I'm very, very, I know I sold myself a little short, didn't I?
- Absolutely.
- My background is in building product tools for product people. And I don't think it gets anymore made a niche than that. And for anyone in product, I think the most exciting thing you can do is build a tool for what you're trying to do for yourself. Both on the good side and the bad side, you come with your own bias, but then you also go, "Ah, I was wrong. "I learned something."
- You scratch your own itch and then suddenly realise you're itching somewhere else.
- Exactly .
- I love it. Yeah, okay, I like to start with the softball question. What's the purpose of a roadmap in your opinion?
- The purpose of a roadmap is to align your team around the direction and intention of what you're essentially aiming to do with that overall strategy. I know you've had Janna on the line here earlier and she likes to describe it as the blueprint to your strategy. And that's a great way of describing it. It's really less about, this is a list of things that we're going to absolutely do and more like, here's a bunch of things we could do. We're not really sure.
- When everyone talks, thinks of it as a plan, I always talk about, oh, it kind of is it's Plan A, but we start working on plan B tomorrow because nothing's gonna change. We're gonna learn some things we got.
- Yeah, I like to refer to it as a list of questions rather than a list of features. I think there's this trauma around the word roadmap in general and people like to run away from it. They're like, "Oh, roadmaps are bad. "They're horrible. "You should throw them out." To a certain extent I do agree. I think roadmaps in the sense of a timeline or a hard list of things that you have absolutely been pigeonholed into having to do is a terrible thing. But a roadmap in the sense of here's a list of questions that we're looking to potentially answer, see if we can answer them if they're worth answering in the first place is kind of more of the approach that we should be taking when it comes to roadmaps.
- What's the audience? Who's looking at this thing?
- Everyone. Don't limit yourself. And my product management answer is, well, it depends alongside with everyone. It depends on who your audience is and how you're gonna formulate that roadmap and present it will change but the core essence of it will not. You're still aligning your customers around what the future of your product might look like. You're aligning your business facing teams, your marketing team, your sales team or success team, your support team in understanding how they can have those conversations with customers. You're aligning your development team, you're aligning your own product team around what's happening. You're board, your leadership, everyone should have access and be able to see. I'm a believer that transparency is key and even more so when it comes to customers. Have the transparency in place because that's going to enable to have that solid relationship.
- And you talked about it having questions on there. I often talk about product management kinda lead the conversation in a company to kind of get it going aligned. And so it almost feels like the roadmap is the questions we're gonna ask in that conversation maybe.
- Yeah, the way I kinda like to formulate or present that product thinking is kind of starting with the later. If you're thinking of that now next later, and positioning those questions as how might we be able to do this? It doesn't even mean you understand the problem. You just know that there is a potential problem you might be able to look at. And as you understand the problem a little bit further, when it gets to next and you're going into discovery, then you change the question and you go, "Can we do this in order to impact," whatever it is you're trying to impact or in order to benefit whatever that benefit of that outcome might be. And that enables you then to kinda add a little bit of direction while still maintaining that flexibility around that particular question that's being asked. And then when you get to the now, you can have the answer a bit more of a solid statement. I'm still not a fan, I just wanna add to make this very clear. I'm not saying add features to your roadmap. I'm saying, once you get to that now and you have those committed resources, you should be able to communicate what it is that you're doing. That's when you have that really solid statement and you say, we are going to do this in order to affect that, in order to impact that, in order to have this benefit. And that really leads and sets that tone and that context and that conversation and you're also able to show everybody what that process and thinking looks like.
- Just unpack that for me, what's the three questions you ask of those three stages? 'Cause I think that's really useful.
- Yeah, so how might we is the later term. Can we? Can you actually do that? Is it feasible? Is it worth it? Is it viable? And then once you answer those set of questions, you can then communicate what that answer is. We are going to do whatever it is in order to whatever it is your outcome is. Just being able to, like I said, communicate that process and thinking.
- Okay, so it certainly it's question in the later in the next and it's getting to the here's the answer in the now almost?
- Yes.
- The answer to those three questions as it matures.
- Yeah.
- Cool. Now someone's putting it together. Who owns it? Who maintains it?
- The owner of the roadmap is always gonna be the product manager or I guess the VP of product, but over the highest level in your organisation might be. They are still making the decisions as to what's going into discovery? Whatever it is that you're focusing on, objectives, things like that. Absolutely the product team. I think when it comes to presenting it externally and being able to communicate it outwards, that's where your product marketing team comes in. Your product marketing team or product marketers are the communication site to product. They are going to be there to be able to help you formulate those questions or help you formulate what you could, could not be saying, how do we say it differently? How do we say it to different audiences? And then be able to present it on whatever different channels you might have to present it.
- Sure. I know I'm personally unlucky is to never really feel like I've worked with super strong product marketing. Loads are great product managers. Load of great product earners if we split the role or not. But it's always been a gap I feel in at least the people I've worked with. I kinda see people who do have strong product marketers and feel jealous some days.
- Yeah, to be honest, I didn't know I was a product marketer for the longest time. I kind of came upon it by accident, much like I became an accidental product manager. But you should absolutely consider your product marketer, whoever that person is or whoever your team is to be that strategic communication side. Not just for the roadmap but for launching new things, for communicating decisions and like I said, just being able to translate that to everybody else. I think as teams grow and as there's more work for the product manager, realistically there's only so much you can do. And when it comes to the comms your product team is there, product marketing team is there to help you.
- It's always the view I've techniques. It's about scaling ultimately as an organisation. There's only so many hours in the day. You either gotta narrow the focus of the work you do or narrow the focus of the product or part of the product you work on. Those are the kind of dimensions you can move. And that sometimes for me is where you end up with either splitting product manager and product owner or splitting product manager and product marketing. At least kinda that's how I've seen it working for me. I've usually gone the product manager doing a lot of the product marketing, but I do wonder if that was the right choice some days.
- It depends on the size of the company. I've seen product managers do it all when it's a smaller company. And it makes sense because you're only just one person or you might be a team of five to 10 and it makes sense. But as you said, as you grow, there's more work, there's more to do. You only have so many hours in the day and I am an advocate for taking care of your own mental health. Work where you have to work. Take time to yourself and work with others to get your stuff done.
- Okay, you hinted earlier at kind of having the roadmap in relationship to the strategy maybe to things like vision and objectives. And I know that you are working through the strategy and the positioning of your business at the moment. Kind of how are you interrelating those different things?
- Yeah, for instance it's going through a really interesting phase where we're adapting our strategy, but before we have a roadmap, we have to understand what that strategy is because that strategy is going to inform the roadmap. We've derived our objectives from our overall vision and our strategy. We've finished our strategy and over the next week or so we're gonna start writing out our roadmap based on what we know we need to focus both in the short term and the long term where we want to be in that future.
- Are there any particular methodologies around objectives or any particular favourite tools on strategy that you like to apply or how you kind of I guess communicate that?
- I've been working with Dave Martin quite a bit from Right to Left. I actually write for Right to Left. I write their content and their blog posts. And one thing that I've learned that's been super, super, super valuable for my team is the value concept board or the value product creation. And it essentially focuses on adding and highlighting how important it is to separate your company strategy and your product strategy. And a lot of times the mistake is made to think that the product strategy and the company strategy are the same thing. Making money is not a product strategy. That is a company strategy . And certainly you can do things around the product that align to that, but your product should not just be focused on making money. That's a business thing. The product should be focused on what is the value that you're creating for your customers. That is what the product does. At the end of the day, people get a little hesitant when I say this, but you're creating habits for people. Not all those habits are bad. If anything, those habits that you're creating should be good, should be positive, should help people accomplish something. Whether it's to do something faster, to do something more efficiently or to do something more effectively or whatever it is that the user is trying to do, you're helping them reach that outcome. And that is your product strategy is how do we help the user get value out of the product? And so it focuses on answering very specific product questions like who is your audience? Why is it important that we solve these problems? What is the experience that we wanna provide with them? And a lot of people don't or leave the experience to the end, whereas experience should be part of building the product. And the last question is, what are the behaviours that we want to influence? And then tying all of that back to your strategy, to your objectives and adding that very unique lens to the value of the products.
- Okay, we've got vision strategy, objectives linking into the roadmap. Are there any other artefacts, items kind of things that linking to roadmaps look like? Roadmaps overlaps with roadmaps?
- I'm gonna say overlap and this is a very contentious, misunderstood area of product but release plans and what are release plans? Again, another reason why the word roadmap is so heavy and so hated sometimes is because roadmaps are used as delivery plans and they're used as release plans and they're two separate documents. They compliment each other really well but they are two separate documents at the end of the day.
- Yeah, I think I've said this on the channel before, but I think John Cutler tweeted a few months ago saying, "We try to make the roadmap do too many jobs. "You're thinking that job's to be done concept. "And the release planning is one of the jobs "we're trying to ask you to do often. "And so we end up compromising, "we end up with one tool that does everything badly "instead of a couple of tools that do things well."
- Absolutely. I think they compliment each other well and you should always present your roadmap with your release plan. One is what is the direction that we want to take? What are the questions that we're asking? And then what is our focus right now and what are we accomplishing and what are we actually progressing towards in the next two or four, six weeks, whatever it might be.
- Now, we're looking at a roadmap. What are the key elements that are on this thing? What are we looking at?
- There's a lot of but I think if I were to pick one, 'cause otherwise this is gonna turn in like a three-hour conversation, but if I were to pick one is for product managers to understand the difference between timing and timeline. Timeline is the start and the end of a project. And that's why we always fail with roadmaps and timelines because you cannot predict the future. My new thing has been like, okay, let me get my Tarot cards and read you the future. It's never gonna happen. I'm not a psychic, it's not happening, but timing is very different and your roadmap should be answering timing. And timing is why this, why now? And particularly when it comes to that now column, you should be able to at that point communicate why is that we have committed resources to this? Why did we choose this solution? How are we gonna master success? Why is this important right now and why is it that potentially we might be looking at answering these other questions.
- What about visualising your roadmap? Any particular preferred style?
- I'm very biasly gonna say now, next later . I've worked with it for years. I was part of the ProdPad team for six years. I think it is the easiest to understand in terms of again, that timing and being able to add different levels of information depending on who that audience is. I've also seen other formats, like literally just having a page and saying now, next, later instead of columns. It's the same idea. I think as long as the information is there is really it. But the key thing there is to really stay away from timelines as much as possible because that's not a roadmap, that's the delivery plan.
- Personally, I like to reduce the amount of words when it comes to visualising. I like something more visual. Dare I say something prettier than instead of these big blocks of words that, well I've probably got a lot of inaccuracy in them anyway.
- It depends on who it is that you're presenting it to, what information they need to know. It could be that your board doesn't care about all the experiments that you're running and they just care about the objectives and how you're measuring success and what the impact is on whatever metrics they care about. Likewise, your developers are gonna care a lot more about the experiments that you're gonna run. You might wanna percent some of those potential ideas for them. It really it varies, it depends. I've always had this pet peeve with the word visual roadmap because you're looking at it obviously it's visual unless it's a podcast and you're listening to your roadmap. It's still gonna be there but the presentation, absolutely, I agree it matters. What I really like about tools like Air Focus and ProdPad is that you can play around with some of the colours and some of the labels and that makes a little bit easier to digest. You have things like filters to let you filter the information. You can click on things and expand them and reduce the amount of stuff that is being shown. There's different ways and different ways of presenting it I guess.
- It sounds like you're not gonna be a fan of all the books I'm thinking of writing then 'cause I love the more visual side thing but that's okay. We can all have agree to not love everybody else's work every time.
- Well, I think the important thing is the information coming across. That's key. It doesn't matter to me what it looks like. It's really, is it easy to understand and do people get it? Do people get that you're not committing to features?
- I have a little bit of a love for visualisation, therefore, if you saw my bookshelf, it's got tonnes of books on just visualisation and graphical design and even though I'm a product person, but it's just something that I, it's one of my little kind of things. I kind of hook on that when I think about. but in a video.
- Yeah.
- That's visual, right?
- That's visual. How do you engage people with your roadmap but on a video or a cartoon?
- The next stage from a vision type I know is I think Leah from Silicon Valley Product Group was telling us about Adobe's vision type a few years ago was very much a video that took you through that journey. The customer was going to have to actually get across the vision that the business had for how they're gonna evolve and what led to creative suites or creative cloud I should say. And so yeah, that's an interesting kind of dimension telling through a video.
- Yeah, I think it's Asana. Don't quote me on this, but I think it's Asana that actually created a video for their vision as well. And I thought that was a really interesting way of presenting things 'cause to be fair, and this is a really key thing as we're talking about and these things, how do you present it? I think people get bogged down very much on how do we present it and then they just create the document and leave it. And they're like, "Well, I did my job. "I created the document. "It's there." But you can't put all the responsibility on the document, whether it's your magic video, whether it's ProdPad or Air Focus or God forbid Jira , whoever it is that you have your roadmap, you cannot just share the link and say, "Oh well it's there. "It's done." It's not the documents responsibility for people to see it. It is your responsibility as a product manager to make sure that people know that it's there, that they're aware that it's there, that you're bringing up constantly, that you're sharing it at least once a month and referring to it and then using that release plan and saying, here's what we've achieved so far based on the direction that we're setting on the roadmap.
- So true. It's like maybe a little bit of an analogy to presentations. Any presentation comes from the presenter, not from the supporting visuals behind them. The document that we're talking about is the supporting visual for the roadmap that's actually in the product manager's mind, maybe codifying into a system or a tool but it's still kind of that gonna be communicated and lined out.
- Absolutely. I think we put so much responsibility on the document. Oh, well I tried the now, next, later and it didn't work. Well, why didn't it work? Did you try? Did you socialise it? Did you bring it up at least once over the last three months? At least once a month or did you just create and left it there? I think we need to just make sure that we're not leaving the whole responsibility of that communication to the document itself.
- Now, I'm gonna ask a dangerous question here, Andrea, 'cause I might be asking you to pick between your children. Would you have a preferred tool for road mapping?
- Oh, I can't answer that . I'm gonna give a very democratic answer, which is not about me but more about what is the outcome that the audience needs to achieve. I think the ProdPad is a really great tool. It is super outcome focused and your team has that process in place or wants to start that process. It's a really great way to work and a really great tool. Air Focus is a lot more flexible. That I would say is the key difference. It also allows you to be outcome focused. It also allows you to do all that stuff but it's a lot more of a flexible tool. If you have a process that perhaps you know isn't gonna change anytime soon, then one tool is good for you. If you know that there's a process that will very quickly change and needs to scale and needs to be adapted, then the other tool might be better for you. But I at the end of the day, I'm gonna say it's really less about the tool and more around the process. Process first. Make sure that you understand what it is that you need to achieve and then see which tool actually helps you get there.
- Yeah, I very much in agreement, it's like the tool needs to fit the context, not the context fit the tool.
- Exactly. Like I said, it depends. It depends on what it is that you want to do. It depends on what that workflow and those processes look like for you. The biggest reason people tool hop at the end of the day is because they think the tool is gonna fix their problem but the tools aren't gonna fix their problem.
- I know it's so many people who've adopted a tool and then given up on tools because they actually found it was making more work, making their life harder than actually just sticking with dare I say at my good old Microsoft PowerPoint all spreadsheets, which can still be the job.
- Exactly but what problem are you trying to solve for yourself first? Understand what your problem is because you might be going a tool after a tool that solves an entirely different problem. And you need to know what it is that you need to achieve.
- My old old team, we evaluated a lot of tools ourselves and we were going through the process of sourcing one as I left, but one for example that we looked at was Craft.io, which was much more UX centric. It allowed us to do a lot of product activities but it very much focused more more on the user journey and that and the user experience side of things which wasn't a great fit for us in our context. Now one of my team absolutely loved it but when we looked at across the real jobs we needed to do, it just wasn't a fit.
- There's people that love Jira, no judgement .
- I do, well.
- No judgement . And that's what they're all . But if that's what you wanna do, honestly, at the end of the day, it solves your problem. It solves your problem. If it scales and it works, then no judgement . If it works it works.
- And we've kind of talked about some of these here but let's kind of get a little more concrete. What's best practise when it comes to road mapping for you?
- No timelines . Just flat out no timelines. That would be number one best practise is to drop the timeline. A lot of people are still afraid of dropping the timeline. I actually did a study last year as to why product managers are still using timelines. And believe it or not, I think out of like 400 respondents to the survey too said that they used a timeline as an actual roadmap and 398 said that they only used a timeline because their boss said so, not because they believed in it, not because they thought they were going to a adhere to it in any way, shape, or form. It was just like, well, somebody asked for it. It's not true and we know it's not true but we just did it. Timelines, just if you can, drop the timeline. And again, know the difference of timeline timing and I'm gonna throw a new one in there, which is deadline. Deadlines unfortunately in the real world as much as I'm gonna say they don't exist but in the real world, they do exist. There's industry things that you need to adhere by. There's specific projects that need to be done by a certain date for certifications or like at the famous ISO certification everybody wants to get. You've got to do that fast. In the real world, deadlines exist, but just because some deadlines exist doesn't mean that everything has a deadline. It's also important to take that into context and that a deadline does not mean throwing everything on a timeline. A deadline can also just mean you've got your annex later and then maybe one or two projects have an actual deadline written down on it.
- Just kinda to probe that a little bit. The one category where I've struggled to get away from a timeline is physical products, hardware products. And where there are things like getting into a catalogue where if you're going through distribution and things like that, any thoughts there?
- How do you decide what is part of your hardware product? You still need a strategy. And you still need to run some form of discovery. So the now, next later kinda fits really well to that because you still have a space to run that discovery and ask those questions and go, okay, we know we've answered this question and we are now working on that and we still have these other questions to answer.
- Yeah.
- It's still a great way of visualising those things. You can still have a timeline. I'm not saying don't have a timeline, I'm just saying they can both work together really well. You've got the piece that helps you, as you said, visualise what those questions look like, what questions you're answering, why are you even answering those questions in the first place, and then having that timeline to make sure that, that those processes are moving along. And I agree. I think the hardware products, having that timeline and endearing to those timelines is important because you need to resource a lot of different things together but there's no reason why you can't have the other one as well.
- I know from my own experience where I generally recommend going to the now, next and later format and most product people say it is like, "No, no one will ever accept it." And then they try it and senior leaders, customers all of a sudden just accept, they accept it quite happily in my experience because they kind of realise it's more honest.
- Yeah, and not just that but I think it's also about context. When you give a timeline, all you are saying are, okay, this is the block of things that we're doing. No added context, no information, that's it. When that is all the information you have, you're going to want answers . You're gonna be like, where is that thing you promised me? I don't know what else you're working on, so give me that thing you told me you were giving me. But when you change that conversation, you change that context and you say, "Hey, these are the things "that we might be looking at in the future. "We're investigating it," et cetera, et cetera. It changes. It removes that need for that security blanket because you're already providing that security blanket and you're saying, this is the stuff that we're working on now but this is all the other stuff that's in context around it. And I think customers and your team as well just becomes more understanding of what that process looks like. And it's like the typical, oh, I want chocolate cake. But it turns out I'm actually working on a lemon meringue pie. "Oh, I also want the lemon meringue pie. "Oh, I forgot about the chocolate cake." It's again, it's providing that context and the more information you're actually able to provide because at the end of the day you are providing more information with the now, next later, the more understanding people become.
- How I think asked this before someone, but from, I have a perspective on if something's in the later column, does that mean you're not working on it till later?
- It means that you haven't started answering that question yet. Again, it's timing and that question may be answered later or it actually could accidentally even be answered as you're answering another question. We don't know. And that is kind of the point of a roadmap is to make space to be able to ask those questions in the first place. Just because it's in the later and something is in the next doesn't mean that is the actual progression of the roadmap. It just means that it could be that while you were answering one question, you started answering the next one, and then you grab that one and you move it up and then you change the context of the question. That I think is a misunderstanding of the now, next, later roadmap is that it shows a progression of literally now next, later . But that's not what it's meant to do. It's meant to say these are the things that we have committed resources to and these are all the questions that we're still trying to figure out. And at any point in time those questions can shift, they can change, they can adapt, they can change in context but it's not a set list of things to do.
- My perspective, I'm working on the things in that later column, but they're gonna pay off later. Whereas these things in the middle, I'm working on maybe with less emphasis or less effort in the later things right now but they're gonna, the next is gonna pay off so nearer term and the now is gonna pay off much more near term because otherwise very quickly the later becomes now and I haven't got the answers to the questions to know what to do.
- Yeah, no, that's also a great way of thinking about it. And I don't think there's a right or wrong. And that's the most important thing is there is no right or wrong when it comes to asking those questions as long as you're asking them . That start with a question, don't start with we're gonna build a Salesforce integration. And funny enough, this happened at a previous company I was at is they actually kept promising a Zendesk integration. "Oh, we're gonna build a Zendesk integration. "We're gonna build a Zendesk integration." And I was kinda like, "Okay, but why?" It doesn't feel like it's really a fit. I decided to investigate and I went to the entire Intercom backlog and I pinged every single instance over two years where Intercom not Intercom, Zendesk had been mentioned. And it turns out there were more instances of the team promising an integration that customers had actually requested it. It was completely biassed. They completely just decided that they were gonna build this because they thought people had asked for it, when in reality they hadn't. And that is the danger with leading with a feature and just saying, "We're gonna build this," as opposed to, "Should we even be building this?"
- Okay, we said the best practitioner was no timelines. Does that mean it's also the biggest mistake putting timelines on those? Is there another big mistake on there?
- Like I said, leading with features, working with timelines, those are generally the biggest mistakes. And using your roadmap as a delivery plan, open yourself up to ask those questions. At the end of the day, asking that question or those questions and realising that you're potentially going down the wrong path is better than building that thing and then realising you were wrong after you've built it.
- Whose advice on road mapping do you listen to?
- C. Todd Lombardo, he wrote, "Roadmaps Relaunched." He's a good friend and he's a mentor. What I like about his book, "Roadmaps Relaunched," is that it gives a variety of different options and ways to create roadmaps that are realistic. If you have to have the feature, if you have to have that deadline, what might it look like? And it's not just, oh, don't have a roadmap because that's also not realistic. You can't not have a roadmap but it really kind of sets the tone to the different situations that you might find yourself in.
- Fine enough. Bruce, his co-author is already recorded over out just a little bit before you and in C. Todd's booked just next month. Gonna gonna get their thoughts.
- Nice. Oh, I love C. Todd. He's such a smart person and as my mentor, he always just asks me these questions. I sent him a message the other day and I was like, Oh, I was given this feedback about something and he's like, "That is amazing. "What did you learn from this?" And I was like, "Nobody's asked me that." I love it. He literally just said, "This is an awesome opportunity for you to grow. "What did you learn from this? "What might you do differently next time?" And everything, he never just tells me the advice, he asks me the question first. And he's like, "What might you learn from this? "How might you do this differently?" And that is very like roadmap oriented as well. How might you do this? How might you change things in the future? Yeah, I love C. Todd. He's such a great person.
- Right then, resources beyond the people who you listen to. What about the resources out there? Anything that you look at? Anything you read, listen to, et cetera about road mapping?
- I'm wanna suggest some Twitter and LinkedIn and see what comes up. I can't really think of anything specific at this time but what I am going to say is be aware of bad advice. Instead of telling you what to listen to, I'll tell you what not to listen to. I'll change this a little bit. I was working on a study because this term kept on coming up and I was like, "Why is this a thing?" And it was Kanban roadmap and I was like, "What the hell is a Kanban roadmap? And I went on Google and I actually typed a Kanban roadmap and I thought, "This has to be a joke. "This cannot be a thing." There were so many articles on the first page that said Kanban roadmap and it gave absolutely the wrong advice. Absolutely. Like it misunderstood Kanban and it misunderstood roadmap. And it was just talking about how you can use the Kanban and the roadmap. And I'm just like, "What is this nightmare? "Who approved this?" Because this is not a thing. Let me make this clear. A Kanban roadmap does not exist, please. And so I wrote an entire thing and I was like, "Okay, let's first analyse why this even happened "in the first place." I think it was honestly SEO Jews. They thought Kanban, they thought roadmap, let's make it a thing. But it really came down to a misunderstanding of what the now, next later roadmap was. And I've seen a lot of terrible roadmaps and examples of good roadmaps that were really just instead of now next later said, backlog in progress. Done .
- Yeah. That's, I guess if we go back to the related artefacts, our backlog is probably another one of those related artefacts that kinda links in, has a relationship to the roadmap and might be managed through a Kanban board in terms of delivery but it's not the roadmap.
- But it's not a roadmap. Exactly, exactly. When you read something that makes you go, "Huh," know that it's okay for you to be like, "Is that even right?" Feel free to ask that question because I've also read things and be like, "Huh." For example, Marty Cagan love his stuff, absolutely 125% respect him but I don't agree with no roadmap. And it's okay for me to say I understand where he's coming from and I understand what he's saying and I agree his point of view of how damaging a timeline roadmap can be but I don't necessarily agree with the notion of let's drop roadmaps entirely. It's okay for you to ask those questions and question some of these things. And I think that's healthy.
- But taking that pragmatic view, similar to what you just expressed of there are anti pattern bad roadmaps. And what we need to do is instead of throwing the baby out with the bath water, let's actually use this name of an artefact that we're all expected to work around and turn it into a tool that actually helps us deliver for customers. This is the hardball question now, Andrea, if you had to distil your philosophy on roadmaps down to one or two sentences, what would it be?
- I'll give you four words. Absolutely no timelines involved. That's it. That's all you have to do. Or three, drop the timeline. There you go. I made it even shorter. And know that it's okay to drop the timeline. There's so many great resources out there from Jana, from C. Todd, from Teresa Torres, from Melissa Perry, from John Cutler. I can keep naming people. There's so many wonderful resources around different ways of creating roadmaps, different styles of roadmaps that are really focused on not having that timeline and also dropping this notion that leading with features is okay.
- Is there anything else I should have asked you about road mapping that I should have asked you?
- What do you do with the items that are done?
- What's the answer?
- There is a hidden quote unquote column that people tend to not talk about very much, which is naming is up to you but it could be you complete a column, it could be your outcome column, it could be your whatever, released column, for lack of a better word. And at that point you're then able to take the time to reflect on what you've done and say if the answer to the question was in fact to release Zendesk integration , what do you achieve? What was the ultimate benefit for the customer? What have you learned from it? And I think even more powerful than sharing, especially to our customers, what it is that you are planning to do is what you have achieved so far. And that sets context and it sets tone for the conversation that you're not just releasing features for the sake of releasing features but you're actually releasing and working on solutions that provide an ultimate benefit for the customer thing. I often phrase that is especially in B2B, what benefits can they have to do or what can they have to do? They don't have to wait until the thing that's coming next or now it's you can have it right now, don't wait, don't order in six months time, order today, get the benefits today and you're on the journey with us.
- Yeah, and speaking of artefacts, there's one thing we didn't talk about, which is release notes. Release notes are a great way of talking on a weekly cadence and engaging with your customers around the things that you're putting out there. But on a much higher level it's really about the overall benefit. Now of course you can frame your release notes in like a benefit style thing but at a much higher level think higher than the button that you added or the thing that you styled or the minor bugs and fixes, which is a huge pet peeve as well. But what was the benefit for the customer and what is the value that they're getting out of it? And you can absolutely use your roadmap to communicate that.
- Andrea, I guess last little thing from you, if you'd like to make a pitch for you, yourself, the businesses you work with or for, here's the floor.
- Cool, I guess I'll talk about trends 'cause it's so completely different than anything I've done before or at least anything I've done in the last 10 years. As I mentioned the beginning, I have been like hyper focused on product teams and product tools, but Trint is a new challenge for me and it focuses on allowing teams to bring stories to life faster on demand as things are happening. Imagine going to the Can Film festival or the Grammy's or a tech event or even this conversation right now. You want to be able to share things as they are happening. And right now there's a few options. You record everything and process it later. Like what we're doing right now. This is being recorded. It will then be put up on YouTube. Or you can try to do it on Instagram, but you also potentially lose time and also miss out on moments as you're like trying to record and upload and cut it and trying to do all this stuff at the same time. Trint actually allows you to bypass all of that so you can focus on capturing what's important and then your team receives it in real time and they can process it for you. They can add any captions, they can translate it. We actually recognise I think it's like 34 languages now and translate into an additional 50 something. It's insane. And then they can create those new bits, find those moments to share and actually just start sharing it for you. You can focus on the capturing and they can focus on creating consumable content that is inclusive. It allows people to engage with it in real time and as quickly as possible 'cause as we know, everything just happens so quickly nowadays. But also, is easy to to have anywhere at any time, whether it's TikTok, or Instagram, or Facebook or there's so many platforms right now. It's so hard to keep up with, isn't it? It essentially brings that like newsroom capability to content marketing teams and also to newsroom. That's our niche up until this point. And we're moving into new undiscovered areas .
- I guess we'll close there. I actually wanted to thank you for your time today, Andrea. It's been wonderful talking loads of insights, loads of unique perspective, which is what we're looking for. We're looking to kind of have that conversation with the world about road mapping to help move the craft forwards. Just the mandatory to everybody else, please do like, subscribe, share all those good things. And if you'd like to sit where Andrea is, maybe not in her house but on the channel and have a talk with us about road mapping, please do get in touch. Contact details are below at info@talkingroadmaps.com or just find us through the web or comments and we'd love to invite you on to have a chat. Andrea, thank you again.
- Thank you so much.
