S3E5: The Truth About Roadmaps: Why Dates Don't Deliver with Janna Bastow

On today's episode, we're diving into a crucial tool for every product manager, the roadmap.
Roadmaps serve multiple audiences, each with their own expectations.
How can you effectively communicate with all these stakeholders through a single document?
How do you ensure your roadmap isn't just an empty promise?
What's the difference between a roadmap and a delivery document?
And how do you handle stakeholders who don't understand this distinction?
To help us navigate these questions, we welcome Jana Bastow, the inventor of the Now Next Later Roadmap.
Jana is the co-founder of ProdPad, a company dedicated to helping product managers plan and deliver better products.
She's also the founder of Mind the Product, a worldwide community of product managers.
Jana inspires great product conversations by asking, what problem are you trying to solve?
I'm pleased to welcome to Productly Speaking, Jana Bastow.
Hey, thank you so much for having me. Great to have a chat here.
Yeah, absolutely. Pleased to have you on.
So tell us the story of how the Now Next Later Roadmap came to be.
Yeah, absolutely. I mean, this is actually something that grew out of the early days of ProdPad.
So when I first devised the idea for ProdPad, I was a product manager myself, so it was my co-founder, Simon.
We were both leading up product at a couple different companies and needed a tool to do our own jobs.
So we started hacking away and building something.
And at that time, the way that I did roadmaps was timeline, Gantt chart style, feature-filled roadmap.
Because honestly, when I gave it to my boss and showed off, this is what we're doing, they love to see that level of certainty.
And they'd love to see that, you know, I had the plan of what was going to be delivered and when.
And, you know, I found it pretty tedious to create that version of roadmapping.
So I ended up creating a digital version of it.
And so myself and Simon hacked together this first version of this roadmap.
And this is also around the same time that we were starting the whole product tank thing that grew into Mind the Products.
We were surrounding ourselves with product people.
And we started sharing this tool that we'd built, right?
It wasn't commercially available.
It was just very, very beta version of what we'd built.
And we started putting it in front of product people.
And honestly, people loved the idea of having a drag-and-drop roadmap that you could drag your features on and stretch them out to show how long they were going to take and squish it back in and that sort of stuff, right?
And it was a bit of a complicated build, especially because, you know, I never built much in the way of anything interactive on the web.
I learned how to use jQuery for it.
So this dates it, I guess, for you.
When I started sharing it with product people, they loved being able to use this tool.
And so we were like, oh, we've hit on something.
This is interesting.
And obviously, as product people, we kept having conversations with their customers to find out, or these new users, to find out what was working for them or what wasn't working for them.
And what we found was after about, like, four to six weeks, pretty much everyone who'd used it had come back to us saying that they wanted to take a selection of things that were on the roadmap and move it over by, like, a month worth along the timeline.
And, you know, had we just built what the customers asked for there, we would have had, like, a multi-select, drag-and-drop type function.
But actually, we asked these questions.
We really dug it down into why, what was going on.
And turns out, no one was delivering what they'd put on the roadmap that month.
And the thing is, like, when I was a product manager, I often had months where I said that we're going to do this, and this is the date, and that's all going to happen.
And it wouldn't happen.
But I thought that that was me being a bad project manager.
Like, you know, I didn't have a handle on setting enough buffer or, you know, getting fine enough detailed specs or controlling the scope creep or whatever it was.
But turns out, all the product managers do this, right?
Even the ones who we highly respect who were, you know, leading really successful products were creating these roadmaps that ended up just being a bunch of lies because they weren't delivering on the stuff and they were just shoving everything over.
So we kind of went back to the drawing board and said, so this timeline is going to be a problem, right?
Because if we have time always marching forward, then things are going to fall into the past, and people want to be able to move things.
So they're always, like, in the near term, but still communicating what's most important next.
So we ended up throwing away the concept of the timeline at the top, and it was actually Simon who drew out this concept of three buckets, which we called the current, near term, and future.
Not exactly the catchiest term for a roadmap, but we could implement that in the roadmap page in BroadPet.
And so we shipped that, and people really jumped on board with it.
They liked the idea of being able to say, well, here's what we're tackling, and here's the order in which we're tackling, but I can't tell you exactly what the dates are.
And it was always with this idea.
It was based around, if you're familiar with it, the cone of uncertainty, right?
The further things are out, the more uncertain you are about them, whereas the things that are right in front of you, you've got much more granularity and certainty around.
And so we built the roadmap out with that in mind and used that as how we were telling people how to use it, and people really loved it.
They got on board with it.
But we weren't actually sure as to whether we could still call it a roadmap, right?
Or if we just ditched the roadmap, but the page is still called roadmap, so what do we do, right?
And we ended up keeping it as is and actually talking to people and really understanding what they were trying to get out of roadmapping.
And ultimately, roadmapping is a strategic communication document.
It's a strategic communication exercise, and it wasn't about the fine-grained pieces.
So people appreciated that they had this freedom to outline the problems they're trying to solve in the order they're tackling them.
Long story short, we ended up making it so that you could change the titles.
The current near-term future were editable.
And one day, an early customer came in and edited them to now, next, later.
And we realized that, actually, this is a much better version.
It's much snappier.
So we ended up adopting that.
They changed it to that and then wrote about it publicly, and it sort of caught on as a concept, this concept of the now, next, later in these three columns.
And that's where it became part of the fabric of what we do.
Yeah, that's a very interesting story of how that all came together, because you started with more of the traditional date-driven delivery document version of a roadmap.
And through the software and through your learnings, you found out, and like you said, that was a great point about if you had listened to your users, you would have ended up with some really complex multi-select tool.
The customer knows a lot about what they want, but sometimes you have to design something that they don't quite understand yet, and that's an excellent example of getting ahead of that.
You know, Apple is famous for that with things like the iPhone, you know, showing that off at that time when everybody thought they just wanted a more complex smartphone, and then the iPhone was something a lot of us never could have imagined, and here they are making a successful category.
So that's really great. But, you know, you get into a now, next, later roadmap, I would say you get more truth and honesty out of that, because, like you said, nobody really delivers on those date-driven delivery documents.
But what are some of the key differences there, and how do you kind of manage the tension between the two?
Yeah, absolutely. I mean, the big thing that people always notice is that lack of the timeline at the top, right?
And that's often a bit of a shock to people when they're, you know, having to show this off, realizing that they don't have dates lined up against the items on the roadmap.
But the problem with the timeline is when you have this line at the top, it means that everything underneath it, no matter where it sits, how far out it sits, it has a date and a duration assigned to it.
That's where you end up getting caught, because the reality is that some things in your roadmap might have hard dates, right?
If they're strategically important or externally driven, it might be important to outline what that date is and commit to it.
And that takes some additional project management practice to, like, make sure that you've built in enough time and you understand the scope before you make such commitments.
But the reality is, is that chances are not all of your things on your roadmap are date committed.
If they are, then you're not running a product management organization, right?
You're probably very either sales-led or somehow project-led, regardless of where those projects are coming from.
But ultimately, most teams are not actually date-led, right?
They're not commitment-led.
What they're doing is they're trying to find the best path forward.
And along the way, there might be certain milestones that need to be hit, but actually there's a lot of leeway, different paths that they could take through.
And so the NowNext Later helps articulate that and show flexibility for the things that can be flexible.
But also, I think one of the biggest myths about the NowNext Later roadmap is that you can't have dates on it.
The key thing is that you don't put the dates at the top.
If you put the dates at the top, everything underneath it has that date.
And no matter how big of a caveat you put, being like, oh, it's sort of this, you know, it's kind of only Q2 or whatever you want to put in your broad thing, people are going to go, well, you said to be done by Q2 or whatever date you put on there.
Whereas actually, if something needs to have a date on it, put it at the initiative level, right?
The actual thing on the roadmap that has that date tied to it, articulate that, put that on the roadmap, but then everything else, leave us flexible around it.
But one of the other big things that differentiates the NowNext Later format from timeline roadmaps is the fact that it takes it up a level, right?
So one of the traps that a lot of teams get stuck in is that they have a bunch of ideas, a bunch of features or experiments they want to run, and they break them down in detail.
And they map them out on a Gantt chart, a roadmap type thing to show where these things might get delivered and in what order.
Whereas what you should be doing is actually thinking about the problems to be solved first, and putting those in order on the roadmap.
What are your big problems, right?
The big chunky rocks and boulders that need to be broken down.
And then within those pieces, we call them cards on our Progbat roadmap, you're able to articulate which ideas and experiments and potential solutions might be done as part of that.
But you're actually sorting at the problem level first, this higher level version of your roadmap.
And really, it means that when you are making decisions about the order of things on the roadmap, you're making more impactful decisions.
You're not getting lost in whether that experiment about, you know, that check-in flow there is more important, or that experiment about changing the copy over there is more important.
Like, I don't know.
But actually, take a step back.
Which problem are you trying to solve, right?
If it's, you know, check-out conversion rate, well, then here's a list of things you can do to solve that.
And that first experiment is just one thing that's lined up to tackle that.
Well, and ultimately, customers don't really care about the minutia of how you solve the problem.
It's a matter of did you deliver the value to solve the problem or not.
Exactly.
That's actually something I've learned is a lot of people don't care about the details that are on the roadmap.
They're not reading it anyways.
You know, my biggest advice for anybody trying to switch from timeline roadmap to now, next, later is just do it, right?
Re-articulate your roadmap in a now, next, later format and then bring that to your next meeting.
I was told really early on in my career that it's easier to ask for forgiveness than permission.
And actually, what a lot of people find is they bring this new roadmap in, they show it to people, and actually, it's really intuitive.
People get it.
They look at that roadmap and they go, cool.
And so this is what's in front of us and here's what's coming later.
And they might ask questions going, well, when is this going to be delivered or, you know, what does this mean or whatever?
And those are places that you can articulate more or you can say, hey, we don't know when that's going to be delivered because that's only going to be done after this other thing.
So we're talking six months out from now.
We don't even know how big the team's going to be in six months, let alone how fast we're able to deliver.
But do we have agreement on the order that we're going or the direction that we're going into things?
Yeah, it definitely gets a little bit more interesting when you start having, like, commitments to external partners and whatnot in addition to customers that you've got to deliver by this time for this partner to be able to consume and do enablement on their side.
You get into some areas where sometimes the date-driven roadmap is fairly key because, like you had mentioned earlier, sometimes you actually have hard deadlines that you have to hit or that things have to come in place by now.
Or if they don't come in place by now, that's a bigger discussion at a higher level of the business to say, why didn't we meet this deadline?
Yeah, exactly that.
And so recently, and recently being in the last few years, ProdPad has added the ability to assign dates to items on the roadmap, and it kind of seems like that's merging these two ideas.
So what kind of led to that, and how's that been received by the customer base?
Yeah, absolutely.
I mean, this is actually a case of continuously doing research on how people do roadmaps, how they articulate different things, and paving the cow paths.
The thing that we did when we created the Now, Next, Later roadmap was we took the dates off the top and actually just created you blank spaces in these cards to articulate what it is that you're trying to tackle.
And for the longest time, we'd actually left that pretty up-to-interpretation, right?
If you wanted to add a date, add a date.
If you don't want to add a date, leave it blank, right?
You've got that flexibility.
But also, you know, it gave you the space to say whether this was a, you know, hard-fixed date, like this is a legal requirement that has to be done by August 2nd, right?
Or maybe it's a broad sort of thing saying, hey, we're aiming to have this done by Q3, or maybe something slightly more specific, like we need this done, you know, by the end of July or something like that, right?
We reformatted that into a specific date field that you can now use.
And there's actually two of them.
There's the actual date and the target date.
So the target date being when you're looking to get this thing out.
And just like, you know, the flexibility that the original blank doc space gave you, we give you the ability to leave a really broad date.
So you can say which quarter it's going to be due in, or you can say which month it's going to be due in, or you can say what day it's going to be due on.
But also, you can leave that off entirely.
You don't have to add a date.
The other one of that is the actual date.
So making sure that you're articulating when something did get done so you can do a comparison on that.
You know, one of the things that a lot of people tend to miss off the roadmap is what's actually been completed and what worked on it.
A lot of people think of the roadmap as just a future-facing document.
You know, here's where we are.
Here's where we're going next.
Here's where we're going later on from there.
But best practice isn't to delete stuff just because the time has passed and because you've finished the thing, but actually move it to a completed area where you've got this reverse chronological timeline of what you did deliver.
Because people are only going to trust that you're going to deliver what's in the future if you're actually able to show them what you've been able to deliver in the past.
That's a good point.
And that is something that a lot of times we do just drop right off the roadmap because it's the future-looking document.
We don't go and dig up copies of the roadmap from a year ago and say, what did we deliver off of this thing?
Well, no, exactly that, right?
And, you know, often what happens is you finish your roadmap from Jan 2024 and then by the end of the year, it's completely changed.
And so you can't even look back on that old record.
But what you can see, you should see a path of here's the stepping stones that we did take, right?
So we did this, this, this, this, and this.
You can see retrospectively what you did deliver that year.
And that's super key, especially lately when teams are under a lot more pressure to show the return on investment of these product teams.
So it's not just about how many features you shipped, but it's about did you actually solve these problems?
If you're working on a particular area of focus, right, you're saying that you're going to fix the checkout conversion.
You can show the three times last year that you cracked into several different experiments on it.
And which of those experiments worked?
Which of them didn't work?
It's a little bit like math class.
You get half the points just for showing your work.
You get half the credit as a product person just for being able to say that you ran a bunch of experiments and learned things.
And ultimately, if you're doing the experiments right and you're understanding your market and you're following a good process,
then if you continue doing lots of experiments, some will go in the right direction and those numbers will go into the right direction for you.
So a little while ago, we were talking about moving from kind of that date-driven roadmap into the now, next, later roadmap.
And one of the things of making that change is to actually up-level what's on the roadmap.
In a lot of cases, you will have a roadmap that's got just a lot of features.
And there's a whole desire to focus on what is the actual problem to kind of figure out what are these features actually solving for a customer?
Because, again, we deliver three different features that only the engineering teams and some people in management care about.
Oh, that was delivered now.
But outside the company, what people care about is the value that we're delivering.
What problems are we solving?
What would you say to someone who's looking at a roadmap that has to collect features from across a variety of different teams and they're working to try and pitch that value to the customers and get into this now, next, later mindset?
What would your advice be to up-level that if you're in that environment where you've got these teams that are kind of working independently of you a little bit and you've got to yet take all that together and build a valuable roadmap?
So there's a lot wrapped up in there, and I'm sure we can jump into a bunch of different rabbit holes or, you know, what about in this situation?
But actually, one of the really key things that I want to touch on is the so what test, right?
And I have looked at literally hundreds, maybe thousands of roadmaps now, right?
And one of the key things that I always ask myself is, so what?
Now, I don't know anything about your product or what you're building, but I should be able to articulate or understand more or less the sort of stuff that you're building based on your roadmap, right?
What kind of problems you're looking to solve?
But ultimately, it should answer the question of, so what?
Like, let's say, you know, you're given free reign and all the resources and you did actually successfully build everything on your roadmap.
So what?
Like, does it get you a lot of features, right?
Do you just now have, you know, that widget there and that doohickey over there?
Or actually, is the roadmap really clearly articulating that, you know, your goal right now is to increase conversion and then later on is to solve retention and then later on is to build out marketplace presence, right?
So there might be different sort of things that are much higher level that you can say, okay, I can now see what your strategy is rather than you just having a bunch of stuff to do.
Yeah, absolutely.
That's a great point.
So in another vein, you've gone from being a product manager to being a CEO.
How has that changed your perception on the role of the roadmap?
Yeah, absolutely.
And, you know, when I first started building ProdPad, I was the product manager at my company and a lot of ProdPad was built to, let's say, protect the product person, right?
In the way that, you know, oftentimes people think that product managers are where ideas go to die.
People often think that product people are making decisions off in their own little corner and it's not clear to anybody why certain calls were made.
And ultimately, like good product management isn't just done by a product manager sitting in the corner saying, you know what, I'm going to take my ideas and go build them.
It's their job to surround themselves with people in the team and ask really good questions and be transparent about the direction of the product, right?
So people can actively get involved.
They can pitch in better ideas.
They can, you know, help you discover what direction you need to be going.
Back in the day, we didn't really have good tools for that.
If somebody came up with an idea, I would have put it on a post-it note first and then it would go in and create like a Jira type ticket and people would then think that ideas would come to me and they'd die.
The other thing that it helps to do, and I was feeling this a lot back then, it was to reduce bias and create more awareness into, you know, why things are built in certain ways.
Because it's very easy to have a strong CEO or a strong leader in the company or a strong sales team who strong arms you into building stuff that isn't necessarily right, right?
Saying, well, this client has asked for it or, you know, CEO comes in saying, this is a great idea.
Put it in the roadmap.
Cool.
But actually, what you're able to say is, hey, here's all the ideas we have.
We've all agreed that these are the high-level goals and this is the direction we're trying to go.
You've just given me an idea that's over this way, right?
It's not near what we're trying to do here.
And you can actually visualize that in ProdPad.
You can see which ideas are time sinks or aren't related to what's key on the roadmap.
And so, you know, the first versions of ProdPad were actually analog versions of what became ProdPad.
You know, I used to take my entire backlog and put it on a big whiteboard behind me and then have conversations around and move sticky notes around so I can make it more visible.
It became a lot more useful once we digitized it into ProdPad.
But now I'm playing the role of the CEO and I have a product person.
We've got a brilliant product person on board with us who's a better product person than I ever was when I was a product person, which is great.
It's transformative.
You know, I realize now that I am that CEO with opinions who's come in saying, oh, I talked to this customer, I was at this conference, I've learned this thing.
What about X?
And our product manager is able to use our own tool to say, hey, yeah, your idea, cool, it's right here.
But here's all the other ones that are still more important.
And I go, yep, you're right.
I'd lost sight of those, but those are the key ones.
So it makes it really clear as to what's important to the business, to everybody.
And sometimes that really key stakeholder is your CEO who needs to be kept on track with a clear product strategy that aligns with what their vision is.
And, you know, kind of talking about the different perspectives and the different people that need to consume a roadmap, would you ever at any point recommend like having different versions of the roadmap for different audiences?
Or is it just a all up roadmap is the best way to go?
My way of handling it is always to have sort of like one main roadmap that has all the information, which frankly, to most other people is way too much information, right?
Only the product person really plays in this space.
But then you can sort of carve out different sites, different angles of it.
You're not creating different roadmaps, but you're creating different cuts on that same roadmap data.
Or your execs, they don't care about the tiny little nitty gritty, what features are coming out when and which experiments are in flow.
They care more about, you know, what problems are we solving and are these aligned to our goals, right?
And also, very importantly, the completed roadmaps.
What have you done, right?
Is any of this working?
You might have your dev team who needs something much more fine-grained and does care about which experiments are being lined up for the next few sprints to go in.
But public, customers and, you know, the general public, you probably want a version of your roadmap that like hides certain levels of detail and certain cards.
So we built ProdPad.
This is one of the original use cases was to be able to create these different versions and build it off one sort of main roadmap and then spin it out into other ones for different stakeholders.
What has it been like building products for product managers?
That's a unique space to play in.
You're a product manager.
You turned into a CEO.
You build a product for product people.
Product people are brilliant to build for, right?
I mean, I've had a number of products that I've worked on in the past and product managers are by far my favorite type of user.
They have a sense of humor that's in line with the product development process, right?
They know when I tell them, hey, you know, it's a great idea, but I don't know that I can promise when it's going to be out.
They get it because they also feel that pressure and know that they can't make the promises.
But I can point out to them saying, you know, here's where we're going with things, right?
This is what we're trying to do with it.
And they'll give feedback that is articulate and useful.
I mean, we've literally had people as front pad customers write in almost in user story format saying what it is that they'd like to see out of this thing.
And some of them have been like, yeah, that's actually a great idea.
And also aligned with what we're trying to do and is well written.
We can basically just ship that to our development team and start working on it.
We get really good quality feedback and well-considered conversations with our product people, with our customers.
That's really good to hear.
That is what you'd expect, but that's really neat to get to play in that space of doing product for product.
And also really cool to enable other product managers to build the cool stuff that they're doing.
Like, I love a niche, right?
I love when I talk to a product person who's working on something that, you know, in hindsight, you go, of course, there's a product team behind that.
But you wouldn't have thought about it until you've had this conversation.
And what you realize is that there's cool product teams working everywhere, doing all sorts of kind of geeky or niche things that, you know, you can have a fascinating conversation with them about what it means for their customers.
But ultimately, the underlying processes across all of these different types of orgs seem to be very, very similar.
Yeah, and that's fascinating insight to get from working with all these different product managers to see how similar all of this really is, even though there are definitely differences in the disciplines for which we build products for.
And there's a question out there about should product managers be technical?
And it's like, well, if their product is a technical product, the answer is probably yes, they should.
Because I think, tell me if you agree or not, that a product manager needs to have some level of expertise in the area of the product that they're building.
Yeah, absolutely.
That expertise doesn't have to come with them, right?
Oftentimes, great product managers might have completely different backgrounds.
But by way of talking to all the stakeholders around you and your customers and everybody else who's been working on this product, you'll become an expert in that area.
I know this because I've become expert in some surprising niche things, most of which knowledge I haven't held on to.
But I certainly realized that I got right into it.
I'm like, oh, wow.
Yeah, because now I understand why we need to build this thing this way.
And so anybody who's saying, oh, well, I'm in e-commerce.
I don't know whether I could work in health or whatever.
Yeah, you can.
You'll get it in there and you'll figure it out.
Does the product manager need to be technical?
Now, I think if you're working on a very technical product, it helps to have a good understanding as to how the high level it works.
But you don't necessarily need to know the nuts and bolts.
You certainly don't need to be a coder, right?
I think there's very few cases where you actually need to be a developer yourself.
My cohort of product people, you know, when I started getting into this thing, a lot of the jobs out there expected that you had a computer science degree first, right?
And I was like, oh, I don't have anything like that, right?
I came from the customer support, customer success, sales type of background.
But actually nowadays, because tech is so much better handled these days, right?
I mean, we're even entering into the world where, you know, soon we're going to have teams building almost primarily using AI, no code, low code type stuff.
You don't need to know the coding languages themselves, but it is useful to have a good handle on the constraints, whatever it is that you build in gives you.
Yeah, I think that if you do know the coding languages, there's a little bit of a temptation to want to get in there and get a little more on the engineering level and kind of pull yourself out of the product level.
Yeah, it can actually be dangerous.
You become a solutioneer because you go, oh, well, I know how to solve this thing.
And you pull up your knowledge of how you would have coded this thing when you were a coder three years ago.
And actually, that knowledge is outdated, right?
Like the people who are best at coding it are the people who have been actively doing this stuff day to day for the months and years before this.
If you are an out of practice developer doing product management, don't try to hack it together yourself, right?
I mean, you can use an express in code if that's how you talk, but expect it to be rewritten, right?
Like whatever you thought you knew is not going to be valid going forwards.
Yeah, there was a situation at my last job where I had come up with a how-to.
I thought that by writing a how-to for customers, I was doing a good thing and I was, you know, helping to bridge a gap between engineering can't get there yet.
But we've got a path to do it today.
I wrote the how-to and it was the most complicated thing I'd ever written.
And so then I turned it into a script and before I knew it, I'm like, uh-oh, I've just engineered something.
And I handed it over to my engineering team and I said, please take this.
I'm not going to maintain it.
I don't want that responsibility.
Don't let me jump into this.
So it can happen.
It's tempting to do that.
Yes, it is.
So you talked about AI.
That's a huge topic.
How do you see AI shaping the product management field?
I mean, it's already shaping the field, right?
So we can see this in flow right now.
I think a really key thing is that I don't believe product managers are at threat of losing their job.
I don't think AI is going to replace product management anytime soon.
But I think it's going to change what product management involves, right?
So, you know, if I look back at my history as a product manager, I've spent a lot of time, I don't know, specking out the same junk over and over again, right?
Every company I've ever worked for, I've probably specked out a login page and a tag system or whatever, right?
And actually, a lot of this stuff should be more or less solved because, you know, one login page should actually look like somebody else's login page, right?
I should just be able to say, you know, hey, I've got an idea for an app and a user is able to log in and does X.
And the login part is, yeah, you have to have it.
It has to work.
But actually, it doesn't have to be special, right?
That's not where you stand out.
And yet, product managers of the past have spent a lot of time specking out and getting these types of flows working.
It's the user logs in and then X, whatever that X is, that's the key thing that, you know, makes your app special.
And you need to figure out what makes your app special, how that's valuable to your users, and how that's going to be valuable to build for your company, and build it within the technical constraints that you have.
And today, that might be, you know, using a mixture of AI and own written specs and using a mixture of AI and own written code to do that.
Down the line, it might be all AI written specs and code, just with the product manager making those decisions based on what they have pulled in from insights externally to make sure they're building the right stuff.
Yeah, that's an interesting point.
There's definitely a handful of different opinions on just how far AI is going to go.
But I think one of the big things we all have to remember about AI is that at its core, it's a large language model.
It's literally predicting what's most likely to be next.
If you don't have the training data constantly coming in with new, fresh ideas, then your AI output gets stale and less useful.
This is where product managers become really key.
I mean, think further and further into the future when building an app is as easy as me just saying something into my phone.
And it allows me to quickly build something without even needing a development team, without needing to spec anything out.
The job of the product person is going to be to curate, right?
To decide which features get built.
To decide which features get moved on to be promoted in various ways, right?
To bring the stuff up to some sort of level of visibility.
When it becomes so easy to create features that actually I can give my AI agent an idea and it runs off and creates 10 versions in a second.
Cool.
But who actually decides which of those versions are useful?
Who actually decides what to tell that AI?
And if we're not careful, you end up with AI feeding AI, as in it's using the same outputs as its training data.
And ultimately, you won't end up with anything that's unique or valuable.
And humans are always looking for that new thing that's going to create value in a way that hasn't been done before.
And so humans are going to be the ones to interpret that because we've got the context.
We've got the empathy, the way to talk to customers, to pull out this insight.
And then ultimately make that call on which direction we point this thing.
Yeah.
And that's where AI is not taking over our jobs.
But if you think about it this way, the role of product manager 30, 40 years ago is completely different than it is today.
So, you know, what's it going to be in 30, 40 years?
I mean, probably completely different yet again.
It is a fast evolving field.
And like you said, it's going to keep evolving and it never sits still, which is part of the fun of being a product manager is that this is just never sitting still.
It's never the same thing twice.
So how is ProdPad as the product helping product managers now and how do you see it preparing product managers for this future as the industry evolves?
Yeah, absolutely.
So what ProdPad is, it's think of it as like the operating system for your product-led team, right?
So you need a space to articulate what direction you're going with things and, you know, what's playing into that.
What it is, is a tool to capture your high-level vision and your goals, but also things like the steps you're trying to take to meet those goals, your roadmap, for example.
But also stuff like the ideas and experiments in your backlog.
Which of those have you done?
Which of them do you want to do?
Which of them have worked, haven't worked?
And everything that your customers have asked for as well, right?
So it pulls in all of this insight from these different angles and gives a space for the product manager to ultimately guide the team and make decisions on what we're going to work in this direction next.
And then after that, we're going to go over here, which involves these experiments.
And that's all based on this customer feedback.
What it's doing is creating a space that is transparent for the rest of the team, but also creates a bit of defensibility for the product manager decisions, right?
So product manager has to prove that they are creating ROI, is able to show the work that they're doing, and back up why X is on the roadmap next, and this other thing is way off in the future.
But where we're building towards, and what you'll see in our most recent releases of ProdPad, is that we've underlined it all with AI, a co-pilot that now knows what your vision is and what your goals are and what's worked, what hasn't worked, what all your customers have asked for, and is there to help make these decisions faster and with more confidence.
Being able to do things like, you know, all the questions that you normally tap your product manager on the shoulder for, you can now just ask this co-pilot, like, hey, have we ever built anything that looked like this?
What happened?
And it'll dig back through your history and be like, yeah, you did this, and the experiment went this way, and so-and-so said this, and you decided to do X.
Cool, right?
That would have taken a while to dig back up if you didn't have this sort of tech.
But also things like, you know, can you summarize everything that everyone in this sort of market is asking for from us and, you know, compare that to what our competitors are doing and then help me write an idea for my backlog that will help address that problem.
That sounds really quite nice.
Yeah, that takes a lot of work to be able to pull that together just manually and to have a large language model read your data that you've given it and be able to spit out answers based on that is a fascinating development in product management software.
We're certainly helping cut down the number of cycles that we have to spend on menial tasks, quite frankly, and being able to get to those answers and make real decisions.
It's all those menial tasks and all that grunt work that we're eliminating so that product managers can do what's important.
And, you know, I think that we've said for years and years and years, you know, you got to get out of the building, get out of the building, go talk to people.
That's the way you learn how to do good product management.
But I think so often product managers have been bogged down, well, I can't get out of the building, right?
I got to make this roadmap that's due for tomorrow and I got to, you know, write these specs and I've got to help the Q&A team on this thing because it's getting bogged down as well.
And actually, all of that stuff is pretty menial stuff, pretty much grunt work.
And so if you don't have to do all that stuff, then what are you going to do?
Get out of the building, you know, spend more time talking to customers and, you know, exploring the world and discovering what's actually needed to be built.
You will no longer be able to hide behind the pile of work.
You will have to get out and talk to customers.
Yeah, exactly that.
I don't think product managers are going to get replaced.
But if your job basically has been to just write specs and push papers around, then AI is going to take over that stuff.
But it's going to enable the people who want to do true product management to do more of that.
Yeah, no, that's really great.
And I love that perspective because it shows it's a healthy AI isn't coming for your job, but it's AI is going to allow you to do what you thought you signed up to do in the first place.
Exactly that.
Yeah.
So, Jana, one final question to have our audience get to know you a little bit better.
What is one goal that you hope to achieve in the next year?
That's a great question.
So, our goal here at ProdPad is to enable people to do more with less of their time, right?
We know that product managers are under a lot of pressure.
And so, you know, we've only just launched this co-pilot thing.
We're taking in beta users and collecting feedback on it and, you know, really collecting different use cases that we can test against it.
You know, what we're finding is a really surprising array of different stuff that people want to do with AI once it has access to their entire product world.
And so, you know, what do we need to test for?
What sort of cases can we build in so that it makes it even faster and easier to use?
And ultimately, by the end of the year, we're hoping we've got all of our customers making use of it and accelerating their efforts with it.
Well, thank you so much for coming on the show.
Glad to have you and good to talk.
Yeah, wonderful.
Thank you so much for having me.
This has been great.
Thank you.