[On Demand] Product Management Webinar: Product Management Toolstack

Megan Saker: [00:00:00] Hello, everyone. Welcome to today’s webinar, ProdPad webinar, how to build the ultimate product management tool stack. So just before we kick off, just a bit of housekeeping. There is, as well as the chat, which is great. I can see that some of you are.

Messaging in there now and telling us where you’re joining from, feel free to use that at any point. Throughout the webinar, we are going to talk, be talking about tools. And so one of the things we want to do is encourage you guys to talk about what your tool stack looks like, what you write, what you don’t write, et cetera.

But there’s also, you’ll see a Q and a box separate to that. We will make sure we leave a bit of time at the end for any questions. So at any point during the webinar, if you think of a question that you want to ask Janna, pop it in there and we’ll get to those at the end. We’re here for an hour, yeah let’s kick off. Just before I introduce Janna, let me just explain to you a little bit about ProdPad. So those of you [00:01:00] who don’t know ProdPad, who aren’t already a ProdPad customer, we are sort of end to end, all in one product management platform. For product managers to manage their idea, backlog, communicate and build their road map and gather and analyze their customer feedback to inform that road map.

We also have the most advanced AI capabilities of any product management. Tall in the form of our co pilot. So we have an AI assistant there primed with product managementbest practice, but we will tell you a little bit more about that later on. But ProdPand was founded, co-founded by Janna and her co-founder Simon.

Janna is also the inventor of the Now-Next-Later roadmap and an all round product management thought leader. Without further ado, over to Janna. 

Janna Bastow: Wonderful. Hey, thanks so much for the warm intro and for setting this all up. And thanks everybody for [00:02:00] joining. So today we’ll talk about what we’re going to cover.

You’re product people and you know better than anyone about how the right tool can transform your work and your results. So if you’re anything like me, a product geek, discovering a new tool or unlocking hidden capabilities is really exciting. There’s a lot of fun here. Plus each new tool that you.

Come across might spark ideas that you can bring back into your own product or your users. So that’s exactly why I love talking about the right tool stack. My expertise centers on product management tools because I’m a product manager by trade. This is my background. And of course, having built a product management tool myself.

This is truly my space. Today I’m going to share what I believe makes up the best tool stack. But I also want to hear your experiences. I’m mainly focusing on tool types rather than specific brands, cause there’s just too many out there. So please chime in on the chat, what tools you use, what.

Whenever we’re talking about a tool, is this something that you’ve tried? Is it something that you’d recommend and would bring it to your next business? I’m also going to be running a couple polls to gather your input. So I’d love to get your insights there. They’re not going to be able to cover every tool in the market [00:03:00] though, because obviously there’s just way too many.

But let me take you back to 2009, 2010. Let’s call it the dark days of being a product manager. If anybody’s been in the game for that long, you know what I’m talking about. My tool stack back then revolved around things like anybody remember Track or Bugzilla? They’re like the precursors to JIRA, and remarkably still going, but I just don’t hear about them so much.

And basically it was whatever else we could cobble together from the Microsoft ecosystem. And it felt clunky and inefficient, and I was constantly frustrated by how hard it was to get a clear picture of what was going on in the product and why certain decisions were being made. Those early challenges are actually what motivated me to create ProdPad, because I believed, and still believe, that better tools lead to better products.

And we now have evidence to back that up, which is great. Now we find ourselves in 2025, and yet, when I hear people talk, the status quo hasn’t changed. Nearly as much as you’d like. The names of tools have shifted to things like [00:04:00] Jira and Google Docs or other generic solutions out there, but the underlying problems remain.

If anybody was paying attention, Lenny Rochitski did a survey on tools recently about tools used by PMs, and it highlighted just how widespread this challenge still is. So today I want to share what an optimal product management tool stack looks like in 2025. And there’s a real opportunity here to evolve beyond the patchwork approach that we’ve been relying on for way too long.

So I’m going to show you how. To start with I want to take it back a step and think about what it is we have to do as product managers and as product teams. What problem are we looking to solve? And we can assess what jobs can be enhanced with tools. With this, I’m going to go from broad to specific.

Like this is the broad cycle that product managers use to move ideas from concept through to delivery and beyond. It’s not the same as a product’s overall life cycle, life stages. It’s more about the process that you follow for each new initiative and feature and even a whole product. And of course, we know that these things aren’t linear.

I’ve shown it as a [00:05:00] loop here, but of course, these things go in different directions, let’s start with business outcomes. This is where the overarching strategy comes in. Your OKR is your vision and defining what value you want to drive for the business. It sets the objectives that you’re going to translate into product strategy.

And that goes into discovery, whether you’re developing a whole new product or just a feature, this is where you research and validate the problem space. You’re asking, is this worth our time? Which solution is likely to achieve the desired outcomes we have? And then in validation, this is where you confirm whether your hypothesis actually stands up.

If it doesn’t, you pivot or abandon the idea. And if it’s solid, you move forward with more detailed planning and then into the build stage. This is about your specs, design sprint planning, development, testing. Your dev team is hard at work making the concept a reality. And then into launch and for launch, this can mean a number of things.

This could mean closed beta, open beta, iterative releases before general availability. We’re not talking about just. Big bang launches. Your marketing, sales and customer success teams here, jump in to make sure that the launch is [00:06:00] successful and well supported. So a lot of cross team collaboration here.

In fact, next month’s webinar is all about this launch phase. So there’s so much that goes into it. So we’re going to talk about the launch phase and how to do it right. So be sure to look out for your invite on that. And then we want to go into the evaluate and iterate stages. After you assess whether you’re hitting your target outcomes sorry, actually launch, you assess as to whether you’re hitting your actual outcomes.

And then if you need improvements, you return to discovery to figure out next steps. And there’s almost always improvements to be made. So that we know this is a very iterative process. It’s essentially a continuous loop. You bring ideas through to discovery, validation, build, launch, measurement, and in a circle.

But always trying to tie back to your overarching business outcomes. So I want to look at how the right tools can support each of these stages. So let’s look at it like this. The first thing to note in here is the overlapping validation, validating section, right? This is positioned like that because in reality, your validation.

So I want to talk about beta testing [00:07:00] if I feel like, generally pretty much always overlaps building, especially if you’re creating a prototype for proof of concept and user testing with it. Anyways, I started to break down the types of jobs you’re doing within each stage that can be enhanced with the right tools.

Now, I actually want to jump into a poll because I want to ask everybody here, where in the product lifecycle are your biggest gaps? And let me just launch that poll for you. There we go. So we’ve had a poll launched. You should be able to see this. Let’s go back to the previous slide here so we can just see the examples here, but where are you seeing your biggest gaps in terms of your tooling?

Yeah. And that can 

Megan Saker: either be, if you’re lacking a tool in any of those particular areas, or that your current solution isn’t doing a good enough job for you, or maybe you’ve got frustrations with your tooling in that area.[00:08:00] 

Janna Bastow: Excellent. So we can see the answers coming in thick and fast here. I’m not sure if you guys can all see this as well. Can you see the question now? Okay. It’ll come through when I end the poll, but we’re seeing a few of the areas kind of neck and neck. Other areas look like they are better solved for.

That’s what’s interesting. I’ll give this another share of the poll with you and that way we’ll be able to see them. Ian has pointed out that validating isn’t on the list and that’s a common problem. That’s a good point. That’s the validation, sits between a few different areas, right?

It’s part of the prioritization and part of the design prototyping stage is part of strategy and road mapping. But actually, yeah, validating as a standalone problem area. Yeah, thanks for the insights there. And as he said in chat for anybody who’s not paying attention there, he’s talking about how to avoid the shiny object syndrome problem, which is a real issue for people making sure that the stuff that you’re building is in fact the right stuff.

Megan Saker: Yes, we published an article actually on that and how to avoid that. So if you are suffering [00:09:00] Shiny object syndrome or stakeholders, particularly with shiny object syndrome. We have got an article included in the email after this with loads of advice on how to. Deal with that. 

Janna Bastow: Excellent. Thanks, Megan.

And thanks, Ian, as well. I have shared the poll here, so you should all be able to see that ooh, it was very neck and neck. I think literally neck and neck between strategy and road mapping and prioritization with idea capturing following straight behind. And I wonder if people who are thinking about validation put that under idea capturing.

Cause we think about it in BroadPad, but we’ve got the idea management area, which includes capturing, but also helps you with that validation. Also seeing documentation and collaboration coming up shortly afterwards and funny enough, design and prototyping. People are saying it’s a solved problem.

And actually, maybe, follow up, I wonder if this is because it’s already solved, people already have their tools for it, or it’s not an area that they need solved, as in, it’s not an area that they are looking to solve. That said, I would [00:10:00] guess, my hypothesis is that there are a lot of different design prototyping tools out there, so everyone got that sussed up, whereas these other areas, these are where the holes are.

But I could be wrong. Let me know if I’m wrong in the chat. So we’ve talked about the gaps. Here’s a representation of an optimal product management tech stack. We’ve given all the different layers that you might want to consider in there. And I want to get into examples of particular tools in a bit, but this is really all about the basis that you want to cover in terms of your tooling.

So let me know what you think of this. Are there any? Gaps that I’ve put in here. Now I’m squinting to see. I’ve got this small version here. We’ve got validation. Not directly. I put that under idea management. But yeah are there any, is there anything in here that isn’t necessary that you don’t cover?

Which of these could you live without and which of these could you not survive without? Would love to hear your thoughts on that in the chat.

And in the meantime, I will put some faces to the names here, [00:11:00] right? So I want to see that you’ve got these, the big teal blue squares representing ProdPad. And this is the areas that that our platforms offer that our platform offers. Now there’s alternatives in the market but none offer quite the same comprehensive coverage of different areas.

But whether you use ProdPad or another platform, the key point is the most efficient stack always hinges on having a central. home, right? A base. Think of it as like your operating system for your product work. If you rely solely on a bunch of disconnected point solutions, like just one tool over here for OKRs, another one over here for roadmaps, another one for feedback, another one for ideas, you lose that essential connection between them.

Because everyone’s roadmap is not done in isolation. It’s done based on the insights that come from your objectives, how are those going? What are your customers asking for? What sort of things are in your backlog? So these connections are what basically power seamless decision [00:12:00] making.

They power quick prioritization and give a clear, unified picture of your product status. What this combination of central tool and point solutions looks like can vary, but this is what I would recommend. Yeah, here’s a a list that you can digest here. But I want to explain some of this.

I want to split out the stack and pull one element out, starting with the delivery and development planning tool. So the best way to construct your tool stack when it comes to delivery, development planning versus your idea backlog and road mapping planning, I’m going to pull that out and look at that.

So you’ve seen what an optimal stack looks like. And most importantly, how these relationships work, how your idea management and product backlog interacts with your delivery planning and the connection both have to your customer feedback. So this is the optimal tool stack that we’re looking at here.

This is how it starts to break down, right? This setup is all too common, right? This unwieldy stack with no single home for strategy or pre development planning. The typical breakdown where, what you’re seeing here is like strategy and vision and [00:13:00] OKRs are trapped in slide decks or spreadsheets, a Google Doc or, a PowerPoint somewhere.

Roadmapping. How many here have their roadmap stuck in static slides of sorts. There’s no dynamic link to the day to day progress or the outcomes. It’s not living, breathing. It’s just a picture of your roadmap as he thought it was, last month. And then delivery and execution. Most of the time when we’re talking to people where this stuff is taking place in JIRA, Azure DevOps, Trello, Asana basically point solutions for the development process.

Now, the thing is, the trouble starts before something even gets to the roadmap, incoming ideas from stakeholders or customers or, the PM zone brainstorming don’t have a dedicated place to live while being assessed and validated. Back to the point that Ian was making about validation, they end up lost in the same delivery tools, right alongside the fully specced and in development work that’s approved, ready to go and is in flow.

Everything just gets clumped together. You also end up with no connection to the roadmap, [00:14:00] single backlog might have rough, unformed ideas and tasks that developers are actively working on. And, if not connected properly nothing ties these items back to the strategic part, the strategic roadmap.

And also, you see this lack of connection to feedback. It often sits in another silo altogether, so you can’t see. how much feedback from customers is related to any particular idea, you end up missing critical insight on whether that idea or that feature that, that that you’re looking to build, that, that problem you’re looking to solve is actually a real problem and how it lines up with your broader strategy.

It just becomes disconnected. And so you end up with this slower process more work to get the insights out of guesswork heavy decisions, right? People are just trying to figure out from their gut feeling rather than from what they’re actually seeing in the data. And then just generally limited visibility from feedback to idea, to roadmap, to strategy.

And there’s just a ton of manual effort to connect [00:15:00] up these dots across multiple disconnected tools. And so let’s explore the full journey that any idea goes on to show you why you need different tools for strategy and execution. So ideas can come from top down from strategy and objectives or bottom up from customer feedback.

And ideally they can emerge from anywhere in your organization, right? The reality of it is that insights and innovation comes from anywhere. After ideas are generated, you refine, you prioritize, you validate them, you decide which ones are actually worth your team’s time. You validate those assumptions, you spend time defining the solution, you work on specs and design, and only then is it ready for development in any sort of production state.

And herein lies the common problem. A lot of teams try to manage this entire process, the wide slate of things we do for strategy and discovery and validation with execution, which happens in generally tools, as I said, like Jira, Trello, Azure DevOps, that sort of stuff. [00:16:00] These are tools that are great for project and task management, but they’re not suited for the more strategic idea, validation, discovery, that sort of opportunity backlog triage that strategic thinking, and also, spare thought for your developers, tools like Jira and Trello, Excel at delivery, organizing the tickets, the tasks into sprints and showing you that work in progress, but when you use them to manage your pre development, Work, all that stuff that could be done.

It leads to chaos. You get these unvetted ideas just getting jammed into JIRA random stakeholder requests, again, getting thrown at the developers, half formed concepts, which, sometimes those half formed concepts are gold, but they’re not ready. They shouldn’t be piled in the same place as fully specified tasks.

And then, developers have to wade through that noise, they’re sitting here going, they’ve got this huge, big, long backlog and they can’t autonomously pick at it and say let’s work on this one, because they don’t know whether it’s been spec’d out, they don’t know whether it’s been [00:17:00] approved.

So there’s a lot of items there that may never actually become actual work for them. So really what you want to do is give your team a cleaner space to focus on execution, having a list of clear things to be done next that they can burn down through or work their way through in a Kanban, whatever it is so that you can have a separate space for the strategic pre development thinking where you can refine it.

Ideas, validate, different experiments that could be run, discarding the non starters and only push validated, spec’d, approved tasks to your delivery tool. And it just keeps everyone more focused and helps maintain sanity with everybody in your team. You see this.

The complete process is a game of two halves. Two different disciplines at play. The first half of the flow is where you as the product manager play, it’s strategic in nature. The strategy work is around researching, assessing, evaluating, prioritizing, deciding it’s the what and why.

Whereas the second half of the process, these stages are all from the middle down or [00:18:00] execution, tactical execution to deliver well defined work. This is planning, building, testing, deploying, that sort of stuff. That’s the how and the why.

The really key thing here, one of the first rules is to separate your strategy from execution. You have your strategic stages and your execution stage, and give each space its own space. A dedicated tool, a dedicated area. And you reduce clutter for everyone and ensure that each stakeholder has exactly what it is that they need, without getting bogged down in different aspects of the process.

You should have different tools and different spaces. Have something like ProdPad for the Strategic work and something like Jira, Trello, Azure DevOps, whatever it is you’re using downstream for the development tools. And ultimately from there, everyone wins, right? You get developers with a more manageable backlog for better focus and ultimately better morale, right?

They’re able to work more autonomously and be able to see very clearly what needs to be done, whereas [00:19:00] you get a dedicated space for prioritization, validation, decision making, you can validate decisions in an area before committing to anything on a roadmap, and it makes it easier for the rest of the stakeholders, right?

You can communicate that plan to the wider team. So you give them an easier view rather than just dumping them in JIRA and saying, let’s see if your idea gets done or not. Having something upstream makes it so much easier. So if anybody’s thinking about it, Okay. When you’re doing a switch like this and offloading something from Jira into something like ProdPad we know how it can become this horrible mess in Jira.

What we’ve done is we’ve actually built in an import that allows you to connect ProdPad and Jira. It pulls your messy tickets from Jira and then uses ProdPad’s CoPilot, our AI tools, to assess what you’ve pulled over and helps you clean it up so you can stay on top of it and start working basically the way that I’ve shown you.

If you want to know more about this, we have made a video so you can actually see it run through examples on how CoPilot can help you [00:20:00] deduplicate that backlog once you’ve pulled it in, link all the ideas to feedback, link it to your compare Your ideas to the product vision and test alignment with the roadmap and just flesh out everything you’ve pulled over that might be just like these stubs of tickets that were in JIRA.

You can give them a life and space to breathe in ProdPad. What this allows you to do is separate your strategy from your execution. Check out that video. We’ll drop it in the chat here and we can also send it to you following this recording, but back to the stack. And it’s.

whole glory here. Hopefully I’ve convinced you about the benefits of having a core platform as your home, your source of truth. And then, over on the right are different suggestions for point solutions that you might consider. But the key to this is thinking about the interplay between these tools, right?

You don’t have to have one of these tools. In fact, I’ve met some teams who have multiple design tools and no[00:21:00] 

Testing tools, for example, AB testing tools that might be totally fine, depending on the context of your team. But what you want to make sure is that when you do have these tools, you’ve really assessed how it’s going to fit within your process and how they connect together. So that connection is really important, right?

You want to make sure that your product tool stack integrates. With each other, right? It’s going to make your communication more effective and streamlined because a big part of your job as a PM is you’re the glue that brings together a whole bunch of cross functional efforts. You’re the custodian of product strategy, and you’re the one that people come to for updates and who, what.

When people are looking for information, you get your tool integrations, right? You should make it’ll basically help make sure that updates and info are shared more easily with your stakeholders that it just takes the manual load off your shoulder. It should also improve the efficiencies of your workflow and [00:22:00] process, right?

You don’t want to be copy pasting stuff from one place to the next or constantly having to reference things from one place to the other. If you have everything tied up and synced into one place, it means that people aren’t having to hunt around for different logins. It’s all centralized in one source of truth.

It reduces the risk of people being out of the loop as well, which makes your stakeholders happy and makes sure that you’re doing your job of communicating over and over again. Again, it makes it so much easier and makes it easier to make decisions. You can make stronger, more informed decisions that are more defensible as well, because you’re able to see the complete picture and make sure that you’re making clear decisions that pull together the insights from different areas, right?

So what’s going on in your design area? What’s going on? on with your objectives. What happened in that last test? What has happened since you launched something? It’s all tied together. You got a clear picture as to what the inputs are and where something’s gone. Once you’ve actually acted on something, done something with it, launched it.

So it just helps you make a [00:23:00] clear decision around what you can do to hit outcomes or whether something’s actually worked or what customers are asking for that should inform your priorities. So when you’re thinking about how these tools all need to work together, you need to consider things like who needs to be informed, right?

Identify which stakeholders need updates at which stage decide which tools or channels those updates should flow through. Who needs to contribute? Determine which roles will be adding data or feedback. Is that stakeholders customers, team members internal, external, whatever it is, and determine how and when their input feeds into your product process and also think about where integrations can reduce manual effort?

So look for any repetitive or time consuming tasks, like copying info from one system to another, or trying to get updates across the board. You can automate these handoffs wherever possible, wherever you can see the data is flowing seamlessly. And also think about what [00:24:00] data do you need to make decisions and where.

So what helps you make decisions, which metrics or feedback are crucial to each decision point. And make sure that the data is available in the tool where those decisions are actually made. I’m gonna try and have it all with that same source of truth or pulling into one place, it becomes your source of truth so that you can make those calls and have a much faster loop, a decision loop, really.

So start by making these lists for each of these and understand where you’re looking for comms to go out, where input should be coming in, where data needs to be going in any direction so that you can figure out where efficiencies could be made. Answers might look something like this.

Now the next thing to consider is how valuable these things would be to you, us product people love a good stack rank, so I would rank them right. Maybe the most important to me is the contribution from customers in terms of the feedback. So making sure I have visibility where I need it in terms of my customer feedback would be priority one.

Then I wanna make sure that the dev team contribution is as smooth as [00:25:00] possible, otherwise it’s gonna slow us down and create a big headache for me if I have to go chasing down developers for their estimates. So nailing that is my next priority, and I absolutely hate having to. Dig out status updates for stakeholders who want to know where their idea is or what stage something’s at, right?

It’s just really time consuming and ends up taking you out of your flow over and over again. Maybe you want to prioritize having a sync between your dev tool, your dev planning tool and your roadmap. So you can see one from the other. So work out. Questions like this until you know what your deal breakers are and what you’re nice to have are understanding how important they are will help you know whether you need to have a native integration or whether you’re, willing to connect things with Zapier and duct tape and other tools or whether you need to get your devs on it to help with API stuff and webhooks or whatever it is.

Some examples of useful integrations that are possible one example here is ProdPad’s integration with Slack. We do the same thing with Teams as well, where you can keep everyone informed by pushing ideas and feedback into [00:26:00] dedicated channels in Slack or into Teams. And you can encourage contribution and engagement by syncing discussions between teams.

Prod part and with slacker teams? So you can be in ProdPad and the rest of your team is in slack and they’re able to contribute and add questions all in one thread. And it’s real time chat directly in one tool or the other. Or even just being able to say, you know what, this was a conversation that was interesting, let’s take that and put that over here with one, click, as opposed to having to copy, paste, just being able to select a message and drop it directly in.

We also talked about syncing your development tools. Here in ProdPad we have separate strategy and delivery tools, but the two have seamless two way integration. Once the idea is validated, spec’d it’s gone through and been approved. It’s ready for developers to work on.

You just press a single button and it pushes the idea to say JIRA in this case, and the two entities sync back and forth. You can also track status and progress directly from ProdPad, like in your roadmap or in the idea record itself. So it keeps the idea record up to [00:27:00] date. And then once the final stages of the development process are complete, you pick it back up in ProdPad, just because the developers say it’s done, doesn’t mean it’s done.

So there might be other stages that you have. That you’re managing and like post delivery, making sure that it matches the expectations. I hate your target outcomes and then making decisions about iterations, communicating it to customers, the wider team and then also things like you might have integrations between your change log tool and your live chat system.

Another example here of showing Beamer here. You can: You’re trying to reduce the manual work of communicating outwards. In this example, Beamer integrates with Intercom. So your changelog is automatically pushed to your Intercom chat interface and then flagged to all your users. One tip. That I always tell people is when you’re integrating tools in your stack lean on the vendor whenever you can, right?

Get them to help you. If you’re setting up an integration, talk to the players that you’re integrating. They’re generally pretty happy to help. Here at ProdPad, we’re more than happy to [00:28:00] help any customer get set up and have any sort of an integration. focused session and implementation session, make sure that everything’s hooked up the way that you want to to make sure that everything’s running smoothly.

And I know that other vendors do the same, right? We always lean on other vendors when we’re looking to connect stuff up.

No, we can’t talk about a tool stack without talking about AI tools. If used well, AI can transform the way you work, like what you’re able to achieve, the progress you’re making, the speed you’re able to deliver it. I was just talking to somebody else, somebody today who was saying that they’re looking to reduce the time to delivery by 95% by using AI tools.

Being effective. Using AI is going to become a vital skill for product managers and look, I realized there’s some trepidation around AI. There’s a lot of talk about AI’s potential to replace certain roles across the spectrum, but there’s also tons of commentary and evidence suggesting that product management is not one of these ones that’s going to get replaced.

It’s [00:29:00] one of the core functions that’s the best place to capitalize on the benefits offered by AI. But rather than the entire discipline being automated and therefore replaced by AI, product management stands to gain advantages if we use the right tools. So this is really cool, this is really key is to understand the tools that are available to us so that we can move faster and get more done.

Make smarter decisions and move our products faster and faster. So John Mada. Does anybody know John Mada? He’s a prominent technologist, and he’s currently VP of AI at Microsoft. He does a design in tech report that he’s just put out there, and he said that product people as talkers rather than makers PMs are likely to be less disrupted by AI in the way that many makers are going to be, right?

Where are the talkers? We’re not going to get disrupted. And, with that AI can expand what PMs are able to do and achieve and transform the value that we’re able to provide for orgs. I actually talked a lot about AI [00:30:00] tools and how to use them well in a previous webinar.

You can actually get the details on the slide there, but we can also drop you the link in the follow up. But check out the recording. We basically covered all the stages that the product management lifecycle can be enhanced by tools and talked about these different tools. But some that I want to flag up and point out for example, I’ve been talking about ProdPad’s CoPilot which allows you to know everything that’s going on in your ProdPad backlog, everything from your strategy to your vision to the things your customers have said and allows you to answer questions, but there’s also very on the spot, helpful with things like, Hey, do you want to help some, get some help writing these user stories or brainstorming some key results?

I’m also a big user of reclaim, which is a time management tool that allows you to rebalance your calendar based on what different inputs are in there. Fathom is one of my other favorites as well. It records your meetings for you and then does little summaries that you can use their AI to talk to, ask you questions and say, Oh, when did we mention this?

Or can you summarize this part of it? [00:31:00] Or write this follow up for it? Perplexity is really powerful for doing research. And what I love about Perplexity is that it backs it up with research on more scientific sources on the internet, which I think is really key for making sure that you’ve got solid research.

Mid journey for image creation, Tome for presentations, anybody using anything to speed up the presentation making? Prototyping as well. Prototyping has become, has moved from rapid to instant with tools like cursor, coda lovable, Replit, things like that. And then we’re here using Figma AI as well.

Again in the e design prototyping type area, but some really powerful things you can do there. We’d love to hear if there’s any other AI tools that people are using, whatever, what I’ve missed, because this space is moving super, super quickly. Every time I see something that comes out there, I always get a chance to jump in, see what it’s like, and then see what we can learn from that to put into our own tools, or to put into how we work.

Speaking of which, this is speaking of our own tools, this is ProdPad’s tool CoPilot. I mentioned it just a moment ago, but It’s [00:32:00] specifically designed for product managers to take advantage of the time savings and performance improvements that AI can give you. So we’ve primed it with product management best practice.

So it has the expertise, but it’s also been fed with insights from real product teams. So it always answers from a real product perspective. It’s been fed instructions about how good product managementbest practice works. So everything it creates for you is hyper relevant without you having to prompt it.

And then what it does, it’s connected to our platform. So it has all your product work in the same. So it’s got roadmaps, ideas, your idea backlog, all your feedback, your OKRs, what your team has been talking about, what’s worked, what hasn’t worked. And therefore, it can help you create documentation, field any questions around things like, Hey, where is this on the roadmap?

Or, have we thought about doing this? It can give best practice coaching and advice in general, or be quite specific and say, Hey, this idea you’re working on, this doesn’t [00:33:00] align with your roadmap. What are you working on? It can brainstorm with you and do like a whole month, a whole ton more as well.

So this is an evolving space as are other product tools, but would love to hear about people who are using that and use cases you’re putting forward as well as any insights on other stuff you’re using. Michael nerd just threw one into the chat. He said sauna labs which I’m not familiar with, but I’m definitely going to be playing with.

So you’ve seen my suggestion. The optimal PM tool stack, and you understand how this could all work in terms of integrations, but how do you get your hands on the budget? This is actually one of the more difficult areas. It’s really interesting to talk about because I see a lot of variance in

how much access Product teams have to budget. Some product teams have their own direct budget so they can spend on this stuff. Other teams have to claw it away from development or marketing or just finance in general. It seems to track with the maturity of the product function within the business.

If you [00:34:00] have a product ops team, then you probably have a product. Operations, tools, budget. If your team is an offshoot of your development team, you’re less likely to have your own budget. Does that check with other people as well? I’m actually going to throw a poll up in a second that’s going to talk about this, but I would love to hear anybody’s insights on it.

Or you can see it based on the value placed on the product, to which extent product management is seen as a significant growth driver for the business. The most product focused companies are giving the product teams an annual budget, a budget that they can use towards tooling and they have autonomy over how they’re going to spend it.

But there’s no predefined budget and you often have a case for having to spend it, make use of it, and pull it out of the company where needed. So I want to launch a poll here, and I’m going to ask you all some questions about your own budget and what you already have.

And then we’ll talk about how to get that budget in place. Let’s go back here and launch poll two. Great. What access do you have to budget for tools? What’s going on in your place? So no budget at [00:35:00] all. No hope of getting any. You can pitch for a budget if you have a strong reason. You have to submit your tool request during budget planning season.

Or you have a predefined budget that your team has, for your team needs, and you can spend it how you see fit. Or, if none of these fit, let us know in the chat. What have we missed here? And I’ll just give people a second to jump in on this.

I’m seeing one of these answers poll right at the top, and then a few other outliers. But we’ll have to get a few more answers here, and then we will share this poll with people and we can talk about the results.

Megan Saker: Alright. And actually, probably, regardless of the results, even if you have got a budget, given, Or you’ve got, you can submit your tool budget. There’ll be times outside of the budget cycle where something great, particularly now with all the AI tools, something great comes along. And so how do you convince people, convince the finance [00:36:00] people to just give you that little bit more?

Janna Bastow: Yeah, that’s very true. All right, so sharing the results here and shows that There’s not many people of no budget at all and for those who do really sorry to hear that’s a tough place But we’ll talk about how to pitch for it soon a lot of people here most people can pitch for a budget if they have a strong reason and and then a few others can submit their tool requests during budget planning season.

It looks like no one has a predefined budget and can just spend it how they see fit. So not true autonomy over this stuff at all. Which is a shame, but because I know other teams have that but product, I think it’s sometimes fallen behind or has always started behind and is still behind some of the autonomy that other teams like sales and marketing often get.

Let’s talk about how to pitch for that budget, right? So we’re gonna talk about how to put a case together. A lot of you, as we saw in that thing, are in a position where we need to pitch. It’s always worth being proactive and trying to make a case for anything that’s going to help you deliver results for the business.

So here’s how you’re going to do that. So first, and most importantly, you need to [00:37:00] understand exactly who is making the spend decision here, right? Whose money is it? Be clear about who that person is, and then think hard about the drivers and motivations. What do they care about in their role?

You know why you want this tool and what benefit it’ll bring you, but what benefit will it bring them? Why should they care about this tool? For example, if you’re pitching to the CPO they’re going to care about the overall performance of the entire product function. So don’t present a case for a tool that will only alleviate one pain point that only you have.

Think about how the tool will drive efficiency across the whole department, how it’s going to help their goals. Is it going to standardize processes and drive consistency? It’ll make you try to show the CPO how it’s going to make their life easier. Consistent reporting across the product team, all data in one central place.

Something that you and your other product people can use rather than something that’s going to solve one tiny thing. Unless it’s a really key problem that needs to be solved. Think about the person you’re how the person you’re pitching to is measured in the role and try to appeal to that wherever you can so to put a case together, [00:38:00] identify the problem and explain the pain points and challenges that you’re facing without this tool, is it time wasted, reduced productivity?

communication gaps, literally leaving money on the table and explaining how the tool addresses and fixes these pain points and challenges. Just, you don’t need any, you don’t need to make a huge long business case. Just keep it succinct and get to the point. Sometimes just writing a one pager.

Can make a really big difference. But, outline what the benefit would be to the business of this problem being solved, not just the benefit to the team and your division and your work, but, is this something that you can quantify for the business? Can you calculate the cost savings or revenue generation or time savings or quality improvements velocity or output improvements, whatever it is you think it’s going to help with, can you put a number on that?

If this tool is going to save you or the team time, then how much time and, look at the salaries of the team members involved and, how much is that time worth to the business so they can quantify it and show your workings, right? They might not be exact, but at least it gives you a framework that you can begin the [00:39:00] conversation around.

If possible, share any case studies or testimonials from similar companies or teams who’ve seen benefits, if you can find a competitor using tools, you can pitch this as a way to ensure that you’re competing properly. They are moving faster with this. Can we move faster by doing the same thing?

And then lean on the the tool vendor for these, tell them the specific problem that you need solving and ask them for customer references or examples or, case studies that that you can lean on, that you can use in your building a case that, anybody has successfully done it before you, they should definitely have examples of that.

And you can also trial run the tool and share your results. Most tools, give you a chance to, to trial in some way or the other even if it’s just to share showcase what your data looks like in that tool, you just want to be able to help other people visualize and also approve validate on your side that this is going to work in reality and be clear what the implementation timelines are, both getting set up and the initial setup and then it.

Realizing the whole benefit, [00:40:00] right? This might be something that takes a few months to get bedded in, but after a year it’s going to be worth X, right? And you want to preempt questions around how much training does this involve? Who needs to be trained? How are we going to get that? How much support is needed?

Who’s going to provide that? Who’s going to be responsible for managing that rollout if it’s going to be something that needs that sort of Oversight and then get down to the costs, right? How much is this tool going to cost and compare that to the quantified benefit you’ve worked out? This is the bottom line.

Really? If you spend X on this tool, you’ll be powering through something that will eventually lead to better business performance and therefore more revenue or whatever it is that you’re making your case on. Don’t worry about it being airtight. You don’t have to have exact revenue return numbers because no one actually does.

Just focus on telling the story of the long term improvements that you’re going to be getting in performance or or time savings that are going to lead to more of what’s important to the business. Tom in the [00:41:00] chat is just adding to this and saying, we as PMs are feeling the pain, but the stakeholders with budget authority are not feeling the direct pain. So you’ve got to connect the pains to their goals to help sell the case, right? So it’s really important to demonstrate the value to the business.

Matthew made a point here, though. He said it’s not always easy to know their goals, right? It’s not always that transparent. When it comes to understanding other stakeholders around you, I think it’s really important to. How do you treat them like you do your customers? In that you do customer discovery.

You don’t always know what their pain points are and what their problems are and how you’re going to solve them, but you discover it by having conversations with them, right? Teasing it out of them. So if you do a similar discovery on the rest of your team, your execs, the budget holders, the people in dev, the people in marketing understand And.

What drives them? What problems do they have? What pain points do they have? Use the same stuff you’ve been deploying on customers for years. Deploy that on your internal stakeholders, and then you’ll be sure to be able to solve problems for them and make better [00:42:00] connections and get what you need out of them.

If it’s something like a budget. 

Megan Saker: Yeah, Matt’s absolutely right. Go and talk to them. I’ve been known to do it. Personal analysis. And in terms of politics and helping the rest of my team understand, like who in the business is holding the purse strings and making decisions and looks, this is what they care about.

This is what they’re trying to achieve. And look most of the time, particularly if you’re looking. The people holding purse strings, it’s revenue, right? It’s performance, it’s your core business metrics, right? Yeah. 

Janna Bastow: Yeah. 

Megan Saker: Yeah, exactly. To 

Janna Bastow: cut costs or to grow revenues. Obviously business, obvious business drivers but if you can tie the reasoning that you have behind a tool to that.

You’re able to say, actually, if we had this, it’s going to allow us to move faster, which will help us get to revenue faster, or it’s going to cut down on the cost, then this is how it’s going to save those costs. And this is how much it’s going to save. So really, we’d be silly not to spend the money on [00:43:00] this tool, right?

It’s not about making your life easier. It’s about making their end of day easier because they’re trying to get those cost savings or bumps in revenue or whatever it is they’re trying to do.

All so on because we’ve covered a lot today, right? And I would have liked to have gone deeper in some aspects. So if you want more info, I’ve actually put together a tool stack reading list that will be followed, included in the follow up email. So everybody’s registered.

You’re going to get a copy of this. But we’ve written a whole bunch or we’ve pulled together a whole bunch of different sources on this around, the best AI tools, the best roadmapping tools, the best OKR options, right? Things like that because there’s just too much to cover.

And, obviously there’s a thousand different tools we could talk about. So we’ve whittled them down into some articles here that we’ll send out to you. On that note, I’m very conscious of time, so I want to make sure that we have at least room for questions. Let’s jump over to that.

Yes, great. 

Megan Saker: Yeah, we’ve got a bunch of questions that have come in. Obviously, if you think of any while we’re asking [00:44:00] the questions, just whack them into the Q& A box and we’ll answer them. One which I found was interesting was how often Should we be reviewing and updating our tool stack?

So it feels like every week there’s a new tool that we must have. I suppose that’s particularly around AI, 

Janna Bastow: right? 

Megan Saker: And 

Janna Bastow: that’s only going to get faster, isn’t 

Megan Saker: it? Yeah. So Dominic is saying, I understand the value of being an early adopter. But it’s hard to keep up and like, how often should people be reviewing?

Janna Bastow: Yeah, 

Megan Saker: Absolutely. 

Janna Bastow: And actually, on the point of being an early adopter, I love being an early adopter to like test things, but to actually implement them into our stack. I’ve been burned too many times where I’ve tried the hottest new thing and then it shut down for whatever reason, right?

So I actually like to consider whether this is something that I’d be willing to spend quite a bit of time on. Switching over and be willing to let go of and to make sure that I don’t do that I try to go with and then there’s there’s a lot of other tools that are, have lots of other customer [00:45:00] references and yeah, I’ve been around in the market and been tried and tested.

These are the types of tools that also tend to have better fleshed out integration points. Sometimes the hottest new tool might sell some cool thing, but it’s often just a feature and not a fully fledged product. On that note, I will review and change the tool stack. We review our tool stack I guess you’d say regularly here.

It’s not like we have an annual review where we look at all our tools and decide if we’re going to make changes, but generally we start making changes as renewals come up, we look at it going, okay, this has been adding value for this year. If not, then, we’ll think of something else.

More often than not, because we have been spending time mapping out how things fit and trying to fit tools that. Fit together really well. We end up not making major decisions too often. It’s only something that represents a big enough impact that it’s worth both the implementation change and cost that comes with it, as well as solving the problem.

better than [00:46:00] anything else, right? That said with AI tools, this is coming in and displacing the way that we work in a lot of different ways, right? I didn’t expect to add an AI note taker to my tool stack. But once it was available, there’s no way I’m ever living without this, right?

I didn’t expect to use AI to manage my calendar. But now I see time is really valuable as a product person. Why wouldn’t I use something like this? Review them as and when is needed and when there’s opportunities to renewals or new areas to focus on.

But also don’t feel stressed about missing the new latest tool. There’s gonna be another one three months later and another one after that. Find the one that fits your tool stack. It’s a really good question though, Drew. 

Megan Saker: And I suppose it’s also, you should also be led by, have I got a problem that I need solving, right?

So when they come up, rather than just tools for tools sake, it’s like, what are my challenges? What’s, where am I getting stuck? And then you look for a solution. 

Janna Bastow: Kind of like validating features, right? You could [00:47:00] build this feature because you can, and because it’s there, and because one person asked for it, but actually you want to build something.

You want to get a new tool because it solves a really core problem and should represent part of your tool strategy, if that’s a thing we can call it. 

Megan Saker: Another question here. Matthew’s asked a question which is, it’s quite specific to PropPad but Matthew said it, PropPad seems like an interesting tool.

It is. Thanks for noticing. The Atlassian ecosystem has many integrations with various tools that we’ve mentioned. It has a marketplace. Like, how is ProdPad better than one of, than the tools in Atlassian that a lot of the organization uses? And I suppose that comes into your point, Janna, about is it worth it?

Is the value enough? Is it worth moving or making the change? 

Janna Bastow: Absolutely. And a really good question, Matthew. And, the thing is that the key part of Atlassian’s ecosystem, I think most people center around the JIRA tool, right? And JIRA is a fantastic tool [00:48:00] when it’s used for what it’s good at, which is development, task management.

And there are add ons and additional pieces that you can do to that. But a lot of them and this is my. Bias view, but you’ll hear this from people that we speak to our customers who are unbiased as well. We’ll point out that a lot of them feel like they are pure add ons, right? They are made for the developer ecosystem and not ready for the wider tool team.

And don’t look at that bigger strategy. Planning for the post delivery piece as well, right here is really good at saying, here’s things that we want to build. Here’s what we’re building. Here’s what has been built and then just moving right back into that same loop. Whereas ProdPad looks at the wider flow.

Here’s the problem we’re trying to solve. Here’s what we’re trying to be. Here’s our strategy. Here, our goals are okay. Ours. Here’s where everything the customers have asked for as well, right? All that context that goes into deciding what even might go to development. and then gives you the space to push it to development.

But then once something’s actually been done, giving you options to understand what did it [00:49:00] work? Let’s measure the success of this. Did it solve the problem for the customer? Has anybody remembered to get back to the customer? Has anybody told sales about this thing? So they’re all trained up, right?

Have we released this fully or is it just done as a check mark in JIRA. So JIRA works really closely with Atlassian, which means with JIRA and also as a connection with Confluence as well, which means that the two kind of sits together. So ProdPad has its marketplace, Atlassian has its marketplace.

But basically, you’re having one for your strategy side and one for the other, which because they’re connected. Means that you get to take advantage of both ecosystems, which I think is actually probably healthier overall in general is to have different areas solved differently.

Megan Saker: And also the Atlassian ecosystem does tend to be like more of a closed environment. And we’re, with PropPad, we firmly believe that one of the most important things is. Is getting collaboration right from around the organization, both to feed the [00:50:00] product strategy, but also to make your life easier communicating the product strategy.

If you want to engage with any of the work you’re doing in an Atlassian tool, then you need to, that person needs to have an Atlassian account, right? And have a seat. 

Janna Bastow: That’s actually really key is, ProductPad is designed for the wider team, right? It’s core user, of course, the product person, but the wider team all has access for absolutely free.

So that they can see what’s going on in the product space, they can add their thoughts, they can communicate, they can collaborate. We’ve got lots of ways of connecting with it, but what’s really key is that they can see like this window into Jira from ProdPad. So you no longer have everyone in your company having to fall into Jira and find where their idea disappeared to.

And so yeah, separates the two, but keeps them closely linked so that you got that tighter collaboration across the team. 

Megan Saker: And AI. And ProdPad’s CoPilot is fairly hard to beat. 

Janna Bastow: Yeah, absolutely. And I think we have time for one more question. I spotted one from Claudia who said, [00:51:00] Any tips on how to guide a semi large PM team in new tool adoption so it doesn’t overwhelm teams with the change?

Such a good question. What you want to do is, with any change management, create a sense of clarity. What is your vision with this thing? What are you actually trying to do with it? Make sure people know what that is. Create a sense of urgency so people understand what the timeline is and why you want to make this change now.

So it’s not just something that sat on forever. Show them. How it’s going to work, show them quick wins with it, show them the trial account that you filled out with details and make sure that they’re feeling the momentum. And then as people start switching over then start keeping that momentum up by showing people those wins that you gain over time with it.

And reporting back to them, making sure there’s clarity on the process and where you are with it and what they can do to contribute. So just some tips there. that that can help with that. Hopefully that helps, Claudia.

Megan Saker: Great. Wonderful. 

Oh, we 

are, we are out of [00:52:00] time. 

Janna Bastow: We’re 

at time 

now. Good time to wrap here, but also let you know that we’re going to be back for another one of these webinars. Megan, do you? We run these things twice a month, we usually run a how to write webinar as well as a guest webinar.

And we always post these up on ProdPad.com/webinars. 

Megan Saker: And we will, yeah, we’ll send an email following this with a recording of today’s webinar. And also a link to those resources and the product launch webinar we’ve got coming up as well as a couple of others. So look out. in your inbox for all of that.

Janna Bastow: Absolutely. All right. Thank you very much for taking part, everybody. Good to see everybody hanging out in the chat and saying hello and jumping in on the conversation. Thank you, Megan, for teeing us up for this. And until then see you next time. Bye for now. Great. Thanks, everyone.

Bye.