[On Demand] Product Management Webinar: Product Roadmapping

Janna: [00:00:00] So welcome everybody. And great to have you here. Thanks so much for joining today. This is one of our fireside webinars that we run here at Prodpad, one of our product expert webinars. We’ve been running these things for years, so you can go back into our history if you go to Prodpad.

com/webinars, there’s a history of all the conversations that we’ve had with product experts in the past. We’ve always recorded them and shared them out there and put out transcripts and all that sort of stuff. And these things are always with a focus on bringing in. Amazing smart experts who have world experience with the world of product management.

And so there’s always a focus on the content, the learning and sharing what we know here. So today is going to be recorded. You will have a chance to ask questions. Feel free to use the chat as I can see people already are, which is very cool. And yeah, we’ll have a chance to dive into today.

We’re talking about the pitfalls of product management. 

C.Todd: So there’s so many. 

Janna: Yeah, [00:01:00] exactly. Exactly. Product management is such a contentious subject because it’s like the output of what people see the product manager do, but there’s so much that goes into it. And it’s not just the product manager.

doing the road mapping, right? It’s the iceberg, 

C.Todd: Really. The tip of the iceberg, right? There’s so much underneath. 

Janna: Yeah, it’s a good way to put it. We’re going to be talking about all that. I know that some people have written in with their questions as well, so we’ve got those ready, and, use the Q& A area here today.

You should be able to see each other’s questions and give them a plus one thumbs up, and that way we know which ones are the most burning questions. Now before we jump in, and start talking to C.Todd about this. I just want to share a little bit about Prodpad. So I know many of you already know Prodpad, so thanks so much for your support.

For anybody who hasn’t tried it, it’s a tool that myself and my co-founder Simon built originally when we were product managers ourselves. And we needed something to help. Keep track of the ideas and the experiments and the steps in our roadmap and all that sort of stuff. So we built something that’s now being used by thousands of product teams around the world.

And basically what it’s [00:02:00] doing, it’s giving you a single source of truth for all your product decisions. It’s giving you a space to capture your high-level vision and your goals, as well as your more strategic steps on your roadmap, so it’s now the next leader of the roadmap builder as well as the more tactical stuff, like what ideas and experiments in your backlog and what have your customers been asking for.

So it’s something that you can try for free. And we even have a sandbox mode that you can jump into that has example data like roadmaps and OKRs and feedback and experiments. And you can see how it all knits together in one product management space. So I would love to see a bunch of you give it a try and let us know how it’s going because we’re all product people here.

We’d love to get your feedback. And in the meantime, one of the other things that we’ve launched with Prodpad is Copilot. Some of you have been beta testing on this for a few months now, and some of you might have seen our launch just last month. But Copilot is an AI agent that underpins the [00:03:00]whole thing.

And so it’s. Your sidekick, your product management coach, you can ask for advice on whether your roadmap is aligned with your vision. You can take an existing roadmap, a screenshot of it and just feed it to Copilot and it’ll turn it into your first Prodpad roadmap for you. It will assess feedback for you and tell you what objectives might line up with it.

Basically you can ask it anything and we’d love to hear your use cases, find out how you’re using it. If there’s anything that we haven’t thought of already and we love seeing those examples. Give it a try and let us know what Copilot does for you.

So I want to introduce you to C.Todd. So C.Todd is a long time friend in the product management space. We’ve known each other through the Mind the Product network for like a decade. 

C.Todd: It’s at least 10 years at this point now. It’s at least a decade, I’m sure. 

Janna: Yeah, absolutely. So he’s a product leader and a design strategist with years of experience helping teams build and launch products that actually solve real world problems.

He’s spoken [00:04:00] on stages around the world. If you haven’t seen his MTP con talks in the past, then get in and have a look at that because he’s fantastic. And he talks about design thinking, innovation, agile product management, agile product development. And he’s a mentor as well. He’s been helping the next generation of product leaders level up.

We were just talking about his work teaching these days, which is fantastic to hear. And if you’re into product books, you’ve probably come across some of his before he coauthored design sprint product roadmaps relaunched, which actually has examples of prod pet roadmaps in there, which is fantastic.

And 

C.Todd: yeah, I think there was a forward there or something that you were part of? 

Janna: Yeah, I wrote the forward. Thank you, C. Todd. So I know that one quite intimately. And most recently he’s written product research rules. But I heard from C. Todd just earlier today that he’s working on another one as well, which C.

Todd, you’re, please give us anything I’ve missed from your bio as well. No, that’s great. 

C.Todd: Look at that. I’m like, is that really me? No, that one’s [00:05:00]That’s not me. 

Janna: Did I do all that? You did all that. I did 

C.Todd: do 

all 

that. And anyways yeah, ’cause I’m just me. So Yeah the latest thing that I’m digging into and the to everyone on the call if you have thoughts, opinions, or have somebody I should talk to I would love to, please reach out to me and let’s talk more what the, so when I was at my time at Appcues, I met a guy named Romley John.

He is now sort of his own content creator. He is really active on LinkedIn. He’s amazing. Super smart guy does a lot of things like product marketing and onboarding. Like he actually wrote the book, I think it’s product led onboarding. And so we just hit it off at app cues and now we’ve both moved on from there.

We’ve also had this curiosity around the concept of creating delight with your product. And there’s a whole bunch of things that are going on around that, but also like this smashing title wave that’s hitting us around. AI. And so how do we think about creating delightful products with artificial intelligence and thinking about what the guardrails are, but also, and I don’t want to be like a doom and gloom type of thing, but it’s like, what’s yeah, sure.

They’re [00:06:00] guardrails, but also what’s good. It’s one thing when you hear about it, I was like, Oh, it’s very dystopian. And the guy’s going to take over everything. It’s okay, but what’s good. And how can we use this for good? And that’s really what our directive is here is. What can we investigate around that and also maybe give a bit more, a lot of the conversation around delight in the product space has been related to the condo model, which is like the 1980s.

And I think there’s a lot more research and more really helping to better refine what delight is in the management sort of academic space. And I’m like, how do we bring that more towards the forefront of the conversation and mash that up with. Artificial intelligence. So anyways a bit of a long winded answer, but delightful intelligence is what we’re digging into.

And I’m excited, really excited about it. 

Janna: Yeah, absolutely. Me too. We were just talking about this earlier and saying that building for AI right now is a little bit like, it’s a bit of a wild west, right? It’s like building mobile apps. Coming up 20 years ago. We’re still working out the patterns.

We’re still figuring out what works, what doesn’t work. And there’s just so much to discover. So a really timely [00:07:00] book. Looking forward to that one. And so in the meantime Just mentioned this a moment ago, the fact that road mapping is like the tip of the iceberg, right? It’s like the place where everything comes to a head as a product manager, right?

Product manager. Why is road mapping so difficult? What’s going on there? 

C.Todd: I think you asked five people, you’ll get 10 different answers. 

Janna: Yeah. 

C.Todd: My answer may be very different than yours, but I think the thing that I think about that is hard is that humans are complex and nuanced.

And it’s a bit reflective in her roadmap. I think that’s the hard part. I think it’s some under maybe under popularized research that talked about they looked at super projects in Boston, there’s the big day, right? Where they basically sunk an entire highway underneath the city.

And any of these super projects, The thing that’s missed out a lot, because they’re always way over budget, they tend to be not actually living up [00:08:00] to what the initial promises were that, say, the politicians and the builders actually advertised or marketed. 

Janna: Yep. 

C.Todd: And so part of it is there’s this element and but the one of the things the research that talked about these super projects was that the thing that everybody misses is the coordination of people working together.

And people don’t realize how much of a skill that is. And the people just assume that people know how to work together and can be aligned and work together. So one of the reasons, to get back to your question of like, why is roadmapping so hard? A lot of it is you’re trying to align a number of different moving parts.

And every organization is going to have a different set of moving parts. So if you’re really good at road mapping in one organization, and then you get blocked up and plopped into another organization, you go to a different job, you might find it’s incredibly impossible. You’re like, wow, this was so easy over here, but it’s so hard over here.

Why? It’s because so many moving parts are different and you might have gotten accustomed would be able to, oh, I know how these moving parts work together and [00:09:00] I can actually navigate and deal with these set of moving parts, but I go somewhere else and it’s wildly different than what I’m used to the moving parts are different they’re moving at different velocities.

And so how do I actually pull them together and it might take you some time to figure that out. So I think, the. The short answer is because people and organizations are much more complex than I think we understand them than we think they are. And we’re trying to put everybody in an aligned direction.

So I think that’s the thing. Why are roadmaps hard? Because there’s so many things going on and some things, a lot of things we don’t even pay attention to. And one of the reasons why my co-author Bruce went off and wrote a whole book around alignment was because all of our roadmapping workshops We have heard the same question over and over again.

How do I convince my stakeholders? How do I convince my boss? How do I convince my engineering manager? How do I convince my dot, insert stakeholder here. And so he was like, we were like, wow, there’s a whole, we need to include a whole chapter on that for the next edition. Like we kept talking about that.

Then I think he ended up pairing off with Melissa and just like they wrote a whole book [00:10:00] on it, which is fantastic. All the aligned, 

Janna: a much needed book. Absolutely. If anybody hasn’t read aligning with Bruce McCarthy and Melissa Appel, Ben, definitely get in and have a look at that. And you know what you’re saying, it reminds me of you, you were there actually you remember my talk where it was at mind, the product where I, great.

I basically summed it up as people are hard. This is why product management is difficult because people are hard. And I think it was during that talk that I first started talking about the idea of your roadmap as a prototype for your strategy. Oh yeah. I 

C.Todd: lifted that quote and said, every single talk I gave after that,

and it’s just like it’s hard. And one of the things I loved about it was that you took a tool that product people know prototyping. And you say, Hey, look, take the same approach you have to creating a prototype, meaning it’s not finished, it’s not polished, it’s not meant to be shippable, so to speak. Yeah.

It’s meant for you to learn something, [00:11:00] take that same approach and curiosity, and now apply that to your roadmap. Yeah. For your but now that’s your artifact, right? It’s not an actual product prototype. It’s still an artifact, but it’s a prototype of what your product strategy is or could be, right? Yeah.

And that approach. It is really fantastic. And I’ve used that a number of times because I would always be like, Hey, I got a draft of the roadmap. Can you help me think through it? That is such a great conversation starter between your stakeholders. It’s amazing. 

Janna: And part of what it does, it tries to take the pressure off making this perfect roadmap.

We see a lot of people coming through to try Prodpad and a lot of them are looking for stuff like, a roadmap template, and they’re looking for the first, the perfect version of what a roadmap should look like. And there is no perfect version, right? Because you absolutely should work to some sort of template or something that, some common shape or way that you talk about the roadmap, but really it’s not about.

the roadmap itself, because that’s going to get thrown out. That’s going to change. It’s going to [00:12:00] hit a wall as soon as you show it to somebody and you say, this is my first draft and they go, Whoa, what about this? Or what about that? Everybody 

C.Todd: has a plan until they get punched in the face.

Exactly. Exactly. Maybe it was who was the, was it Eisenhower or whatever the famous army general said, everyone’s plan falls apart as soon as they actually get out. The battlefield type of thing. Yeah, 

Janna: Absolutely. And it is a battlefield. And to your point this is why it changes per company, right?

Because it’s not the roadmap, it’s the roadmapping process. And the process has to change based on the people that you’re working with, the context in which you’re working, depending on how mature your product is or how much tech debt it has, or, what that tricky stakeholder over there is like in your particular company.

Everyone has a tricky stakeholder, right? 

C.Todd: Oh, God, and it’s not that they’re trying to be difficult. They’re trying to do their job. And that’s the thing, right? They’re not trying to be this tricky stakeholder and they don’t even know they’re the tricky stakeholder. I think another thing that I’ve learned probably in the decade of talking with teams, my own [00:13:00] experience and talking with others is that almost every problem with a roadmap can be bubbled up to the two macro categories.

It’s either you’ve got a strategy problem or you have an alignment problem. Now there are subcategories from there, but you’ve got a problem around your strategy, meaning you haven’t set your goals appropriately, they’re not clear, they’re conflicting. You haven’t prioritized appropriately, like again, bucket those in one or macro category around strategy.

The other one is around alignment okay, again, there could be an issue with goals. There could be some conflict. You’ve got one stakeholder or multiple stakeholders that are misaligned and that’s causing an issue. Almost every roadmap problem can be boiled down to one of those two challenges.

And so for you as the PM, whatever level you are, you’ve got to think about okay, am I trying to solve an alignment issue here? Or I’ve got some other kind of strategic issue that I’m dealing with. That I’m going to start to figure out how to solve, because one of the challenges of the roadmaps is what’s the actual problem you need to solve here?

Is it an alignment problem? Is it a people problem? Like I’ve got, customers telling me to do X, Y, and Z, and I’ve got salespeople telling me to do A, B, and C, [00:14:00] and I’ve got. Support telling me to do D, E and F and it’s okay, I’ve got, that’s an alignment problem, 

but 

I haven’t gotten alignment from everybody on what we should be doing.

Or is it like I haven’t clearly established product goals that line up to my company goals, right? And so I can show progress, Oh, if I’ve done. Solve these product areas, ship these features, got these outcomes. I can now point up to a higher level company and say, yeah, look, this helps us drive this revenue or decrease this cost or whatever.

And that’s more of a strategy, potential strategy problem. 

Janna: That’s a really good way of categorizing them. And I think people run into both of them. Is there, how do you avoid creating a roadmap that, that looks impressive, but ultimately isn’t fit for purpose is indicative of underlying problems.

C.Todd: And I think we’ve all created, every single one of us here in this call has probably created a roadmap in that exact thing. Like we’ve created, it looks good. It looks great. Everyone agrees to it, but there’s some ticking time bomb somewhere. I think part of it is to remember or recognize the same.

That same ethos [00:15:00] around your prototype, right? Prototypes are not permanent. They are changing, right? You might have a prototype that helps you out with one area of your product or one feature helps you solve one problem, but it might need to evolve and change later. Oh yeah, we’ve solved those things, but now what’s the next thing?

So your roadmap should be evolving the way it, the rule of thumb I’ve come to is, and I’d love to hear of yours, this highlines up with you or anybody else’s. Your roadmap should probably change like 80 percent up to 80 percent of the time and not change 20 percent of the time.

There’s going to be 80, 20 rules. And then you also should have this other artifact called the release plan, which is the inverse. The release plan should be, this is the highest stuff we’re really confident in. We are shipping it and 80 percent of it is never going to change. And 20 percent of it might much more tactical, much more focused, typically owned by the engineering or delivery side of the organization.

But that’s how I also think about this. And so telling everybody like, look, this is going to change. This is what our snapshot is of our current thinking with all the information we have right now today, this quarter. And we hope it doesn’t [00:16:00] change drastically over the next three to six months.

But it might, because we know things change. I’m sure OpenAI’s roadmaps changed drastically once they saw DeepSea come out. 

Janna: Yeah, absolutely. And actually, you’re speaking about the difference between a roadmap and a release plan. This is still one that gets everybody tripped up. You talked about what’s the difference, but, what should be on a release plan that’s not on a roadmap, and what should be on a roadmap that’s not on a release plan?

C.Todd: Sure. Great question. I think this is the thing that we came to. I think a few of us when we were doing research, the book, Bruce Evan and I, we started talking to a lot of people about this and we’re like, Oh, there was this sort of aha moment. We were like, wait, everyone expects a roadmap to have all these release plan project plan types of.

Around oh, it’s going to be released on this date. It’s going to have these specific features. It’s going to have all of this stuff. So you don’t really want to have specific dates on your, maybe general timeframes, like yeah, quarters. Months, maybe to a certain point. Again, it all depends on how fast you can deliver things, and what the velocity of your organization [00:17:00] is because things change.

It keeps it more broad. Hey, this is Oregon. I know you, you even took that to one step more abstract to be like, Hey, now, next later. Great way to do things. Sometimes that’s harder for people to grasp. You’re like, okay, that’s great. And I’ll, but I need something a little more concrete.

So it’s like quarters or months sometimes can be a little bit more refined, but if you start to go sharper than that, unless you are. Like incredibly precise at being able to predict what to do and how long it will take to deliver. It’s probably going to start to break down if you try to do more, a finer grain than that in terms of resolution.

So with things like dates yeah, you want to put oh, this release should be, this should be shipped in, March or April. That’s really more of a release plan kind of thing. Cause it’s the engineering team that hits the release button and hits the deploy button, right? It’s not the product person.

You do it together. You make sure you’re aligned. But you let the engineering team own that and I remember when I was at Openly I had a really good relationship with the VP of Engineering there, Joe, and it was like, he totally owned that release plan. I said, Hey, look, Joe, we can divide this up.

You own the release plan. We’ll all know [00:18:00] the roadmap and here’s how we can split it up. And you guys can determine when things should actually go out the door, when you, when they’ve passed all the tests and they meet the criteria that you see. And he was like, Oh my God, this is great. And so the road back is that higher level direction, the things that you don’t see, maybe like higher level thematic areas, like maybe even goals or outcomes.

That’s what’s on your roadmap. Your release plan is Hey, this is what we made and when we want to ship it. So a little bit like answering what and when is the release plan answering why and what that’s maybe on the roadmap. And so that, that sort of what is the Venn diagram overlap, 

Janna: Yeah, absolutely. And as you get closer to what’s happening in the near term, the now sort of time, this is when you start seeing the larger grain stuff being broken down into more fine grain stuff. Now, do you find that people tend to go granular or not granular enough on roadmaps?

What sort of pitfalls do you run into there? 

C.Todd: I’ve seen, yeah, I’ve seen people trying to force the release plan into the roadmap and just oh, they just want one artifact and they want the roadmap and the release plan to basically all be [00:19:00] smashed together. Give me everything. And then that, depending on the size of your organization, right?

If you’re a small organization, you can probably get away with that for a short period of time until you get to a certain size, but. At some point, you really it’s good to separate that because then you also have different owners, different ownership of it, right? Let the product team own the roadmap and direction.

Let the engineering team own what’s actually getting shipped and when, right? And it’s not like they’re working in a silo. There should be an overlap. 

Janna: Yeah. 

C.Todd: I think one of the things I remember from using your product was that you had this great way to send stuff into JIRA. So like we would take some thematic stuff.

And we connected it to our Jira and we shipped stuff over there from that. And okay, great. And that could have helped put stuff in our backlog and say, okay, great. Now I have the designers work on this. And then once they would, that would help chunk up the work for us. And so that was a really cool thing to be able to do that kind of tooling.

Janna: Yeah, exactly that. And what it’s doing, it’s giving you this view into what’s happening in the development side without going too fine grained, because ultimately the [00:20:00] roadmap shouldn’t have everything that’s in your JIRA on it, right? There’s going to be bugs and DevOps tasks and just stuff that needs to be done that aren’t strategic.

They don’t need to be communicated at the roadmap level. And so you don’t need a roadmap. points out the minute by minute as to what everyone’s working on the dev team. 

C.Todd: But sometimes there, there does need to be a communication of, Hey, how come we’re not doing this? Or what if the engineering was taking so long?

Oh, did you realize that there was these like three bugs that they had to refactor that, they’re going to really hurt these, seven, eight clients, whatever, however many clients, there’s some of that you have to communicate as a PM be like, Hey, The engineering team is not going to be able to deliver some of that because we have this other thing going on.

They’re doing some code refactoring, whatever, right? And that’s, I think, also useful. That’s, yeah, it doesn’t have to be on the roadmap. It might be worthwhile. I mentioned, if you’re talking about it at a certain level, again, depending on how stratified your company is, smaller companies might be a little easier, larger companies, you might have to start to call some of that stuff out.

They’re like, yeah, we’re carving out this quarter. 50 [00:21:00] percent of engineering capacity is going to be over on this. Infrastructure, bug fix, whatever, right? Yeah. Calling that out so that you’re not going to get hammered like, Hey, how come you’re not driving X, Y, or Z, right? 

Janna: Yeah, absolutely. And, speaking of larger companies working to the quarter and things like that.

What’s your take on time progression, milestones that are, set to the quarter or set to months or whatever you’ve whatever you’re seeing out there. I think it’s good 

C.Todd: to have goals. Like you want to have goals, right? You want, it’s always something I think about from the time I’m an amateur cyclist.

I like having goals, like races to run or rides to go for. It’s good to have a flag in the sand and be like, this is what we’re targeting for. So putting goals down is really important. Make sure those goals are aligned with. your company goal. So what’s the difference between a product goal and a company goal?

Like product goals might be something around Oh, we expect to have some kind of onboarding turnover or onboarding conversion here. That might actually translate to a revenue goal or retention goal in your company at a higher level. So I want to make sure that, Hey, do those things align as that more goes back to that strategy element, right?

Make sure that stuff is. Yeah. [00:22:00] is clear on your roadmap so that you can communicate it out. 

Janna: Yeah, absolutely that. And I think one of the biggest misconceptions of lean roadmapping, like Now-Next-Later, for example, is that there’s no dates, right? And the thing is we don’t live in la land where, we’re like, ah, it’ll happen when it happens.

The concept of trying to stay away from date driven development is not having arbitrary dates that lock down time and scope, because if time and scope are locked, then quality is what suffers. And that’s how a lot of teams end up in really stressful positions, building a whole bunch of tech debt and no fun.

But the thing is if something has a due date that’s tied to something external, important, strategically key, then communicate that on your roadmap. Yeah. Hey, we’ve 

C.Todd: got a conference to go to or 

launch. 

Janna: Yeah. 

Yeah. . What we’re seeing is people moving away from time lines and realizing that they don’t have that.

Date anchor at the top, which is actually really healthy. Cause as soon as you have that date anchor at the top, it means that everything that you’ve [00:23:00]put on that roadmap has to have a due date, which probably isn’t true for your company. Some things are going to have due dates and some things aren’t.

And communicate those at the right level. 

C.Todd: Yeah. Yeah. And then it goes back to scope, like scope or to pert really, you’re like, do you have enough discovery to, to clarify it? This was the. Part of a prioritization challenge is like, Oh, if when scoring things to start determine prioritization, like if you don’t have it, this is where the confidence sort of element comes in.

Oh, we’re not confident that we can ship this or get this delivered by that. Your engineering team says, okay why maybe we don’t have enough data or details. Like we haven’t done enough discovery to know how important it is. We haven’t done enough technical discovery. How hard it’s going to be to actually build, right?

Let’s make sure we carve out some of that time. Yeah. But I think there’s a balance between having some goals like, like public companies have quarterly, they have to produce quarterly reports for the street, right? They’re the difference. You’re in a different zone there when you’re talking about, I’m a public company, I have these quarterly reports and I’ve got quarterly goals [00:24:00] that I’m trying to hit.

So totally understand that’s going to cascade down appropriately. But, and there may be some elements of yep, we need to. Show progress, right? We didn’t want to show progress on making our product better in some way, shape or form over the quarter. So having some goal is good. But it doesn’t necessarily have to apply to every single element on your roadmap, right?

Janna: And that’s actually really healthy. And we’re seeing that actually carrying through to smaller companies as well, is having some sort of cadence. And it doesn’t have to be quarterly. Remember that quarters are Arbitrary periods that have been made up for publicly traded companies, obviously they work to quarters.

And stick with the quarters, we’ve tested all different sorts of cycle lengths. My favorite was a six to seven week cycle which is half of a quarter basically, but you’re actually doing six weeks of work and then a one week review to check whether that work has worked right.

And plan for the next one. And that means you’re getting more cycles to, to iterate and to try things out. There’s no reason why something needs to take 13 weeks. But regardless of the cycle that you’re picking, whether it’s a [00:25:00]13 week quarter or whether it’s something shorter or longer, whatever works the goal isn’t to say this is what we’re going to have delivered.

By this date, because in order to do that, you’ve got to start planning several quarters ago to get the kind 

of waterfall and it’ll slow the company down, but exactly. 

It’s possible to do, but in smaller doses I call it the project management penalty, right? You’re spending extra time, extra cycles just to figure out how long it’s going to take as opposed to just cracking on and doing it.

But Dom says in the chat channel here He says sometimes like having a deadline to comply with some new EU regulation, for example, right? 

C.Todd: And then I’ve probably worked in the insurance industry like They’re definitely like, Oh yeah, we’ve got to comply with this and we have to comply with this by this certain date, or if you don’t, then we risk a fine.

Okay. 

Janna: Yeah. 

C.Todd: Prioritize it and make sure it gets the resources it needs to be delivered, at the right level of quality, but by that timeframe, and then it becomes more about, okay. We have the, okay, [00:26:00] great. That’s in progress on the roadmap. The rest of the details go on the release plan because you know you have high confidence you’re going to deliver this thing.

You have to for regulatory purposes. So then track it on a project plan or a release plan that’s geared to use the artifact that’s geared for that thing. Don’t use a roadmap to be a project planner. 

Janna: Yeah, exactly that. Separate the two. Cause they’ve got two different audiences, right? The roadmap is a strategic document, right?

This is for people to understand and get that alignment that you’re talking about. Whereas the release plan is about what things are we working on right now? And when is everything going to come out? And, some people can release plans longer than others. It depends on how much you’re willing to invest in that.

And if you’re working in a more regulated space, then it is going to move slower. That’s the difficulty. But also, if you’re able to do that, you create a moat because it means that other people aren’t able to meet the regulations guidelines and deadlines that you’re trying to do. But the key thing is, 

C.Todd: If you start to have hardware at all or any other kind of non software comportion of your roadmap.

And [00:27:00] I’ve been in situations where a number of the companies I’ve worked for, like IOT or biotech where you have, yes, you have software, but you have these other components to it. And a hardware roadmap is different. It is definitely more waterfall, right? There still can be agility baked in, but you still have to do a lot of things to get something from a hardware perspective out the door.

And it’s very different from software, but finding the alignment, it goes back to. All right. Now you almost have to spend a lot more time on alignment because software can go so much faster. 

Janna: Yeah. 

C.Todd: And hardware doesn’t go as fast. 

Janna: Hardware doesn’t go as fast. And what that creates is more risk, right?

Because if you get the wrong thing, if you build the wrong thing, it’s not just days of work or weeks of work, it could be months or even years of work down the line down, down the drain. And so it’s all about making sure that you are risking it as much as possible. And that’s actually where lean roadmapping is helpful, because you’re saying way up front, sometimes you’re able to see years in the future with a Now-Next-Later roadmap, this is the thing that we’re working towards.

And now [00:28:00] that’s getting closer. We can break it down. And of course, it moves more slowly, but it’s still providing the same. service to the company, which is to align people and make sure that things are tied back to the big company strategy. So you don’t build the wrong thing. Here at Prodpad, we have a number of hardware and software IOT type companies using it.

One is using it to build door handles and security systems, for example. And they’ve got software teams, hardware teams, and firmware teams in between using Now-Next-Later. I was talking to somebody from the NASA jet propulsion lab the other day and they work in a Now-Next-Later way, and what’s fascinating is if anybody has a hard launch.

It’s got to be the Jet Propulsion Launch lab, right?

If there’s any sort of hard release date you got to stick to yeah, the planets are only going to align this one time, so we’ve got to do it. And they can still work in this way. And it doesn’t mean that they do everything in a non date driven way. What they’re doing is setting dates for things that need to, and then building backwards [00:29:00] from there.

C.Todd: And even, and I think it goes back to use the right artifact for purpose, right? Like my roadmap will align people and get people going in directionally. And that will help let everyone know what you are going to do. And then, yeah, once I’ve gotten the validation for all the right items, great, it’s on the, it’s on the release plan.

We’ve got some more project type mindset on it. And now it’s about, okay. Chunking through the work and making sure it gets out the door appropriately. And then because the other thing is like the one other thing that I don’t see a lot of teams doing is. What’s the outcome? Put the outcome on the roadmap and then go back and check, did you actually get that outcome?

Okay. You want it to increase conversion by 5%. You’ve shipped this thing. It’s not going to immediately cause a 5 percent conversion. It might take one month, two months, three months to get there. So do you actually go back and say, Hey, we anticipated a 5 percent conversion. We actually got six and a half.

Did you actually go back and measure it? 

Janna: Yes. 

C.Todd: And do that thing. And that’s, so that’s one of the things that I. I think I would. I didn’t harp on it enough. I think I don’t think you heard that enough in the [00:30:00] book, and I definitely didn’t do it enough in some of my past positions that clearly stated a desired outcome.

And then going back and measuring it and saying yep we wanted a 5 percent increase and we actually got a 4. 5 right just so that we clearly said this is the outcome we want. And then also, it helps from the executive level. To say, yeah we’re trying to get this if you guys have seven different feature ideas.

Great. What’s the top three? They’re actually going to get us there, you think, right? And then it’s starting to put power in the PM’s hands to say, all right, I can experiment with these seven or maybe do some discovery to figure out which one of these is going to actually move that needle 5 percent or higher.

Right? 

Janna: Yeah, exactly that. And that’s why we end up building the completed section of our roadmaps and broad pad, because what we were realizing is that as time moves forward and you launch something, people would just delete things off the roadmap. Okay, but where’s the record of it, right?

I know you have the exports and the previous versions of it, but whatever happened to this thing. And so instead of deleting it, move it [00:31:00] to your completed section where you’ve got this reverse timeline of things that were done and when and what your target outcomes were and what your actual outcomes were.

And what we realized is we just created that space for target outcomes and actual outcomes. People would actually spend the time doing that. But without that, people would just be like. What’s next? 

C.Todd: What’s next, . Exactly. And that was the thing that like again, earlier 

on, like we did be like, we didn’t harp on it enough, and that roadmap is, so when we do an iteration, we’re gonna have to make that a little more explicit because.

It wasn’t until later I was like, oh man, we just, yeah, we didn’t call that out enough. We really need to make space for that. The other thing that I think I learned along the way was also clearly staying up, not doing, ’cause I had a couple of these come up, but a few, he was like, what aren’t we doing?

I was like, what’s on the road roadmap? What are we doing? What you don’t see is what we aren’t. But then there’re like, there, there’s a long, everyone has a laundry list of things that’s not on the roadmap. And some people wonder if it’s gonna get on the roadmap someday? Somebody hopes there’s some stakeholder somewhere that’s hoping for something that’s on that laundry list.

That eventually gets to the roadmap. Part of it is if you’re actively chosen [00:32:00] we’re actually setting this aside for now. And I think it might have been Buffer, who they actually did a version of a Now-Next-Later, but they had a leaving for now. Column and I thought it was brilliant and I was like, Oh my God.

And then we were talking to them and they’re like, Oh yeah, this has been super helpful because maybe it wasn’t the roadmap or it was something that was had a lot of talk or a lot of chatter either in or outside the company, but they could put it in this space and be like, yeah, we thought about it, but we’re not going to do it right now.

We’re actively choosing to do that and communicate to them, to them, they’d have a public roadmap too. 

Janna: Yeah. 

C.Todd: Communicate to both the customers and internally that we’re actually not doing this right now. And that was good because it clarified like, yeah, we’re not doing that thing. Even though maybe we talked about it in the past, we’ve decided against it at least for now.

And so we’re just leaving. And I like the phrase leaving this for now. It wasn’t like, we’re just leaving this for now. 

Janna: Yeah, exactly that. And that’s what we’re seeing people use the candidate section in the Prodpad roadmap for, stuff that you acknowledge is a problem. You’ve identified, okay, this [00:33:00] is what it could look like, but it’s actually not our problem right now, right?

That’s off to this side. These are the things that we’re doing, which is in the now, the next and the later. So you can see that story. If it becomes a problem, we want to deal with it. Bring it over, right? Easy to do that. But for now, it’s over there and you can see what happens, 

C.Todd: Or leave it. I’m ready for later.

It’s not even late. 

Janna: Yeah. Reminds me of the interpretation that somebody made of the Now-Next-Later and called it now next lol. I was like, yeah, okay. Yeah. LOL. Yeah. 

C.Todd: I’ll get to it later. So 

Janna: You wrote the book on roadmap. I think it came out in 2017, which obviously was at this height of people product management and deciding what roadmap looked like.

It was a really timely book, but what else has changed since then? What would go into another version? 

C.Todd: Yeah, that’s a great question. I think some of it is just our own learning. Like me, we talked a lot and this is one of Bruce’s. Concept [00:34:00] around themes and really codifying what a theme is, we’ve learned him just through lots of works like dozens to probably at this point hundreds of workshops.

Yeah, for sure. And talking to hundreds of thousands of companies about the concept of themes, like a lot of PMs might be able to get it. But for them to turn around and go talk about this is the theme for this thing or that thing. And then they’re like, and then all their stakeholders, so their designers, their engineering managers, their CEOs, their VPs of finance and marketing, they’re like, huh, what’s the theme.

It was too abstract of a concept. In many senses. So part of it was like, how do we ground this down and to make this more concrete? 

Janna: So that’s one 

C.Todd: of the things I think we learned is that the concept of a theme, even though we could, we had to better sharpen how we speak about it. I think the concept is sound, but giving PMs the right tooling and language to speak about it I think was a thing we didn’t do good enough.

So that’s one of the things I think has changed is okay, I think a lot of PMs get it. But they struggle when they’re talking to other people about it. So how do we make that crisper and start to be more, and this is where like [00:35:00] actually start to not cheat themes, but like actually just say it’s an out, what’s the outcome you’re looking for, right?

Start to make it very clear. Like we’re going over this outcome. What will drive us to that outcome? These things are cool. So we get away from this abstraction of maybe amorphous words called themes. And we can start to be a lot more specific about, Oh, the outcome we’re looking for is this.

And that’s going to be different for everybody. So I think that’s one thing that I think is just our own learnings from our own things we’ve codified, that could be a bit better, but I think the elephant in the room is like, how the heck is AI going to help all of this? I 

Janna: was about to say how, what’s AI going to do to our roadmapping practice?

C.Todd: I hope it helps a lot. Like I think and I know you mentioned that you’ve got maybe you can talk about a little bit, but I know you’ve got some efforts on there, but the way my brain thinks about this is. For those on the call who may have ever used Gong, I think about what Gong does.

They transcribe all their sales teams calls, and they start to extract data and insights from those transcripts that would never be seen in say a [00:36:00]traditional CRM or a sales pipeline. And they start to surface those things by basically reading those transcripts and looking at patterns. One example that I’ve personally seen happen is.

I think one sales rep had a call four times with a client and yet they didn’t mention pricing once. And so that the flag flew then and said, Hey, this sales rep on this deal has had four, half hour calls with a client, but they never once talked about pricing. You go look at the transcripts and see that the word pricing and price never was mentioned.

Why? Maybe there was something about that, but there’s interesting insights there, right? So what can we do, what’s the analog for Gong for all of our product work, right? What, how can we capture our conversations, our Zen desk or support desk tickets, our emails, our slack messages.

Can we feed that all into an AI that does a similar kind of thing that helps help surface and accelerate and augment. The PM to be like, what’s really important to the business right now? What’s really [00:37:00] important to our customers? You could have all these either sales calls or support calls and be like, oh, here’s what you know, prospective customers want.

And that kind of gives you a summary from what all the sales calls. All the Zendesk or support desk tickets help you surface all like here’s all the feature improvements or things that the current user base wants to see more of or less of, right? And then you’ve got your Slack and other internal documents.

Oh, here’s the rest of the chatter of the marketing team or this. How do you build all of that? And to me, what’s that look like? And I would love to see something like that. 

Janna: Yeah, absolutely. And that’s actually the direction that we’re going with Prodpad, right? We were already talking about the AI underlayer that we’ve built, which basically it has insights as to what your vision is, what your goals are, what your what the steps on your roadmap are, what you’ve completed.

What’s in your not going to happen pile, right? But also, all the support tickets that you fed in from your customers, every complaint your customers have had, every joyful piece they’ve come up with. And it has this picture of where [00:38:00] it is you’re trying to go, what you’ve tried and what, where, what direction you should be going based on, the business needs as well as your customer needs, and then can help.

make decisions, right? What it’s doing is not replacing the product manager, but helping to connect the dots so that the PM doesn’t have to hold it all in their head. And they can they can, have this sort of pile of information digested and then laid in front of them. So they can say, ah, yes, that’s actually really key.

Let’s go that way. And ideally 

C.Todd: gathering piece, which I think is a challenge for any PM, right? Yeah. Just even thinking about the different. repositories of data, right? You’ve got lots of information in your analytics platforms, whether it be, had no amplitude, whatever your analytics platform is, that gives you some data about how your current customers are using your product, right?

You’ve probably got some onboarding data or marketing data from like Google ads, who’s using your web page, who’s converting from a signup and whatnot. So that’s maybe the marketing team might have some of that data. You’ve got if you use Prodpad or any of these other product management tools, specific [00:39:00] tools, the product board is another one that I think I’ve referred you to with those kinds of things.

There’s some information there. And then there’s like the countless number of presentations, Excel sheets, and other pieces of things on top of all of the Zen desk tickets, the sales calls, this and that, like the CRM, like. How do you put it all in one spot? Or how do you at least connect it all to a central repository?

And that’s the thing that, if what you’re talking about, that’s Awesome. Sign me up because that is really cool. Cause the thing that I struggled with even before a lot of this tool is just like, how do I get everything in one spot? And I said, I remember when I first started using Prodpad at machine metrics, it was like, guys, where’s all this stuff.

And they’re like this. And I was like, okay, so we are going to put everything in Prodpad and we’re just going to have one central repository for all our products. Information stuff and then we’ll push and pull out as we need. I think they had a whole bunch of stuff in Jira.

Actually, they had a huge backlog in Jira. 

Janna: Yeah, as do a lot of people, that’s actually where stuff like this started, taking the weight off the development side and all the [00:40:00] tickets there. But actually. The inputs to product roadmapping is infinite, right? You’ve got what the business needs and what your exec stakeholders are saying and what’s going on if you’re a public company, what’s going on in the markets.

You’ve got your data layer. You’ve got what your customers are asking for. All of this feeds in, and this is what’s remarkably hard about the product management role, and we’ve taken for granted what we do, as the product people, we’re the humans who sit in the middle and have to like, understand all this stuff and then make a call.

Yeah. And where I think good roadmapping practices help, regardless whether you’re using AI magic or not, it’s helping to create more defensible decisions where you’re able to say, we’re going this way. And the reason I’ve chosen this way is because you can see how it’s connected to our goals, right?

We’re not just putting stuff on the roadmap. We’re putting it larger. Scope goals and problems, and then we’re breaking it down so you can see the story that we’re going after. And I think that 

C.Todd: story is really key. That also helps with the alignment piece of Hey, this is [00:41:00] how we connect the dots between all these things.

So that we can tell that story. And, like anything, there’s always a case where you’ve done all of that work. You’ve connected all the dots and somebody comes in with a sledgehammer and just says, Nope, sorry, do this thing else. Or some other executive or somebody comes in sledgehammers all this and you’re just like, ah, that’s something that’s out of your control.

And that even though it’s frustrating, I think. And I think we’ve probably all been in this situation, but you’ve got to just take a step back and be like, okay, I controlled what I could, and give yourself a little bit of grace and say, okay, I did everything I could here and controlled what I could.

I couldn’t have controlled that sledgehammer, but I at least had all my ducks in a row. And had my story straight. And if yes, we do have to shift and go this other direction, fine, but don’t sit there and be like, ah, it’s frustrating, let it get out, but yeah, we’ll have to move on at some point.

Janna: Yeah, absolutely. And actually just bringing this back down to the more tactical. So there’s two questions that are actually very related. I think in the question area Matthew was asking, can you let me know how you typically talk to business leaders about the [00:42:00] differences between discovery and delivery?

So he says that he’s been putting two swim lanes in his nanoslator roadmap to show the difference between delivery and the solution inventing solution to, to basically what’s going to happen in terms of the upfront work and Ryan was asking about are you saying that you keep the roadmap and the project work separate?

C.Todd: Not necessarily like you might keep them as different artifacts, but they certainly the other roadmap and release plan might, but they definitely need to tie to each other. And sometimes depending on how I presented, I might actually have a link like, Oh, let me dig into this and let me show you where this is right now might be one thing to do.

But I love just going back to Matthews. One, I love that you’re actually phrasing things as discovery and delivery, right? That’s one thing is just even putting labels out there so that people can go. Oh, and I think I remember at one company I introduced this to that I worked for. I was like, tell me about what we do for discovery.

And they were like, head goes to the side, like what? And I was like, Oh, when we’re trying to figure out exactly what to do, we’re trying to figure out what a, how to solve this problem. Like we might have feature ideas X, Y and Z. [00:43:00] But we don’t know which one of those might actually solve the problem.

We just, somebody, some executive or somebody somewhere may have had an idea, but there could have been three different ways or seven different ways to solve that problem. And so discovery is the part of the process where we figure out what that thing is and valid. Yeah, we need to solve that problem.

If it’s very clear, we know we need to solve that problem. Discovery is the aspect of figuring out what the right solution is for this product and this company at this time. And they were like, Oh, okay. And so the eyes go up and be like, okay, once does everyone, so I guess the question back to you, Matthew, but does everyone know what discovery and delivery mean?

And part of it is are you able to show them? Oh yeah. And it does get a little water folly. I totally get it. Like discovery should happen before delivery. So there’s something that should happen before you actually, go off and ship something. It’s not to try to like. Tell everybody like the pendulum swings all the way into the waterfall region, but at the same rate, also, it’s not the, oh, we don’t know what to do.

I’m going to do whatever comes at us, every single week. That’s also the pendulum swinging too far in the other direction. So having that language is really [00:44:00] useful. And say, look, the deliveries of stuff that we are. 80 to 90 percent confident we are going to work on and deliver.

And we actually, the engineering team is actively working on it right now. Discovery of things that the engineering team might be working on, but they’re working on figuring out how to actually make it happen before they actually go make it happen. Or it’s the product team is trying to figure out the design team is trying to figure out what the right solution or suite of solutions are.

So we truly solve that problem and drive to the outcome you want. Again, tying those things to concrete goals, right? Tie everything on your roadmap or release plan to some higher level company goal. Yes, this is going to help us. And a sales rep who was, he would always say this. He’s looking.

If it doesn’t make money, save money or save time, it’s not worth doing. And he’s, in a sense, he’s right. So I had to tie it like everything should be tied to one of those things. And you have to tell that story to say, yeah, we’re working on this. If it’s a backend thing, that’s going to help with your backend.

Yeah. It’s like, how is that going to help you save time [00:45:00] or save money? Or if it’s going to help with conversion or something, it’s going to help you make more money or get more money out of current customers or expand to a new customer base. Like you have to tell that story for everything in discovery and delivery.

So going back to your question, Matthew, like I’m making sure you’re tying those discovery activities and delivery activities to those company goals. That’s the key thing. 

Janna: Yeah, absolutely. And that’s really key. Like when you’re talking about connecting stuff to, make money, save money, save time sort of thing.

You should be explicit about that, right? Put that on your roadmap. If somebody is wondering what we are doing this year? We’ve got a lot of things that are going to make us money. Cool. There they are. Highlight them, put big green flags on them. If it’s there to save time, great flag it up.

I tag it to save time. And that way, if your exec walks in and says what are we doing to do X? Great. Here’s a filtered view looking at just the stuff that’s going to help solve for that particular object in that particular area. And then it becomes very clear if there’s things on the roadmap that don’t fit any of those things.

C.Todd: Yes. Hey, why is that there? And then there’s [00:46:00] always going to be right. And sometimes it’s Oh. Yeah. There’s this infrastructure thing. The engineering teams are really wanting to, okay what’s it going to do for us? And I think Teresa Torres was like, what do you get when you get that?

Let’s say we have it today. What do we get? 

Janna: Yeah. 

C.Todd: And I love that sort of framing. I was like, okay, yeah. If we had that thing, if that infrastructure thing was done, what would we get? Oh, we’d actually get lower AWS costs or lower Google cloud, whatever infrastructure costs are. We have faster response times for this, that, and the other thing, which means less bugs, less.

Customer complaints. Okay. Now we start to see how they go up to one of those goals and 

Janna: exactly it’s so what test, right? So I did a roadmap clinic with one of our customers a few years ago and they showed the roadmap and they’d done a great job in many ways. They had the right level of granularity, but each of the cards was tagged as a new feature.

That’s what the objective was. And I pointed out that if everything on your roadmap is just to build new features then at the end of the year, what do you have? A bunch of features. Does it actually solve any problems? They’re like yeah, this is going to help us make money here and that’s going to help us [00:47:00] take that market.

Tag them as such, right? Tag which ones are going to do which. 

Because 

at the end of the year, so what? You have a lot of features. Everyone knows a bunch of features doesn’t make the best product. 

C.Todd: Output is not good. Output is important, but you really want the outcomes, right? This is hence going back okay, new features are out.

That’s great. What do you get when the feature is launched? And I’d talk, tell the PMs, like PMs who work for look, launch date is your start line effectively. And I’m half joking because that really isn’t, they do a lot of work. Once it gets launched, that’s actually the start line for the feature is life.

Janna: Yes. It 

C.Todd: doesn’t exist then once it’s shipped. Now you’ve got to put a different hat on and say, okay, how do I track this? How do I make sure it’s driving the outcome for the business? Because then if it’s not, I either kill the feature, sunset it. Backburner, do something else, right? Add new things.

Oh, actually we shipped it. It didn’t do what we thought. Customers used it in a different way. We need to actually tweak it this way. So it actually, really drives the outcome. 

Janna: Yeah. And that’s actually something that I think a lot of product [00:48:00] teams fall down on is that they ship something and they say it’s done and then they move on and they ship the next thing.

And what you end up with is a whole bunch of features. But if you build a bunch of features and no one uses them, you actually build the feature, right? What was, where was the value from that? And I actually find it somewhat rude to the development team. You had them build this thing that you said was the next most important thing to do.

You’d launched it out there and then you never went through the paces to train your salespeople up on it, get your marketing team to to properly ship it and, find the value, follow up, whether it solved the problem and tweak it until it did do that magic thing you said it was going to do up front.

You do all that. Then you’re making up for the time that the developer spent on it. They’re not just doing work in vain. 

C.Todd: Yeah. Yeah. And they’re not, you’re not becoming a custom software house because it’s the CEO or talk to a high ranking customer or big customer, they’re like, Oh, we didn’t build this thing for this customer.

And I’ll, they probably made a promise. They’re turning around and asking the team to go be great. But now how do we do X or Y or Z? Because we’ve just diverted this. So 

Janna: yeah, it 

C.Todd: can be [00:49:00] quite the challenge. That’s where sometimes you have to just, okay. All right.

Nobody likes feature factories, except the thing is sometimes you just have to act like a feature factory is certain at certain times. Okay, I just need to, we need to ship these five features because we know. That these, not one, two or three, but actually it’s these five that are actually going to deliver the value.

Sometimes it isn’t just like shipping one feature or two features. You actually might need a suite of them to drive a particular outcome. So you might actually have to think about that as Oh, I can’t necessarily say that this one feature is the only thing that’s going to drive this kind of outcome.

It might actually be a bunch. 

Janna: I learned 

C.Todd: That probably a little bit more later too, is that, Oh, yeah, I couldn’t tie a specific outcome to certain features that we’re working on, but it’s oh, when I take them as a whole, that’s like a suite of things in this area. Now I know that those five things could actually drive this thing.

So yeah, I’ve got to be a little bit feature factory project manager right now, 

Janna: right? 

C.Todd: That’s I’ll put that hat on for a little bit, but I’m still driving these things to a goal, to an outcome. And that’s, I think that’s where sometimes I think we miss me. We [00:50:00] go back to the. Oh, I’m just a feature factory.

And it’s yeah, 

Janna: Exactly. And that’s part of the value of separating out that release plan of which features are going out when and the bigger picture, which is saying, we’ve got all these things. Some of them we can work on now. Some of them we have to work on later, but they’re all tied to helping us, increase market share or decrease that conversion rate or whatever it is, right.

You’re trying to do it. There’s actually one other question here. Very very tactical from Sabrina. How detailed should the points on the roadmap be? Like headings level or short description, something similar. What do you see as best practice? 

C.Todd: Yeah, what I’ve found helpful for me and I think every company is a little bit because it knows your audience, right?

Sometimes your audience is going to want some level of detail and sometimes your audience is giving me the bullet points, right? So first is to know your audience first, right? Understand what they are, how they consume information and what’s good for them. And you might need to tweak it. But I think about newspaper headlines, of they have enough information to give you the gist and you can say, all right, if I had to write the story, I probably can get that sense or have a headline or subheader. So you have a headline that gives a. Maybe how it ties up to a [00:51:00] particular goal or like driving driving retention with, an invoicing feature, for example, like we’re going to drive retention, but for this thing, because it’s the number one complaint, and we’re going to actually, improve our invoicing feature so that we can drive more attention because that’s the number one reason why our customers are going right.

So you like tying this like headline that gives you a Direction of okay, I get sort of problem and solution, a hint around the solution, maybe not the exactly detailed description of the solution, but also it may be a subheader, like derives a, Oh, here’s how it ties to some kind of business outcome here.

Janna: Yeah. 

C.Todd: That’s what I’ve seen work. I don’t know. What about you? 

Janna: Honestly, going as detailed as needed in order to communicate that level of detail for your stakeholders, right? And typically, the things in the now column are going to be more detailed or the things are later on.

You might literally just have a question going. Can we do something about this problem? And it’s not broken down into finer detail. So it’s. Keeping in mind that the roadmap should be a one pager communication document. You should be able to share it with somebody and they could read it and they get a sense as to what your [00:52:00] strategy is or what you’re thinking your strategy is so that they can give feedback on it.

So if you need more detail to explain it to people, then do it right? If you need less detail to just keep them out of the weeds, then do and typically it’s about having stuff up front, more detailed than the stuff later on. But honestly, it’s your roadmap, right? Do what works for your team, to be honest.

C.Todd: Totally. Yeah. I think somebody in the comments wrote like epics. And so one of the things that I tried to do is have the epics and any kind of themes or objectives or goals on the roadmap aligned in, in names so that some epics in JIRA would have similar names to like our goals or themes in our products solutions.

So it was like, that was super helpful to connect. That was the tie in between the two systems and artifacts. 

Janna: Yeah, exactly that. Exactly that. So we’re out of time for questions today, but I want to point out to people that we have another one of these coming up. It’s going to be one of our how to series.

We’re going to be talking about how to build your ultimate product management tool stack. And also we did talk about [00:53:00] Now-Next-Later, roadmap templates or roadmap templates. So we’ve created one. You can access it here. It’s in our sandbox. So it’s preloaded data that you can play with.

You can see how it fits on your own. And then when ready, you can turn it into your own saved roadmap. And so on that note, I just want to say a big thank you, C Todd, for joining us today. It’s been fantastic having this chat. I think we could talk for hours about I know we could, 

C.Todd: But I’m like, it flew by because I’m like, wow, an hour?

Yeah, exactly that. Oh my God, it’s one on one. Holy crap. Like, where did the time go? I can 

Janna: keep talking for a while. Anyways, 

Thank you all 

for listening. Thank you for the invite. 

Of course. Great to have you here. Thank you, everybody. Great to have all y’all here. And see you next time. 

C.Todd: Thanks. Bye for now. Cheers.