Is your roadmap a prototype or plan? | Janna Bastow
In episode 4 of Talking Roadmaps, Janna Bastow and Phil Hornby discusses the nuances between roadmaps as prototypes and plans. She shares insights on how roadmaps can be flexible tools for experimentation and alignment within product teams. Janna also touches on best practices for managing product backlogs and emphasizes the importance of continuous learning and customer feedback.
Janna is a product manager, taking the forms of a startup founder and CEO, consultant, and accidental event manager. She’s the inventor of the Now / Next / Later roadmap format.
She founded ProdPad, product management software that helps you manage your roadmap and your product backlog. She also occasionally works with other companies as a trainer and mentor to help them figure out how to build and learn, without breaking the bank.
In addition to that, Janna is the co-founder of ProductTank and Mind The Product, the international product management community and series of events for fellow product people. It was started in 2010 and has now has grown to consist of 50,000 members and sold out events in 100 cities around the world.
“Roadmapping is a prototype for your strategy”
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).
The next couple of episodes are shifting gears a little to talk to some product leaders from our networks. These product leaders are involved in doing real roadmapping in their businesses so we get a practitioner’s view. We already have loads more episodes recorded with some real superstars of the product world, like Martin Röver-Parkes in Episode 5, so watch out for the next episode!
-
Hi, Jana, welcome to Talking Roadmaps. Great to have you here as ever. For everybody. We'd love it if you'd like, subscribe and hit that bell icon so that you followers and pick up when new things come up. And if you are interested in taking part in one of these interviews or maybe a round table that we're going to do about once a quarter, do get in touch below in the comments. Heck, add your comments anywhere. We'd love to hear your thoughts on what we talk about. Jana, maybe you could introduce yourself.
Hey, wonderful. Thanks so much for having me here, Phil. Hi everybody. My name is Jana Basto. You might know me as one of the founders of ProdPad. I'm the CEO there. Originally I was a product manager and needed tools to do my own job and they simply didn't exist. So we built a tool that helps you make your roadmap and collect ideas and talk to your customers and really just helps you as a product manager keep everything together and build the right stuff. And you also might know me as one of the founders of Mind the product, which is the huge community of product people. So really good to be here. Thanks so much for the invite. I'm excited to talk to you about roadmaps today.
Perfect. Jana set up when we started outlining our targets for people to talk to you. Were pretty high up the list and so we're really happy to have you here as I think our second external interview. So really great. I know you'll bring some great insights.
Wonderful.
So I guess I'll start with that core question of in your head, what's the purpose of a roadmap?
Such a good question. I mean, to me a roadmap is meant to be a communication document, a strategic communication document. It's meant to align the team around what the steps are that you're going to be taking to meet that product vision that you should be outlining. It's there to help everyone understand where it is that you are now, where it is that you need to be in those next steps and where you want to be in the future. It's there to help you sense check if anybody's stepping off in the wrong direction.
Yeah, I mean, so you talked about the team. So who's the audience then? Is it purely internal or does it go beyond that?
Well, I think the roadmap has multiple purposes, right? I mean, I like to see the roadmap as this tool that helps you check your assumptions about where it is that you're going, right? I don't see the roadmap as this tool that the product manager conjures up in their head and then just blasts out there and says, this is the plan everyone follow. I think the roadmap should be something that they share with their immediate team members, their bosses and their immediate team members to say, Hey, is this about what we discussed? Does this make sense based on the constraints that I understood? Based on the inputs that you provided, based on what you see as technically possible, what you see as important to the business, what you see, what the customers are asking for, right? Talking to all these different audience members, those different stakeholders that they have around them because ultimately the product manager's job is to communicate, and the roadmap's job is a tool that helps 'em facilitate that communication.
And the roadmap then can also be used as a tool to help communicate that vision and the strategic steps to the wider audiences, including to customers. So it could be used to show off where you think that you need to be going in terms of that wider strategy to customers and get their take as to whether it's actually in the right direction or not. Because if you're able to tow that roadmap to a whole bunch of your customers and they come back to you and say, Hmm, this doesn't actually align with what we thought that your business was going towards. Now if you hear that from one customer, okay, take it with a pinch of salt. If you hear it from all your customers, maybe it's an indication that you're actually not hitting in the direction that the market actually needs you to. So your roadmap can be a really powerful tool to help check those assumptions that you'd laid out there for on your roadmap and help you make adjustments if needed.
Totally. You couldn't agree more, and I think you kind of already answered this one, but who owns and maintains it then? Is it the product manager or
Ideally, yeah, there should be somebody who is the product manager, somebody wearing that product manager hat within the business. Now of course, not every business actually has a product manager, but every business has somebody who is wearing that hat who is making those product management decisions in smaller businesses or sometimes less formed product management businesses. They don't necessarily have a product manager per se, but it's oftentimes a founder or somebody who has been in the early stages of that business making those product management decisions. But generally speaking, if you've got more than 10 or 20 people, you've got a product manager and you've got somebody who owns that roadmap and is taking in all those different inputs and helping to carve out those decisions, saying based on all this information that we've got, based on what the customers need, what's technically possible, what the business needs, here's what I think is the best set of steps we could take, and therefore this is what the roadmap could look like. Let's use this tool to adjust and check that dissect in fact the right thing to do.
Cool. Yeah, I have to admit, I agree wholeheartedly and I guess, yeah, you kind of hinted at sometimes people are doing product management without being called one, which is an interesting pattern I find in a number of especially older businesses where the concept of product management hasn't necessarily settled yet, even though they've got a big portfolio of products.
And this is often where product managers come from, right? Product managers don't always come from or often usually don't from training programmes or from universities or they don't grow up. I didn't that I wanted to be a product manager when I grew up. People don't go into it saying, this is where I'm heading. Oftentimes there's just a tonne of people who end up adopting this job because no one else was doing it, but there's always someone who has to do this job because product decisions need to be made by someone. And so if you're that person making those product decisions and you recognise yourself in all these product management talks and all this stuff that you're reading and hearing about, if you see yourself as a product manager, maybe not by title, but by everything else, then maybe start talking to your boss and talking to your team and start saying, maybe can I get that title a product manager? Maybe can I become a product manager? Maybe this is a path that does make sense for me if it is something that I'm doing already and I'm enjoying.
Yeah, I mean, it's definitely how I fell into product management. The business I was part of was acquired and we had a portfolio of products and someone from the leadership team needed to be the product manager to the broader new organisation fell on my shoulders,
Right? An accidental product manager, like the best of us, right? Right. Yeah, absolutely.
So what about vision, strategy, objectives? How do they relate to our product roadmap?
Right. I mean, these are all sort of foundational building blocks for your roadmap. I mean, if you don't have a product vision, if your company doesn't have a product vision or a company vision, you're not going to get far with the roadmap because honestly, your roadmap at that point in time could point in any direction. And fundamentally, it's right. You could go in any direction and it's going in the right direction or wrong direction, it doesn't really matter. So you need to stop at that point in time and say, Hey, where's it we're trying to get to? Because I can point us anywhere. And it's more or less the correct way. You don't want to waste your team's time by sending them off in any direction. You want to point them in the right direction. So you've got to make that call and say, Hey, I don't actually understand the vision.
The rest of the team doesn't understand the vision. Let's make a stop here. And a quick way to check that is to go around the team and ask people, what do you think the vision is? How would you talk about the vision and ask one person and then ask the next person and the next person and the next person. And if they all come up with fundamentally different things, which oftentimes you find that they will, you've probably got a problem here where the company or the product vision hasn't been articulated or hasn't been even defined by upper management, by the founders or by whoever it is who needs to be doing. And you as the product person can have quite a lot of sway in helping the execs in the team actually stop and make those steps happen. And once you've actually got that, you can start breaking that down and saying, okay, so now that we know what the vision is, what our objectives, what does good look like?
How do we know that we're moving in the right direction? What would make you happy as a business person here? Are we looking to get revenue first? Are we looking to get user growth first? What's the overall all business plan here? And again, if they can't articulate that, you probably get a business that isn't well defined and you need the execs in your team to define that, work with them and try to help them pin that down, try to get them to pin it down depending on how much sway and how big the business is. And again, this is where you might want to start asking about the strategy. So if you think that we want to go for this first and then that later, well, let's start talking about the steps we're going to take to get there. And that's your strategy. Your strategy is essentially what's unique about your business compared to other businesses out there that you could take advantage of?
And in what order or what sort of steps are you going to take to take advantage of those steps, take advantage of those differences to meet that vision that you've outlined. And your roadmap really at the end of the day is just an articulation of that vision. Sorry, just an articulation of those steps to meet that vision. So the roadmap really is nothing if you don't have clarity on what the vision is, clarity on what the objectives are and clarity on what that strategy could be, the roadmap itself is a tool to help you lay out those pieces to help you give that clarity around that strategy. But you can't do that if you don't actually know what success looks like or what that vision is or what you're heading towards, because otherwise your roadmap could be anybody else's roadmap. It could be your competitors' roadmap. It could be a roadmap for a completely different type of company if you don't know what it is you're building towards.
Totally agree. I mean, I always think that the metaphor of a roadmap is a bit problematic because a roadmap doesn't actually give us a destination. It doesn't tell us how to get there. It shows us all the options when in reality what we're really looking for is a root plan, maybe with a compass on there. And the roadmap almost becomes the sat nav maybe for how I'm getting to that destination, giving me some guidance, but I might still choose to change my mind on the route I know a better way than the nav even thinks of.
Well, and this is the problem when people think about a roadmap in terms of a map map, because when you're building a product, you're not driving from LA to Sacramento, you're not going some known route where there is a best path, there's a fastest path or the scenic route. You're not trying to decide as to which one of those you're going to be taking. You are entering uncharted territory, you're leaving one place and you are moving into space that no one else has ever moved into. You are building a product that no one else has actually built before. People may have built products like yours, but never quite the same way otherwise, why are you building it? That's not what you're doing. You're building into uncharted territory. So it's like you've landed on a new shore and you can see that there's a hill in the distance, a gold topped mountain that you want to reach.
You can see there's resources along the way. You can see that there's a murky swamp that's probably going to cause some problems along the way. You can see there's some immediate problems, like there's a bear that's just come out of the woods on the beach. There's immediate things in front of you. There's things off in the distance, but you don't actually know what the best path is to get there. And what you actually have are the resources on hand and the people that you have in your team, and you've got to pick a path and you've got to decide which way you're going to head. Are you going to go that way or that way or that way? And you've got to decide as to what you're going to do. And there is, you can't pull out your phone and pull up sat nav and go, oh, the path is that way.
No one has built this. No one has gone that way. So you've got to think about, well, if our team could maybe stand on each other's shoulders and look as far as they could out that way, they could figure out that maybe the best path is a veer around the bear problem, then we could cross the swamp and we could go that way or we could attack the bear problem and avoid the swamp. And that allows us to hit that thing that we see over there, which could give us more resources. So it allows you to think about what resources your team has, what's unique about what you have as a company and what you can see. And as you build momentum, as you gather more resources, as you collect more team members along this journey, as you collect more resources along this journey, you're going to have more and more kits, more and more team members.
So you'll be able to see further and further in advance and be able to map out your path in better ways. So a brand new company can barely see through the immediate term, whereas a much better equipped company can see much further out. They've got a bigger team, they can stand on each other's shoulders, and they've got kit that can look further ahead. They can X-ray through the forest. There's a lot more that they can see, which is why the roadmaps tend to be much more complex and much more advanced than say some new company just building their first MVP. So I like thinking
About the, I love you just essentially turned road roadmapping into a Forex gaming experience.
It is, yeah. It's much less of a road tripping travel thing and much more of an adventure. And it is, right. We're all building into something that's much more of an adventurous thing than it is like a simple drive down to some new city somewhere.
I kind of just reflecting on what you said, even if we were trying to copy the competitors, I forget whose quote it is, but it's like we're all perfect copy. So even if we try to do the same with them, we do it subtly differently. Yeah. So we're going to find that we end up in a slightly different place. Yes. Great metaphors, great analogies. So Ken, we talked about strategy and objectives as things around a roadmap. What other artefacts do we find around it that might interrelate be confused with it, et cetera?
So the roadmap is a great tool for teams who want to be able to communicate the steps that they're going to take to meet their product vision. But it's not to be confused with their OKRs. A lot of teams tend to think about whether they need to be doing roadmaps or OKRs. And my argument is actually that you should have both because they actually represent two different areas. So for example, your OKRs represent your objectives, right? It's like what success looks like. And these are often time, time-bound, measurable goals. And what you're basically saying with your OKRs are things like, we want to hit this user growth metric and we're going to spend the next quarter focusing on this user growth metric. And the roadmap reflects that by saying, here are, let's say two to three initiatives we're going to tackle that we think are going to try to improve our user growth metrics.
And within those user growth initiatives, there are maybe five experiments each. So you've got 15 different experiments we think we're going to run now because we're focusing on that objective for the quarter. The company is basically saying, we're going to commit, we're going to budget one quarter worth of our time and our money into this. So that appeases the executives, they love that. They love being able to put things in nice little boxes and know what they're actually going to be doing with their budget, with their money. So they're able to say, Hey, the team costs a million dollars a year. We're going to budget a quarter of that, a quarter million dollars into solving this one problem. Cool. The product team is able to say, great, we've got a quarter million dollars, we've got a quarter to go focus on this problem, so let's come up with as many experiments as we can and try to do as many of them as we can before the quarter is up.
Now they don't know how many they're going to be able to do. It might be 20, it might be 10, it might be 50, it might be five. It depends on how fast the team's able to go, how quickly and easily those experiments run, so many other factors. But basically they're going to do as many of those things as they can because hopefully they've got a quick iterative process and they've got a good development process that allows 'em to get things out quickly. And let's say they get 15 experiments out and still five left on the roadmap. At the end of that quarter, they've done 15 experiments, some of which have failed spectacularly, some of which has succeeded. So they've learned a bunch of ways not to improve user growth, but they've learned a few ways to improve user growth. And they're able to report back to their board at the end of it saying, Hey, look, we improved user growth by 10% this quarter.
Look at the numbers. And we also found a bunch of ways of not doing it. Now what would you like to do next quarter? Would you like us to invest the next quarter in more user growth? We could think of another 20 experiments we could try to run, or would you like to invest it in something else like revenue? Maybe we could come up with 20 experiments in revenue and we could improve revenue by 20% or 10% or whatever. And what they're basically doing is saying, you tell us what objectives and what that looks like, what that looks like for the business, what's important to the business in terms of success metrics, and then give us space, give us the autonomy to figure out how we'll go about doing that. And then we'll run as many experiments as we can. And by doing so, you actually give the teams the best of both worlds, both the direction and the alignment that they need as well as the autonomy, the ability to run forward and just try things and the safety so they can try things. And this is how you see teams really, really crushing it, really succeeding with hitting their numbers and staying lean even as they grow.
Cool. Yeah, I love that. I mean things like the stories Opportunity Solution Tree, I'm trying to relate that into roadmaps myself, easy because they can sit next to each, but then you making that, okay, what am I doing? What order starts to fall onto the roadmap, for example, perhaps?
Yeah. Yeah. I'm a big fan of the Opportunity Solution Tree. It maps really well with the Lean Roadmap format of the now next later format and the lean format of the roadmap. Because what the Opportunity Solution Tree is, it's essentially a way of mapping out your opportunities saying here are the different things that we could do, the different problems that we have out there, the different opportunities we could take advantage of. And then within those, the different potential solutions. And the idea here is that you want to make sure that for each opportunity you are mapping out at least three to five potential solutions. So you're not falling in love with any one particular solution. Theresa Torres is the person who came up with this Opportunity Solution Tree, and she mentions that it's sort of a red flag if you've only got one particular solution to any one opportunity, because at that point in time, it's an indication that you've probably fallen in love with that one solution and you're not thinking outside that box might have been blinded by the one solution.
So it helps you think outside that and say, actually, let's make sure that you've got multiple solutions. And by solutions, the way that I like to think about them is experiments, because some experiments might be feature-based solutions, but some of them might be things that are like, well actually don't just build a feature what the solution is to take away a feature or change a feature, or not even feature related. It could be something like change the way we talk about it on the homepage, change the positioning or the pricing or the packaging in some ways. So by solution, it doesn't necessarily mean build New Code. It doesn't mean add something to the app, it means change something, iterate something, and solution is pretty wide brush. But the other key thing with the Opportunity Solution Tree is that the opportunities come first, and this is the same with any sort of Lean Roadmap format, is that your opportunities or your problems come first as opposed to your solutions that come first.
So many teams get tied up in this one faux pa, which is this obsession with prioritising at the idea level. So they take all the solutions, all the things they could do, and then they try to come up with a weighted scoring algorithm like Rice or ICE or a stack ranking or all these different ways of trying to say, well, we've got 200 things and therefore based on this algorithm, computer says, or the spreadsheet says, these are the top 20 things to go work on, and they go work on those 20 things. What's missing there is that you're losing this context of, well, what are the most important problems and why the Opportunity Solution Tree makes you take a step back and say, well, here are the big opportunities. Let's focus on those things. Let's prioritise those. A good roadmap makes you take a step back and say, here are the big opportunities or problems in prodded terms, we call them initiatives.
So you prioritise at the initiative level. And what you're actually really doing is when you're reprioritizing those initiatives, you're making bigger product, more impactful product decisions. You're not getting lost in whether one thing is more important than the other. You're actually deciding as to whether something's going to have a bigger impact on the business and prioritising at that level. And the other problem with trying to do these weighted scoring algorithms and getting lost in these little tiny details is you're taking these sort of scores where you run into somebody saying, well, this is a score of 50 out of a hundred. This is a score of 60 out of a hundred. Let's take these two numbers, which are both guesstimates and we're going to multiply them together based on this algorithm. Well, if you take two guesstimates and multiply them together, they become even bigger guesstimates.
And now you're taking those numbers and you're comparing them against each other. So now you've got a whole bunch of really fuzzy guesstimates and you're comparing together to get this list. What you end up with is just this jumble of things that people then take as this holy list. This is the order to do things. And you're like, is it really though? Or have you just really come up with something that's tying you into a way of working that doesn't necessarily make sense? Take a step back and really think about whether it's solving the right problems or not.
And I guess the one time I've seen those sorts of schemes work is just kind of helping an alignment, but I guess there's agreeing principles on how you're going to step back and think it, but you, you've kind of gone into something that I'd always like to ask about our biggest mistakes and anti-patterns. Do you have a pet hate of something to see on a roadmap though?
Yeah, my pet hate on roadmaps is a timeline at the top. The reason there's a problem with the timeline, it's a little bit like a math chart, right? Because if you have a timeline at the top, what it does, it assumes that everything underneath that timeline has a due date and a duration. So that timeline is always a steady state. Everything underneath it has a due date integration. So it's like the x axis versus the Y axis, which is the things to do. And so no matter what you put under that roadmap, where you place it under that roadmap dictates how long it's going to take and where in what order you're meant to do it, which would be fine if you've got a really fixed plan project plan, but that's not what we have. Again, we're talking about uncharted territory and the things that are in the very near term.
Oftentimes we do have that level of granularity, but the further out you plan, the more we're honestly making it up. And sometimes these roadmaps need to stretch out. We need to articulate problems that exist 12 months or even further out because we know about problems that exist, but we don't necessarily have a due date for it. I mean, you don't even know how big your team's going to be in December this year, let alone how fast you're able to deliver on it. So we need to be able to provide that level of granularity or difference in granularity where things that are in the current term right now are more granular and things that are further out are much more fuzzy. So by ditching that timeline and moving to Time Horizons, so this concept of three or more buckets, this now, next and later, it allows you to say, if something has a date, put it on the card itself, put it on the initiative itself and say, this one has a due date because it's a regulatory date.
This thing, the law is coming to effect here, and this one has a due date because it is strategically important. If we miss this date, we miss the Christmas rush and therefore we're in trouble. So these ones are fixed things on the roadmap. We're going to communicate those in place on roadmap. Everything else is pretty fuzzy, and that way we don't necessarily have to put dates on them. We can just put them on the roadmap and then allow them to sit between these other pieces without necessarily penalising ourselves by having everything with a date. So by removing the timeline, it allows us to move from being a hundred percent feature-driven team way of working to a much more lean team way of working.
Yeah, I think we've naturally answered there, what are the key elements on a roadmap? What's best practise on a roadmap as well as the negative side, which I always like to ask about, and it probably, I guess I can take it as a given. What's your favourite tool for visualising roadmaps? I'm going to guess you might say something different.
I mean, I'm going to have to give a shout out for ProdPad. Years ago, there were no tools for visualising a roadmap. We were stuck with doing stuff in PowerPoint in Excel. And myself and my co-founder ended up building roadmap to solve that problem. But honestly, I mean, if you're just starting off with something, I honestly recommend just using something as simple as post-it notes. Don't try to get too caught up in making the perfect looking roadmap. Just honestly write down what problems you think exist and placing them in post-it notes and something really simple and just saying, I think it goes problem A, problem B, problem C in that order, and then check it with somebody else and say, you agree. Am I more or less on the right path? Don't try to get caught up in trying to create this ideal looking perfect, beautiful roadmap that impresses everybody. What you're trying to do is just check your assumptions really early on, early before you get into the details, before you get into trying to come up with solutions to those problems, before you try to get into deciding who might be working on those problems, all that sort of detail. Just start with something super basic and then work your way up from there.
Cool. Great advice. So whose advice do you listen to when it comes to roadmaps?
I love this question. I have always listened to product people. I mean, I've got a great product person on my team, but I also have the benefit of being able to talk to literally thousands of product people who use ProdPad and who I talk to through my product connections. I'm constantly learning from product people to figure out what their best practises are and how they do road mapping. People come and talk to me all the time about how they've been doing road mapping, what works for them and all that sort of stuff. And I've been adjusting my way of working based on what I've been hearing works out there. I run things called Roadmap Clinics, which is like a therapy session, but for your roadmap, people come to me with their roadmaps and say, okay, well love the new approach, love doing the now later, but how do I move to it? And they'll show me their timeline roadmap and I'll talk them through, or they'll say, Hey, I've got been trying to move to this now, next later, but I've run into this tricky stakeholder, and I'll talk them through that, right? So I get a chance to talk to literally thousands of product people and get their insights. And ProdPad wouldn't be where it is today if we hadn't listened to early feedback from product people to understand how things work.
Cool. And I don't think we actually explicitly spelled it out, but your claim to fame is being the creator of the now next in litter roadmap format, I believe as
Well. Yeah, absolutely. At least
Popularised,
Yeah, some history behind that. Myself and my co-founder, basically what had happened, the first version of ProdPad was actually a Gantt chart, a timeline roadmap builder, because when I was a product manager myself, I needed a roadmap builder, and we built ProdPad to do just that. And back then I would build a roadmap and I would show it to my boss and I'd get a little pat on the head and be told, yeah, this is great. Go deliver. Now. I thought it was just me who couldn't deliver a full roadmap. I thought that's just my project management failings, but I figured all the other project managers out there could. So I assumed that it was all good, but it wasn't until we started sharing ProdPad with a wider group of people, right, beyond just solving our own problems that we started getting really interesting feedback because the early version of ProdPad was shared with some fellow product people, and they loved it at first, but the first feedback came back and they started saying, this is cool, but I want to be able to take my ideas that are on the roadmap and I want to push them out by a month.
And so we went, oh, well that's interesting. Right? Now, if I just followed my customer feedback blindly, I would've had a multi-select and move by one month feature, or maybe an automatic move by one month feature that you just press every month because no one was delivering the feedback their ideas every month. But what I did was I asked those five why's, and I just got down into it, discovered that no one was delivering the roadmap every month consistently. It wasn't just me. And so I started really digging in and figuring out that if no one was delivering their roadmap, what's the point of a timeline roadmap? A roadmap that has month by month, week by week, date driven things. If everything has to be pushed out every month, what's the point of this? So myself and Simon sat down and asked ourselves, well, what does a roadmap look like if it doesn't have a timeline? And we came up with this concept of three these time horizons and this current near term future kind of concept. And that was where the Lean Roadmap format was born. That was in 2012. We launched it out there, and instantly you could just see this big reaction from the community where they went, this is awesome. I can now roadmap, but I don't have to worry about having to put dates on everything. I can just work much more flexibly.
Yeah, I mean, for me, it's very reminiscent of McKinsey's three horizons kind of concept in terms of strategic level road mapping and kind of resonates well with me in that same space, thinking about true innovation. And which doesn't necessarily mean you're not working on some of the stuff in the far right hand column. In fact, you might have to be working on it for it to pay off in the longer term sometimes. But identifying this is what's the key focus right now.
And that's exactly it, right? It's these strategic horizons. It's the ability to keep your eye on what's in the far distance, right? Make sure everyone understands where you're all heading, but at the same time, keep your eye on what's important and there's immediate problems right in front of you so you don't lose sight on those as well.
Perfect. So Jana, if I was to ask you to sum up your philosophy on road mapping in one or two sentences, what would it be?
That's a good one. I would say that road mapping is a prototype for your strategy. So if I could describe that a little bit more. Prototyping a tool is a process that we're all very familiar with. The designers in us are all very familiar with. It's the idea of fleshing something out as sketching something out really, really simply. Before you run off and do something really drastic, you wouldn't just take a first an idea and just run to the engineering team and tell 'em to go build it. You would first sketch it out on a piece of paper and then show it to people and say, Hey, here's some things that I've been thinking. What do you think? And you'd take their feedback and they'd probably tell you things like, oh, I don't quite get it. Maybe you change this copy or added a button here.
It'd be better. And you take that feedback on board and you make a new version of that prototype and you go back and get more feedback and more feedback and do more prototypes. And the more feedback you get and the more prototypes you do, the more likely that the thing that you're building is to solve the problem that you set it out to do. So the prototyping is a really, really powerful process. The prototype itself is not the powerful thing. The prototype gets thrown out. That first prototype was terrible. Just like your first roadmap is going to be terrible. Your first roadmap is going to be a really bad articulation of your strategy. It's your first assumptions of what your strategy is. But you're supposed to put it out there and say, Hey, I've talked to you and And I think our strategy is this and everyone's going to go, no, you missed it.
I think it's supposed to be this, this, this than the other. And you go, okay, that's interesting. Let's switch that around. Is this better? Well, actually, no, I think it now needs to go like this, this, and then the other thing, okay, we're getting closer. And so by taking something really simple, again, a roadmap on post-it notes something really, really simple. You can just start bashing apart your assumptions and getting early people on board, your immediate team members, your bosses, your tech leads, your people who are supposed to be intimately involved with what your product strategy is on board with your core strategy before you start committing way too much time deciding as to what the solutions are going to be and who's going to be working on it and when these things are due. All that stuff is secondary to understanding what the core strategy is, which is what are the big steps we need to take and in what sort of order. So I would call it your roadmap, a prototype for your strategy.
Sure. It's a little bit like the kind of old quote of a plan is useless, but planning is invaluable. It's kind of we're figuring things out. We're kind, we might, the roadmap itself isn't there, but the act of thinking it through to get there and really know what we need to do is really be useful.
Little bit. Your roadmap is useless, but road mapping is really powerful.
Here's your chance pitch.
Ah, excellent. Thanks. So ProdPad is a tool that was built by my myself and my co-founder Simon. We are product managers ourselves, and it's essentially a tool that allows you to build your roadmap. It's a lean now, next later format or roadmap that connects to your OKRs. You can manage your OKRs and ProdPad, you can capture ideas from your team, and you can capture feedback from your customers and use it to close the loop with your customers. So it's space that allows you to see what your customers have been asking for, what your team has been talking about, and tie it all together with your roadmap strategy and see it all in one big picture.
Perfect. And we'll put some links below here on the podcast or the YouTube channel so that people can come and find it and find your site. Janna, wonderful having you here today. Thank you for all your time. Thank you for all your thoughts. It's been great talking to you and getting your thoughts on road mapping. Just a reminder to everyone out there in the audience do like subscribe, hit that bell item icon so that you get told when there's new interesting content. We've got a whole raft of interesting other product people coming up, thought leaders, experts, practitioners. So really be interested to hear from you. If you're interested in taking part, we'd love to hear from you as well. Thanks for again, Janna.
Wonderful. Thanks so much for having me, Phil.
