[On Demand] Product Management Webinar

[00:00:00] Megan Saker: Hi, welcome. Welcome to Prodpad webinar.

[00:00:04] So, let me quickly, before we get into it, just explain a little bit about Prodpad. So, some of you will be Prodpad customers but if you haven’t heard of Prodpad we are a product management software, a complete platform that Janna and her co-founder Simon built many years ago and we have developed it into an excellent product.

[00:00:28] So you run your roadmapping and your strategy planning, your idea management and your backlog refinement, and also your customer feedback management all within Prodpad. And you’ll, we’ll talk a little bit about Prodpad and the features that can help you as we, as we work through. So, without further ado, let me introduce you to Janna.

[00:00:49] So, Janna is our, as I mentioned, CEO and co-founder. She’s also co-founder of Mind the Product and was the inventor of the Now-Next-Later roadmap. So, who better to talk us through a best practice product management process and tips on how to optimize it and streamline the way that you work.

[00:01:10] Janna Bastow: Excellent.

[00:01:11] Hey, thank you so much for the warm intro and for getting us kicked off here. So, as Megan said, I’m going to be talking about product management process, and we’re going to be covering, we’re going to be mapping out a process from start to finish and background again we’re going to cover what each stage is and what I mean by each, we’re going to get into tips on optimization for driving maximum maximum efficiency across this.

[00:01:38] And then we’re going to dive deeper into a few of the different stages and give you an idea as to what you can do to improve your workflow and save yourself a bunch of time and just generally make yourself make your life easier. There’s going to be some further resources that I’ll share with you as well.

[00:01:51] And as Megan said, this webinar is being recorded. So feel free to grab screenshots as we go, but also don’t feel like you have to take a million notes because we’ve got it covered for you here. If that helps. So I want to jump straight into the pure guts of this, which is the product workflow.

[00:02:09] Now, keeping in mind that this is what we’ve tried to do with taking a very non linear process and lining it up in as linear a process as we can, but this is a little bit like taking a balled up. Ball of wool. It’s been tangled. And trying to find the end of it. Ultimately, we all know that the product management process doesn’t necessarily have a clear linear process that you can align out.

[00:02:35] There’s always a lot of collaboration and. Movement between stages, particularly as you learn from these different collaboration stages, you notice we’ve highlighted a few different stages within here, where you do specific user testing and gathering feedback. But those aren’t the only places where you do that.

[00:02:52] So this is. A best practice process or workflow for product management, but this isn’t the only good way to work. You might in your own team come across a different way of working and still have great results. But this is a process that we’ve had great results with that I’ve seen other teams have great results with.

[00:03:09] And it’s tried and tested in terms of the set of processes. So we can advocate for this cause we know that we, this works for us here, Prodpad and for a lot of other customers that we’ve worked with. So some of these stages might not make sense for your team but others might.

[00:03:23] And there might be some things in here that you can implement or some smaller tweaks you can do to move towards this or that can help make your life as a product manager easier. So before I go into detail on each stage of this workflow I want to, as I said, Acknowledge that this isn’t a linear flow at least not for most product people who are managing existing products, rather than starting from scratch.

[00:03:49] But I’d rather I wanted to have a simplified. View in order to present something digestible here, so we can start somewhere and work our way through. So what I’ve tried to represent here is the core foundational tasks, like setting vision and roadmap maintenance alongside the different stages that you’re going to be taking at each.

[00:04:10] taking the product through at each sort of stage, like defining the idea, running discovery, going through design and delivery. And things like feedback and gathering insights and collaborating. These are actually constant, although you do see a couple of these feedback loops within Prodpad sorry, within this, this product process.

[00:04:28] So let’s work through this. Stage by stage, and we’re going to start at what we’ve identified here is the beginning, but because of that feedback process isn’t always the 1st thing that you do. But let’s start with the top corner here. So, namely. Establishing and maintaining your strategy and product vision and setting up your product objectives and goals and building and managing your product roadmap.

[00:04:54] Now the frequency at which you spend time in these stages increases as you move along the slide. So, setting your overall product vision and outlining your fundamental strategic approach is probably something that you do once. When you’re, you do this in the big way: the beginning of the genesis of your product or the genesis of your product.

[00:05:18] A company but then something you should come back to semi-regularly, like annually, or when the market demands, it’s like, if there’s a major new competitor, that’s burst onto the scene or a major shift in the way that the market looks at your space. Now, if you don’t have an actual vision statement written out, and that’s kept close to where your product work is being done, then you should.

[00:05:45] I definitely recommend stopping here and taking a step to make sure that you’ve done this. If you need help to craft something meaningful and motivational, then we actually have an interactive template that you can use. So here’s the URL for that. You can go take a look. Outlines the key things that you should be asking in order to build out a vision template.

[00:06:06] But we also have an AI product coach built into Prodpad that you can use as well. What you can basically do is draft up a version of your vision statement. And again, we’ve got a template in that, in that URL there and you can plug it into Prodpad and then use the AI coach to give you an assessment of that vision.

[00:06:27] And it’ll give you really helpful critical suggested improvements that can help you improve that vision and make sure that it’s aligned with or, or the type of vision that’s going to help your team build towards the future. Now, while you’re checking this out, you can also be doing it within the strategy canvas within Prodpad.

[00:06:48] So this is another important point because this all ties together. You need to be explicit about your overall strategy and keep it close by at all times. So you don’t want to take your strategy. This is what a lot of teams do. They build out their strategy and they bury it in a slide deck somewhere.

[00:07:05] Or they save it to an obscure folder or, or linked to it from, an unloved area. On their Internet what you want to do is to be that close to where you are outlining things like your OKRs and your roadmap and where the actual work happens so that no one loses sight of that bigger picture.

[00:07:24] So you have things like your vision, your strategy statement and a description of what your product is all very close to where your objectives and your roadmapping and your work happens. So that’s a really key thing there. So the next stage in this process is to set your OKRs.

[00:07:45] Again, if you need more guidance on this, we, we can, we, we have some resources on this. So by OKRs, we mean your objectives and key results. Now they don’t have to be. Okay, ours in the traditional sense, we’re not dogmatic about this use of whatever goal setting framework. New favor, right? So if that’s objectives and key results, or if that’s some other flavor of KPIs or what, whatever sort of objectives and goals and metrics or whatever but what you’re trying to do is make sure that you have outlined what is important to the business.

[00:08:17] What do you want to measure to make sure that you’re making an impact? And how do you know that impact has been made as in what needles need to move and make sure very importantly, that everything is connected. Back to the strategy and the vision that you’ve outlined and as well, just as importantly to your roadmap initiatives, one of the problems that I see a lot of teams having is what I call OKR drift as in they’ll set up their OKRs in one place and by the time they go off and do product management work elsewhere, the roadmapping and their, their idea management elsewhere.

[00:08:53] And when it’s time to go back and do their OKRs. And update the tracking sheet that they set up. They realize that they’re okay. Ours haven’t kept up with them. They realize that they’re okay. Ours are out of date and it’s because they’re okay. Ours haven’t been connected to the work that they’ve been doing on a day to day basis.

[00:09:09] And so what’s really key is to link these things together, and that’s something that you can do in broad pad. But the really key thing is to make sure that you’re okay. Ours. Are linked directly to your roadmap. So that you know when you’re looking at your roadmap, you can group it by which objectives it Im, it impacts.

[00:09:26] And when you’re looking at your key results, you can say which initiatives on your roadmap are going to contribute to those key results. So the two should be intrinsically linked. That’s why I’ve put these three stages together and that’s one area that you can optimize and really help out with. I’m gonna come back to road mapping ’cause it’s a big, contentious area. There’s a lot to talk about there. But we can look at some of the common time sinks here and what you can do to streamline things and how to optimize how you work. As we move along this process I want to talk about idea management, which is obviously a biggie. It encompasses the larger job of ideation as well as the day to day backlog refinement that you do as a product management as a product manager. So you’re gathering triaging and coming up with product ideas.

[00:10:08] You’re pulling them all together. And I have a good list of optimization tips for this stage. So, I want to come back to some of this, but I want to touch on prioritization as well. So prioritization is this next stage where you start to put action behind your backlog. What.

[00:10:24] Should you work on and in what order based on you do this prioritization based on strategic alignment or business impact or customer impact or the effort it takes to build or the confidence you have in which you know whether it’s the right thing to build or not at this stage of prioritization, you don’t need to know if the idea is is, is exactly right.

[00:10:44] You just need to decide as to whether it’s worth exploring. So you’ll do more prioritization later in the process as well. Once something has been through further discovery, design, more user testing. Proper, more detailed specking and estimation but, at this stage, you’re focused on whether it has legs and, whether it’s appropriate in terms of higher level, strategic impact and effort and at the defining stage, this is where you start picking up each idea based on the rough priority order and start fleshing it out.

[00:11:19] And your job here is to start answering questions around what problem does it solve? What would be the value if you did solve it? What sort of Functional areas. Does it touch? Who does it solve those problems for? What does that look like? Identifying different user stories or jobs to be done that little tackle where in the customer journey it will help remove friction.

[00:11:41] So you might be identifying different areas that you can tie it together to solve problems for your customers or for your business. And that should be Gathered as part of your specs in the defining area, often quite as a high level exercise at 1st, until you start moving through into more discovery and design, which again, we’re going to see in just a 2nd as to what happens with this loop.

[00:12:07] So that initial high level. defining is a very high level where you might say, we’re just going to define what it’s, this type of problem to solve and why we might do it. And then you start going into discovery to discover whether you’re still on track with this, is this actually the right sort of problem to solve?

[00:12:24] Is there in fact the right market for this? Do our customers have this problem? If our customers have this problem, how are they solving it today? Let’s take a look at that and dive into that sort of thing. Lots of different ways that you can start diving into discovery to decide as to whether an idea deserves to move forward or not.

[00:12:43] And your job generally in discovery is not to prove that an idea deserves to exist, but often to prove that it doesn’t deserve to exist, right? To invalidate an idea so that you don’t end up with too many ideas that end up wasting time once it gets to the more expensive design and development stages.

[00:13:03] So, once things have moved through this high level discovery stage, you might move into a higher level design. So yeah, to a more defined design. And again, this would be high level at first maybe even just starting with very, very high level sketches, which you could run user testing on.

[00:13:22] And as you run that user testing on, it brings you back To that initial defining stage that allows you to further understand as to what the needs are, run further discovery on it and then do further design on it. So you get in this cycle here that you’ve run as many times as needed to make sure that you’ve got the right the, the right ideas validated and the right ones invalidated as well.

[00:13:50] So speaking of discovery, there’s a guide here on our blog, all about the ROI of product discovery. So check that one out if you want to dive in deeper on this. And once it’s designed, once you’ve got something that you’ve got enough detail to go into, you might start breaking it down. The nitty gritty of specking.

[00:14:09] And so I alluded to breaking things into more detailed specs. But this is where you might start breaking it down into detailed user stories detailed jobs to be done acceptance criteria. And what it exactly starts to look like in terms of the functional specs and what the technical specs look like, and this is where you’re going to have a lot of collaboration between your design team and your development team.

[00:14:34] And again, every team looks different. Ideally, you’re going to have people very Co located on this. So your developments are. the development team is working upstream and they’re already involved with the discovery of this and your design stream is working downstream and helping what’s going through development.

[00:14:50] But at the very least, your designers and your developers are meeting together at this requirements and spec stage and are helping to make sure that you’ve got this really clean handover so that you don’t end up with things that are designed, but aren’t able to be developed, or you don’t end up with things that are designed.

[00:15:07] But it will take forever to develop if you try to do so, or, it doesn’t make sense to develop.

[00:15:14] Speaking of development again, following this linear path that we know is not fully linear. This is where you start that handover to development. This is when you start getting into the stuff that we’re probably all really familiar with, the sprint planning, the testing, the releasing to beta, the stuff we’ve been doing.

[00:15:30] Like the back of our hand for years, right? There’s a, a, a lot of documented processes on how to do this whole development stage. We’re not going to go into that in detail because it’s been. Covered from every angle, and frankly, I don’t care as to whether you work in kanban or scrum ban or sprints or different types of development processes.

[00:15:53] The whole point here is that the stuff that goes into development is the right stuff because you spent that. All that time in all these stages upstream from here, checking and validating and invalidating the work to be done so that the things that go into development are in fact useful, validated work to be done.

[00:16:11] That’s the really core part of the product management process. You’re de risking the work that only the right stuff goes into development. So you’re not discovering it. When you released a beta, for example, that it wasn’t the right thing to do. Beta shouldn’t be surprised as to whether it was the right thing to do or not.

[00:16:27] It’s more about functionally, does this remove the friction that you hoped it would? Are there any interactions with the rest of the app that, that it can help smooth out? How does it work in production versus how it worked with the dummy data in staging? So, releasing something to beta is a really powerful step. If something can’t be thoroughly tested with that dummy data, it’s also a really powerful step to take if you find that it’s a higher risk piece of work to send out there and there’s lots of different types of beta and I’m using this as a catch all term.

[00:17:05] Sometimes you might want to feature flag something so that the feature is available for some people, but not others. It might be something that people can opt into like a classic beta. And that might be something that they can opt into themselves in the app, or it might be something that you selectively opt into.

[00:17:20] You allow them to, to opt into and you turn them on and off depending on the, the, the, the way that you’ve configure how your product works here at Prodpad, we actually have a bunch of different ways of doing so. We have feature flags and a beta mode and stuff that we put on as beta for everyone, but we just flag it.

[00:17:39] We just call it beta. Those are the ones that we’re more sure about and are more likely to move out of beta more quickly. I’m assuming that it works well with production data production data. Yeah, yeah, data. So now that you’ve got something out there released to beta obviously people see it, so this is a great time to gather feedback and that’s not to say that you haven’t been gathering feedback all the time, so you should be gathering feedback as much.

[00:18:09] Places as you can in this process. So, at the very beginning you were capturing your product vision and your, your and your roadmap. You can be gathering feedback on that stuff from the very beginning. Right? You should be. Get, putting your 1st ideas and your prioritization of the 1st blocks of that out to people.

[00:18:26] Sometimes the feedback is from internal stakeholders and just making sure that you’re on the right path with aligning your vision. There’s a reason why I like to think of your roadmap as a prototype, but for your strategy. So you’re able to think about your roadmap as a tool to assert to pull out.

[00:18:45] The feedback from people as to whether your strategy is on track or not. As you move further downstream, the feedback becomes much more specific about whether we’ve put this thing out here. Is it in the right place? Is it helping you do your job faster? Is it helping you solve this problem faster? But of course, the further down the stream you go, the more time and the more expensive it has been to build this thing.

[00:19:06] So if you’re doing the feedback further upstream in this process, the more chance that you have removed costs if you gather feedback that allows you to not do a piece of work that otherwise would have cost you a lot of money. So, this isn’t the first time you will have been gathering feedback, but this is a really key time, obviously, when something is in some sort of beta phase.

[00:19:28] And of course, if changes are needed, they almost always are. I can’t think of a single time where you’ve put something in beta and gone, yep, good enough. Everyone saw it and thought nothing of it. We’ve always had something go back to design. At which point you make a tweak or. You change it completely, whatever’s needed, and it goes back through the loop until you get to the point that you can launch it.

[00:19:49] And this is really key. You notice that launch is separate from beta launch. And that’s because a beta launch Is easy to get out there. Beta testing is easy to get out there. You can feature flag something and put it out there at the moment that your developers are able to say, yep, this is done.

[00:20:06] This is easy. And your customers are able to see it at the point that the development work is done. Whereas launching a marketing launch, putting it out there and telling the world about it is a risky activity. If it’s there. Depending on getting the development work out. So if you separate these two things, it gives you that freedom to say we’ve had this thing in beta for two weeks.

[00:20:28] So now we know that it’s working. We’ve done a couple of tweaks. It’s good to go. We’ve got pictures of it. We’ve done some videos of it working. We’ve got a testimonial. So now we can launch it knowing that it works. And it’s going to be out there. If you try to collapse these two. Which is what a lot of teams do.

[00:20:44] They try to line up their marketing launch with the development through to done part. You end up with sad marketing people because if development misses their launch and it’s not perfect the first time it goes out, then the marketing launch. So this is really key to stretch this piece out and create space for gathering feedback, making changes and giving the launch time to warm up and really get out there. And then very importantly more feedback and analyze that feedback, learn from it and then measure it. Right. So, ask people about whether it solved their problems and analyze their usage of it. Analyze the usage of that particular feature. That’s been out there for that particular product, but also analyze the impact that it’s had on other parts of the product as well.

[00:21:33] And you, you, you. Anything that you’ve put out there, you should start with the premise of, the target outcome is this. We think if we do this, it’s going to have this impact. And by doing so, we’ve now had this impact. And so you should be able to see the flip side of that in your Analytics and measurements in your measurements, you should be able to outline those target those actual outcomes. So that was a lot now, as I said, there is, and I can see there’s a lot of questions coming up as well. So I want to tackle those I know that there’s a a lot to digest and it has the potential to get very messy.

[00:22:14] And herein lies one of the common problems. A lot of product teams are trying to manage this whole process in a single place in one tool, be that Jira or Trello or Azure DevOps or whatever. Systems built for project management, ticket tools based on they’re they’re meant to manage. development work.

[00:22:36] Anybody in the chat in this position where they’ve just got Jira or they’ve just got Azure DevOps or they’ve just got Trello and they, they, they’re trying to manage that entire process in one space. Yeah, this is the standard. This is where everyone is, right? I see this all over the place.

[00:22:54] It’s because I think teams tended to start with that tool. But they haven’t really started thinking about that wider process, but besides it being difficult for us, I wanted to spare a thought for your developers as well. Because of all those different tools, they were great at the job they’re designed to do.

[00:23:14] They do project management tasks, right? They organize the execution and delivery, but where product teams go wrong is they use these same tools to collect and manage their. Their pre development backlog, as well as their post development measurement and analysis part. And let’s face it, a product backlog can be messy, all the stuff that you could do ends up in JIRA and it weighs it down.

[00:23:41] You could just do your strategy work. Bulks out your Azure DevOps. And then your team is in there unclear as to which things they should work on next. Your developers have a burndown chart and yet it’s got this list of like 500 things to go do. So they pick up one item and it’s not really clear that they should work on it because it’s an undefined product idea that may or may not even be a good idea.

[00:24:04] So they can’t work on it and burn it down. So they just put it back in and it’s hard to burn down a list of 500 tasks to do when only 20 of them scattered throughout that list are actually the next right thing to do. And so you can do your dev team a favor. You can give them a cleaner space to work.

[00:24:23] We’re going to rejig your processes and give them more autonomy so that they can have a space that only has approved, ready to go tickets. And they don’t have an untidy backlog of half formed ideas and not yet approved. Specs and so this is 1 of the main 1st tips, which is to separate your strategy from your execution.

[00:24:43] And what I mean by that is your strategy is your product management and discovery space, right? This is where things like yours include things like your product road map, but it’s also your, your product. backlog, right? That’s what we might build. And your execution is we know what we’re going to build now.

[00:25:03] Who’s going to build it and when’s it going to come out? How are we going to do that? That’s your release plan. And that’s a small sliver of the overall development flow. So, these two stages are completely different outputs, completely different questions that they answer. So, as I said, separate these two stages and you’ll end up with a cleaner, more organized, less chaotic. Backlog process and what you’re actually going to do is have a space that manages your backlog and your road map in 1 space and your development backlog, which is the ready to go approved tickets that you just need to put in.

[00:25:43] Manage releases around so planning sprints with your dev team and coordinating resources and capacity planning and setting up timelines and release dates if you need to get that granular. And that’s why you have different tools for different beasts. So Prodpad being a product backlog and road mapping tool and the likes of Jira and Azure DevOps and Trello and GitHub and tools like that for your development planning and workflow.

[00:26:09] So this is one really key thing that can make a difference. You’re going to be taking the weight off your development tool in order to create that space for your dev team, as well as make it more obvious for the rest of your team what’s going on in that process.

[00:26:28] So, for the flow that I outlined, it would look like this. You’re managing the product backlog in Prodpad. I’m getting to the stage where they’re validated and fully spec’d. Then you push the idea over to your development, sorry, to your delivery planning tool using you can, you have a two way sync.

[00:26:45] So it appears in your development tool, something like Kira. So it can be planned and put into sprints, and then it can be pulled back into Prodpad, syncs back to Prodpad, where you can continue to gather feedback and launch. I think I saw a question fly by, fly by there around where a beta stuff happens in this.

[00:27:05] And so basically what would happen is your development team would say, okay, it’s done, it’s ready to go. And just because the developers say something is done, Doesn’t mean it’s done, done. So in Prodpad, it would show, okay, developer say it’s done. Now it’ll notify your product team in, in Prodpad and they can say, great, let’s unsync it from JIRA and then bring it through to this beta stage and like, tell the people that it’s in beta and then check as to whether it’s actually working.

[00:27:31] Right. Let’s get that feedback and, and get it ready for launching and do the rest of the stages beyond that. So there’s like a handover stage that you can manage within that. I’m always happy to show people through how that works in the process. And Neil asked a question that just caught my eye.

[00:27:49] He said, does anybody seriously use Trello to manage a backlog? Yes. I see lots of people using it. I see Trello, Jira, Azure DevOps and lots of different tools. The really key thing is whatever tool works best for your process. But Prodpad connects to it. To it to, to take the weight off of it.

[00:28:05] So that it doesn’t become this overwhelming vertigo-inducing pile of stuff to do. So the separation of two tools gives you a more manageable backlog. It gives you a dedicated space for your prioritization and decision making and the rest of your stakeholders. a high level plan that makes it easier to understand.

[00:28:32] So that’s the one optimization task. It’s easier to get there than you think. We have an import. So if you have a big, messy Jira, for example we have a tool that can basically say Let’s take your JIRA, let’s bring it into Prodpad, use our AI tools to clean it up and tell you which of these things are connected or need to be put back into your, your backlog, which ones need to be closed off forever, whatever needs to happen, and then connect the two so that you’ve now got a strategy space and an execution space tied together.

[00:29:07] We can always help you with that process as well. And so following on quickly from that is the next tip which is to have an accessible and transparent single source of truth. This is really why Simon and I built Prodpad. The, the, the, People were often when I was a product manager, people often came to me wondering where their idea had ended up, they’d say Hey, I came up with this idea six weeks ago.

[00:29:34] Did you ever do anything with it? And it would be hard to identify where that thing had ended up. And so we built something to make it more transparent, to make it so that the rest of the team could see what was going on create the single source of truth as to which objectives were key, where any idea was, and whether it was tied to one of those objectives, whether it was on the roadmap, or whether it was an idea that needed to take a backseat for, for other things. So this is a really key thing that you can be doing is making it so that product management isn’t this place where ideas go to die but actually is a place that the rest of your team can actually engage. And they understand how they can input into product management.

[00:30:21] So I want to dive into it. I’m laughing at Steve’s point there. Product management is where ideas are going to die. I’ve heard this as customer discovery points that people have made to me and it made me die a little bit on the inside. So I’m now on a mission to save, to fix this. So I want to talk about, I did promise I was going to dive deeper into road mapping.

[00:30:38] I want to dive into some of the points to, to expand on this, this, this, this point let’s start with road mapping. So some of the common problems and hands up, if you have some of these problems where you end up having to rejig your whole timeline when things slip, or you have trouble with getting estimates on work that’s that’s far out, or even work that’s right in front of you or having to constantly update static roadmap documents or having to juggle multiple roadmap views and constantly creating new ones for different stakeholders. Spending more time making roadmap presentations than you are actually working on, the work that is, in the the roadmap presenting to your stakeholders and fielding questions like, where’s this thing on the roadmap?

[00:31:23] Why is it not here? Why is it over there? So to optimize this, this is where the Now-Next-Later. Roadmap came from, we realized that having a horizon concept allowed you to step away from a timeline. Because as soon as you have a timeline everyone assumes that or it assumes that everything underneath that timeline has a due date.

[00:31:44] And everyone is asking questions about. Due dates, and you have to put in all this time planning the estimate. So you can figure out where to put it. And instead it changes it from when is this thing going to be done? And more around what order are we prioritizing our resources to have the most impact, which is really the most important conversation to have.

[00:32:09] Steve Johnson made this point. He said the Now-Next-Later roadmap has become the number one format for road mapping. It certainly wasn’t always like that, but it has definitely taken its place now, which is fantastic to see. And, the other things that you can do here is take versions of your roadmap.

[00:32:26] Or even subsets of it and have them published and have them dynamic for your stakeholders so that you can make sure that people are seeing your roadmap without you having to constantly rejig them and show them to people and bring them along on that decision process. Right? So you can show how different prioritization factors weigh in on your roadmap.

[00:32:46] And one of the best ways to do that is to connect your roadmap. With your objectives so that people are saying if you’ve got this and this and this on your roadmap, but they’re tied to these objectives, people should see that those objectives are the most important things to your business. And they should see how that tells a story for the business.

[00:33:03] And hopefully they understand how those objectives are important for the business and therefore how the roadmap aligns to what the business needs. And those are all things that you can do with a Now-Next-Later roadmap or an outcome focused roadmap. Of course, like what Prodpad builds a little bit more on the Now-Next-Later, the core thing of it is that you’ve got these 3 time horizons where the things that are right in front of you are more granular.

[00:33:26] And as you get further away, they become more high-level and broader and scope and more flexible. And ultimately the things that are in the now are those well understood problems with defined solutions and more committed development resources. The next are problems generally at the design or discovery stage with assumptions to validate before committing to resources and later is more of our aspirations.

[00:33:51] These are things that are fuzzy and are taking form, but that’s all pretty flexible. Now, 1 of the really key things I want to myth bust because 1 of the biggest misconceptions of lean and agile roadmaps is that they, there’s that Now-Next-later roadmaps means that you can’t have dates anywhere.

[00:34:08] And that’s simply not the case. We don’t live in la la land. So the Now-Next-Later roadmap. Can allow you to have dates. Like this is in Prodpad. You can assign target dates but just to the roadmap items as opposed to at the top of the roadmap. Cause as soon as you have dates at the top of the roadmap, everything underneath.

[00:34:27] Automatically has a due date assigned to it just by where it sits on the roadmap. And you’re basically penalizing yourself by putting dates on everything on your roadmap, whereas in reality, if something has a date, then put it on the card, put it on the initiative, tell people what that date is, and then realize that, even though maybe 10 or 20 percent of the things in your roadmap have dates, the rest of it might be flexible.

[00:34:51] Or maybe you’re working in a highly regulated space and like half your stuff has due dates, but that still means that the other half of your stuff is flexible. So don’t penalize yourself by making everything inflexible by having due dates at the top and then therefore due dates scattered throughout your roadmap.

[00:35:07] If you do have to have dates, you can put them in, but don’t over use them just for the sake of it. Use them sparingly and when it’s important to communicate. Important dates, like strategically important and externally driven, like regulatory dates and things like that. So moving on where you can optimize.

[00:35:25] So you might have tricky stakeholders throwing ideas at you. You might have to explain to people why as a product manager, you have to say no a lot. You might have people. Submitting ideas instead of feedback or, might just be difficult to keep your backlog tidy and organized.

[00:35:41] So some tips for this make sure that you give your stakeholders a place to submit their ideas. Be transparent about the process and make it easy for them. We have a tool within Prodpad that allows you to show them the alignment of any idea. With the vision that you’ve put in Prodpad.

[00:36:02] So if somebody puts it in IDEA, and maybe it’s a terrible idea The computer will tell them that it’s not a good idea. So it’s not you saying no all the time. So we’ve built tools to help you identify which ideas are good ideas or not and help you give useful feedback to people on your team.

[00:36:19] And something that might help you is having a clear definition of what is feedback and what is an idea. There’s a lot of information on here. So hands up, just drop it, drop a note in the chat. I can see you’re all using it right now. If you’d like a PDF or takeaway version of this as to give advice as to what is an idea and what feedback is and how your team can best use this and we’ll make sure to get something to you.

[00:36:44] But basically we use this internally here at Prodpad and we’re happy to share it with you. But generally you want to make sure that you’re using feedback. For improvements on existing features or bugs and issues or user experience enhancements or performance or design stuff and have people submit new ideas if it’s a new problem space to explore or new markets or use cases or an innovative idea that hasn’t really been captured or complimentary products. So yeah, drop your your, your yeses or your whatever’s in here and we’ll get Megan to send it out to you as soon as we’ve got that wrapped up for you. Some other things that we can optimize this is in the feedback area, so, it can be difficult to get people to submit feedback in an organized way, particularly salespeople, but I’m not picking on them. It can take time to look through feedback and read it all. I know here at Prodpad, we get more feedback than we can possibly read.

[00:37:38] I love you guys. Product managers are great at giving feedback, but it can be a lot. It can be very verbose. So we need help with that. You’ve got it coming in from customer facing teams. You got it coming in from salespeople. You’ve got everything right. And then of course, closing that feedback loop, getting back to somebody, if you’ve shipped something or you’ve made a movement on something that they’ve asked about.

[00:38:00] So. Really key, don’t expect people to log into a different tool, right? Make it easy for them to add feedback from wherever they are, right? Prodpad got lots of integrations or ways of connecting to the tools that your customers and your team is already using, whether that’s Slack or whether you want to embed something right in your product, we can do that.

[00:38:18] Make sure that you’re building trust that the feedback is leading to something that’s actually being that that’s actually going to be used. So, show people like, Hey, you gave feedback, 6 months ago about this thing and here it is, we’ve turned it into something, it doesn’t guarantee that everything they’ve asked for will ever get made, but certainly give them that positive reinforcement loop.

[00:38:38] And You want to make sure that your customer-facing teams are able to view what their customers have been asking for and self-serve updates on progress that their customers have asked for the spaces within Prodpad that you can do that. You can say, Oh , here’s Acme. And here’s Joe at Acme, who’s asked for these 10 things.

[00:38:58] And here’s where those things sit in the process. These ones are on the roadmap and these ones aren’t. And this one we did and it worked. This one we didn’t do. And this one we did and it didn’t work. So we’ve got all that information that you can, you can use and self serve as a customer facing person.

[00:39:11] And the real key is using AI to surface. Themes or to summarize feedback, if you’ve got a big pile of insight want to make sure that you can dig through it really quickly. And then, with closing the loop, make sure that you’ve got a list of everyone’s Email.

[00:39:29] This is really easy in Prodpad where you can just select everyone and email them. But just make sure that you are actually closing that loop. You are finding the list of people who’ve asked for something and closing that loop so that you hear from them again, because I guarantee you, if somebody gives you feedback and then they never hear from you, they’re not going to give you feedback the next time they’ve got something interesting to say.

[00:39:52] And then closing in on the analytics, the real reality is that measuring and following up on your actual outcomes just doesn’t get done when things get busy, it’s the most forgotten piece of the job. People like building, they don’t like measuring. And oftentimes people aren’t sure about how to measure the results.

[00:40:10] So, hack for you. Literally just add a space within your workflow that says measuring success. It’s a default workflow within Prodpad. We’ve forced it on everybody. It’s just there. But basically by doing so, it means that you actually spend time thinking about whether we have measured that this is successful or not?

[00:40:28] And if it is, the Market is a success. And if it isn’t, then market as a failure, whatever it is. Your target outcomes before you before any work begins, one of our best experiments, this happened some time ago as we created a space within Prodpad for every idea and every initiative and every Key result is to track what the target outcome was and then another actual, another space that captured the actual outcome.

[00:40:52] And just reminding people, giving people that space to, to fill that in makes a huge difference. And then again making sure that you’re building in space to do this, but having a completed section of your roadmap. So your roadmap shouldn’t just be a forward looking thing, but actually something that looks retroactively at what has been completed.

[00:41:16] So, I want to yeah, these are the tips to optimize your process. Now some really key things that you can start doing is to start measuring the improvements. This is another tip that you can use. Efficiency reporting tools to start checking whether ideas are working their way through different workflow stages at a particular velocity and see if you’re actually driving improvements.

[00:41:42] This is actually a brand new view in Prodpad where you can actually see how many days. Ideas are staying in particular stages. This is going live in a matter of days now. So we’d love your feedback on this. But this is based on feedback that we’ve heard. So this is the feedback cycle at work. We’ve told you about a bunch of different downloads and resources today. So, if you want more of these things, head to Prodpad. com slash downloads. It’s as pretty as this Page says here and I did actually mention a couple of key ones. I want to flag it up here. One is I’ve done a video about how to separate strategy from execution.

[00:42:20] So check that out. If that’s one of the keys. tips that resonated with you. And if people are still looking to move from your timeline to your Now-Next-Later roadmap, we have a guide on how to do so. So grab that here. That’s in the download section. You can scan that URL. Or that, that QR code and finally, we have a presentation deck that we’ve made to convince your stakeholders that Now-Next-Later works best.

[00:42:47] If you’re still trying to get people on board. So grab that deck, it’s completely editable and has speaker notes to help you make the points and make sure that that lands. So on that note, I know that there’s been a lot of points driving a lot of stuff for flying by in the chat that I’ve been seeing in my peripheral vision but if you’ve got questions, drop them into the Q&A, or I’m going to lean on Megan to pick things out of the chat if she can.

[00:43:12] But we do have time for a few questions and I want to make sure that I tackle as much as we can today.

[00:43:18] Megan Saker: Yeah, I’ve been, it’s been absolutely wonderful watching the chat. There’s so much chat going on. I tell you one thing I am seeing a lot of, a lot of chat about beta when we were talking about the beta stage, there was loads of chat.

[00:43:30] So that makes me think, that’s enough webinar, right? Let’s do some content on the nature of beta. Do we need to talk more

[00:43:37] Janna Bastow: about what happens at beta?

[00:43:41] Megan Saker: Yeah not now,

[00:43:43] Janna Bastow: not now. If we got specific questions about it, throw them in there. I’m always happy to hear about that. I never know what’s going on with the chat.

[00:43:50] Is it because I’ve said something wrong and flammatory? Like, that’s not how it works here. Or is it like, yay, this is working? I’m not sure. I can only see it in my peripheral, but let me know what you guys think. And I would love to hear your thoughts and make sure that we’ve got the right things being covered.

[00:44:06] Yeah. Any questions or areas that people want me to dive into deeper? Or was this a crystal clear tour and we’re all going to go make sure that our workflows match up to this exactly tomorrow.

[00:44:18] Megan Saker: And there are lots of questions. Let me have a look through this chat and pull out some questions.

[00:44:23] But also in the meantime, do, do, if, if any of you have any questions, want to make sure that yours gets seen, do pop it in the Q& A there. Let me, let me have a look now. We did have a question about a bit of debate about OKRs and the extent to which OKRs are still being used and what the failures are with OKRs.

[00:44:43] There was talk about the problem that often comes down to, when you have to cascade them down.

[00:44:50] Janna Bastow: Right. Okay. So I love OKRs in some ways, but I can also see why they get a lot of hate because first of all, they can be really time consuming and they often, if they’re not done right they end up, they end up getting misused. They end up just becoming a big waste of time for the business. Right. At their heart, what they’re meant to do is the magic of them is that top management sets what the North star is for the business. Right. And from there, the teams are able to figure out.

[00:45:21] How they’re going to contribute to that. So, if you’ve got something like we want to turn our customers into lifelong fans, that’s our North star, right. And that’s a big chunky thing. And to turn a customer into a lifelong fan, we’ve got a specific measure that we’ve tied to that around our net revenue retention but if you want to rally your team around that, there’s a bunch of things you can do with that, right?

[00:45:43] First of all, we want to make sure that we’re getting the right types of people in some marketing has a say in that, right? If marketing was just bringing in terrible leads, then none of them are going to become long term fans. Sales has something to say with that as, with, with that as well, right?

[00:45:56] Design and product obviously have to have a big say in how they’re going to do that. But does development as well, creating a stable product that keeps people around and of course, success and other roles have a big say in that. Now, each of these teams are going to Talk about are going to put forward parts of the goal that contribute to this, but no one team is responsible solely for it.

[00:46:19] And each of those different aspects I talk about will be broken down into more detail in each of those divisions or each of those teams. And that’s how it cascades down, but at every level, everything that’s being done by, by, by members of the team should be able to stack back up. So you’re saying if I’m working on this thing.

[00:46:37] Then why am I doing this thing? I’m doing it in order to solve this problem on the roadmap. And why are we having this problem? It’s well, in order to hit this objective. What’s this objective? It’s a sub piece of this objective, which is a sub piece of this part that is going to help us get lifelong fans.

[00:46:50] And this is how. And. If you’re saying we’re trying to get lifelong fans, how are we going to do that? You’ve got this sort of spread of different things and you should be able to play it down and up from any point in time, anything that anybody’s working on, and it should be justified by where it sits and how it’s connected up and down.

[00:47:07] There should be no one who’s working on something in the team and you go, why are you working on that? And they go, I don’t know, because I wanted to, like, if they can’t connect it to why it’s going to help you get that North Star for the business, then it’s probably not the right thing. And so there should be some connection between it.

[00:47:24] The problem where it comes in is when you hang up with Lagging metrics. You’re, you’re measuring the wrong things. And if anybody wants to, I can send out an article on leading versus lagging metrics and how to measure those. Prodpad has tools in there to help you identify and write better leading metrics for your key results.

[00:47:46] We use AI to help you with this. So that’s one of our wins that we did this year. I’m really proud of that one. And our product people are using it. Absolutely love this one. Cause writing. KR’s key results are not fun. So we’ve helped you with that. Some of the other traps are if there’s too many of them, your team, and you’ve ended up with like, 10 objectives and 10 sub objectives, and then you’ve got one person over here as individual objectives.

[00:48:09] I don’t believe in individual objectives. And I don’t believe in having more than like, Two to five, like five max, maybe like three max, right? Try to keep it as simple as possible. And that way you can cascade down more without having it go way too wide. Keeping it simpler is more important than anything else.

[00:48:28] Yeah. Yeah. I could talk about OKRs a lot. There’s maybe a whole lot. Yeah. Yeah. And we have got,

[00:48:35] Megan Saker: Yeah, we’ve got a lot of content on OKRs that we linked to on the slide. So there’s plenty more where this came from. Michelle, just very quickly Michelle has asked a question here. How would you suggest going about optimizing product processes for non development products where there isn’t a clear development team?

[00:48:53] Oh, cool. That’s a really interesting one.

[00:48:54] Janna Bastow: Yeah, so the beauty about this process is that most of it isn’t actually about the development piece, right? So the development, if you actually zoom out, is actually just this one little slice where you’re like, things to develop, things to develop, things that are being developed, and things that you finish developing.

[00:49:09] Yes, there’s more complication there. I know your development team has like 10 different stages that they all call in dev, whatever. They can make that as complex or as simple as possible as they like. But the real product is about the stuff that happens before that and how you’re validating, invalidating, risking the work to be done and then the stuff that happens after that.

[00:49:28] And so, this is where your magic comes in when you put on your product. Product ops hat and say, here’s what we need to do beforehand. And here’s what we need to do afterwards. And once it actually moves to development, whether that is a single developer who’s hacking away on code or whether it’s being sent to a manufacturing house across the world like an engineering job that needs to be done, or whether it’s not actually a, a dev task to be done at all.

[00:49:54] It’s actually something that’s being done by your legal team. Those are all valid implementation things that need to be done, but you need to validate it before you actually get to that stage. And that’s where the product management  process and product thinking is really key. It’s a good question.

[00:50:11] Megan Saker: We are over time now. I don’t know. What do you think, Janna? One more question? I

[00:50:15] Janna Bastow: didn’t see any more in there. So unless you’ve spotted it. No,

[00:50:19] Megan Saker: no. There’s some questions in the chat.

[00:50:22] Janna Bastow: All right. Take one more and then we’ll let people, we’ll let people go. There we go.

[00:50:26] Megan Saker: Yeah, sure. Okay. So how do you promote adoption of a product like Prodpad in an organization which had been working on Google Docs and Sheets?

[00:50:37] Janna Bastow: So, with a product change like that it’s always important to understand, where are they coming from and what pain points are they having, right? Did any of these pain points today resonate with your team? You can’t just foist a tool on them and say, yeah, change for the sake of it.

[00:50:53] Even I won’t tell you that, but if any of these pain points resonated with you. There’s probably a need for that. And if you have any kind of mature product processes or maturing product processes, you probably have pain points like, people are wondering where their ideas are because they don’t want to look through a giant list on Google Docs or, they don’t want to look through whatever sort of CRM system has been set up and try to find, Whether there’s been feedback or not.

[00:51:18] So you’ll probably find that there are pain points. It’s just that people don’t always know how to articulate them. So sometimes it might be best to set something up and show them a way and say, here’s something I’ve found. This is what it looks like. This is why we have the sandbox environment. So you can show them around and show them what they might be missing.

[00:51:35] And, start talking to them about how they might articulate it. And then as you start getting people talking about where they might see it fits, start bringing this wider circle around you of people who are on board with it. And you’ll find that the, the the, the, the buy in for it grows

[00:51:48] Megan Saker: and grows.

[00:51:50] And I think so much of it comes down to convincing the execs in the business that it’s worth it. worth using is, is the fact that you can, you can increase velocity through all the time saving that a tool like this would do. Fundamental time savings from having dynamic documents and processes rather than PM spending their time updating static documents on and and versioning headaches and everything like that.

[00:52:21] So you can get a return on investment through delivering. More to your product.

[00:52:28] Janna Bastow: Yeah, absolutely. And a couple last points. Judy has just asked for an article, a blog article on convincing people to switch. Yes, we can get something out there for you. We’ll send it around. And Steven’s final question.

[00:52:40] He said with startup. Startups bootstrapping will be something we can use based on cost. Yes, honestly, we’re a bootstrap startup as well. We know what it’s like to be just kicking off. We’ve been there. Our pricing is based on the value that you get out of it. So it’s based on per user pricing and it’s actually split up per module as well.

[00:52:59] So if you’re just using it. So if you’re just using it for the roadmapping part and they capture your vision and stuff like that, you can just pay for that part of Prodpad. If you’re just using it for gathering feedback, you can just pay for that. You can just use it for, taking the weight off your JIRA and just use an idea part and then you can expand later and add on different pieces.

[00:53:17] So, it’s up to you. You can pick and choose which parts you use, but we’ve made our pricing super, super friendly for startups. The other key thing is we only charge for the people who are like the product managers. The rest of your team is absolutely free.

[00:53:32] All

[00:53:33] Megan Saker: right. Thank you so much, Janna. Thank you for taking us all through that today.

[00:53:36] Janna Bastow: And huge thanks to everybody here. I’ve loved the chat. Sorry I didn’t get a chance to see and read everything. But it was great to see everybody getting involved. Love chatting with you all again. See you next time. Thanks. Bye. Bye for now.