Product Management Webinar: Calculating ROI

Megan Saker: [00:00:00] Welcome to ProdPad webinar, How to Calculate the ROI of Product Management. Janna’s going to be taking you through practical steps on how to prove . your value as a product manager, as a product person. So just before we kick off, a bit of housekeeping. Like I say, we’ve got the chat facility.

We’ve also got down to the bottom there a Q&A. So we’re going to make sure there is time at the end to ask any questions. So at any point during the webinar, If you think of a question, please drop it into that Q& A and then we’ll come to it at the end, maybe even mid-flow, but certainly we’ll make sure we cover them at the end.

So use that Q& A box there. And yeah, we’re here for an hour. And yeah, it should be good. Right. What I want to do just before I introduce Janna is to give you a quick overview of ProdPad. For any of you who don’t use ProdPad right now, you should. [00:01:00] Oh I’m Megan, by the way.

I’m marketing. That’s, that was me just marketing. I didn’t realize I didn’t introduce myself. But yeah, so ProdPad, we are a complete product management platform. So your idea and backlog management, your feedback, gathering and analysis, and your roadmap. We have the most advanced AI tools and capabilities of any other platform.

Product management tool and our focus is really on doing as much as we can to help you automate the grunt work to help you free up time to do the important discovery work. And also to make it easy to tell the story of what’s happening in product. So communicating to your stakeholders, ensuring that they can easily see what you’re doing in product and why you’re doing it importantly.

All of which will help you spend less time explaining, less time presenting, and more time doing. [00:02:00] where the value is which is the discovery work, it’s your prioritization, it’s your strategic decision making. And that is what Janna is going to be talking to you about today. Those, the high value activities and how to actually prove The value, the return on investment, how to put some numbers behind it.

Let me introduce Janna. I’m sure most of Janna. She is Prodpad’s CEO and co founder. Also co founder of Mind the Product. And the inventor of the Now-Next-Later roadmap. Janna and her co founder Simon. Created Prodpad back in the day because they were product managers struggling with all the problems that product managers struggle with and created Prodpad as a tool to solve those.

So Janna is well aware of where the value lies in product management and has a wealth of experience. Proving that out. So there we go. Janna, over to you. Awesome. 

Janna Bastow: Thank you so much for the warm [00:03:00] intro and for setting us up. And welcome everybody. Good to have you all here. I’m seeing all your messages fly by and seeing where you’re all from.

That’s great. We’ve got a big group here. Let’s get started with why we’re all here. This isn’t a particularly nice slide to start with, but let’s get it out of the way. We all know the reality of what’s happening in the industry right now. It’s tough out there. It’s been tough out there for the last few years.

Chances are you’re feeling some degree of pressure to prove your value and stats like these make it easy to see why, as tech businesses face hard times, every dollar spent needs to deliver returns. If the company’s going to survive as business leaders are scrutinizing their cost base, it’s more important than ever that you can demonstrate the return that you deliver to your employers.

And if they’re investing in you, what kind of return can they expect? And I can see somebody’s just posted that people are in that group. Honestly, I, so first of all really sorry to hear that. Second of all, I’m seeing green shoots out there. If you are out there looking for roles post your LinkedIn post if you’re [00:04:00] hiring, get networking in this group.

There are really good things on the horizon. And you know what, we’re having this conversation here today. So you can make the case to the people that you’re going to be going into these new companies. You’re going to be talking about why they need to be hiring a product manager like you.

Now, This is exactly why we invited the product guru, Matt Lemay. He came to our Fireside webinar series last month, and we wanted to discuss why it’s so important. We’re able to prove the value that you deliver to the company that you work for as a product manager. You have to have a strong position on this stuff.https://www.prodpad.com/webinars/how-to-show-the-roi-of-your-product-work-with-matt-lemay/

So we talked about how product management had grown up and the mindset shift that was necessary to operate at the more strategic level. So what we’re going to be covering today is some really practical steps to actually show, calculate the ROI of your role, right? Let’s start digging into some numbers and showing these execs what they’re missing.

Let’s craft your argument around your value and pull together some actual numbers. To get support. So if you didn’t watch [00:05:00] that webinar with Matt, I strongly recommend it. It was one of my favorite ones that we did. You can use this QR code here to watch the recording or it’s on our site. We post all of them on prodpad.com/webinars. So let’s jump into what we’re going to be covering. It’s we’re going to be articulating the value that you deliver as a product manager. And I’m going to be giving you the structure for a presentation that you can be taken to your leadership team. And then we’re going to be jumping into ROI calculations that you can run to help put hard numbers against your value claims.

Sounds good? All right. So what exactly is it that you do as a product manager that delivers value to the organization? I’m going to very quickly blast through how you can talk about these seven areas of your role and in a way that will resonate with your leadership team. I’m going to have a lot on these slides.

You are going to have a recording of these slides, and you’re going to have a copy of these. You can take these, this [00:06:00] recording and you can present this to your leadership team. They’re all featured in a guide that we’ve written, which we’re going to send to you. Right. So don’t worry about trying to take notes on all of this.

But let’s start with the work that you do on product discovery, right? Cause you can’t have product management without product discovery. You need to get across the fact that product discovery is ultimately a risk reduction strategy, right? You’re focusing on being proactive.

You’re mitigating against building the wrong thing and wasting costs and wasting time and resources on outputs that don’t drive a pretty good mission when business critical outcomes, it’s the critical due diligence that provides assurances and confidence that what you invest in as a business is valid and has the potential to be successful.

You’re doing the work or the work that you’re doing in product discovery de risks the expensive investments made into product development. So it’s really important to communicate this stuff and use the language. Like de [00:07:00] risking and the business outcomes to communicate this to your execs.

Now, next up, let’s talk about the prioritization and how that delivers value to the business. You need to make the point that your prioritization efforts have a direct influence over when the business realizes results or put another way, the scale of the realized results within any given period, because you are prioritizing based on impact.

Only you have the breadth of insight, understanding, and impartiality necessary to prioritize that will deliver the greatest return. You’re in a really unique role when you are a product manager in the center of the business, the tech, and the user facing part of the business. And we also want to talk about your role as the voice of the strategy.

Over on the product side of life, you need to position yourself to the leadership team as the person that [00:08:00] converts the strategic planning that takes place at their level of the organization to actual realized results. You are the connection between the product and development team and the strategic priorities of the business.

You’re the connective tissue. Without this, they risk having development teams build what they want to build, not what will answer the strategic objectives of the company. We see this all the time without product managers. I’m sure some of you have come into the business that have been running this way.

You’re their representative at the coalface, their translator, ensuring everyone is speaking the same language. Product management ensures that the product development work results in the highest strategic yield possible. And we’re going to talk about this strategic yield concept a bit later. And PMs operationalize the strategic objectives and deliver against them, meaning that the expensive exec level corporate planning work will actually have a return.

And that’s really key too. [00:09:00] And product managers are a mitigation measure against strategic failure.

So simply put, product managers keep things moving forward, right? They keep things moving ahead on both the discovery and the delivery side. So here’s how you want to be talking about this. So product managers act as the connections between each function along the workflow, passing the baton from stage to stage and from team to team, you remove blockers, you answer questions, you jump into QA work.

If there’s a backlog in that queue you get done what needs to be done. You streamline the processes, which include, which increase velocity, which in turn increases the output, the value delivered to your customers in any given period, a greater output of valuable features. Can lead to increased revenue, a growth in customer lifetime value, or a reduction in churn, or whatever it is that’s important to your business.

These are all important financial metrics, but it’s driven by the work that you’re doing, [00:10:00] removing those blockers and answering questions and jumping in where you’re needed. So we’re going to talk about how you can measure that. And most of what we’re already talking about here, all the work you do also helps businesses to mitigate against overrun.

Now, overrun occurs when a project or initiative exceeds the time, and therefore budget, because time is money, that it was actually intended to take. And this happens all the time. Overrun on revenue generating projects. Products add costs, which in turn, squeeze profit margins and delay revenue recognition.

So you reduce overrun through things like research and validation during discovery. You’re ensuring that the specs are actually feasible, which reduces your scope creep later on. And you are making fast and effective decisions during development. You’re deciding which trade offs can be made to prevent delivery time from increasing.[00:11:00] 

You’re also measuring outcomes and the results of all that product development work. Here is where you need to sell yourself as the data expert. Measuring the outcome of everything that ships. Without this, A business risks leaving objectives and goals unmet and bloating the product with features that just don’t move the needle.

Your measurements inform future iterations and product decisions and maximize the efficiency of all the future. Product development work. Features become easier to use and more useful to customers. As a feature success grows, the customer value perception increases, and the impact on financial metrics can be profound.

More sales, greater retention, increased LTV, and all those good things that you’re trying to measure.

And finally, the work you do to manage, [00:12:00] analyze, use customer feedback. How is this valuable to the organization’s bottom line? So to show this, I recommend you take your audience on a journey, tell them a story, ask them to think about a world where no one advocates or even understands the customer on the team, actually building your product.

It’s hard to imagine the risks of that. And, features not answering. Customer problems, functionality not in line with user behavior, highly anticipated features being deprioritized in favor of less valuable work, customers not being listened to, frustrations across the customer base, churn, lost sales, bad reviews Business failure, right?

And I say this like this is a story. It’s a fable. It’s a nightmare, but this is actually the reality for some teams. And this is why they turn to product management in the first place. But the point is that you have to make a that you’re here to have a thorough understanding of your [00:13:00] customers, their problems, their pain points, their needs and expertise expectations.

You’re here to run. The user research to speak to customers and to look at trends in the market. You gather and centralize that customer feedback. You, the feedback that they submit themselves or via, whatever sort of customer facing team members. You’re basically that single funnel point for all this business critical qualitative data and feedback can only live up to its business critical potential if it’s actually.

Analyzed and used to inform product decisions and without you finding the themes and insights, you can’t maximize the value that you’re offering to customers. And therefore the potential revenue and other financial outcomes for your product. Without you, your company is likely to fall back into that nightmare that they probably got themselves out of some time ago.

So without. That product management work, there’s a lot of valuable work right there and [00:14:00] I’ve whizzed through this. There’s a lot more detail that we can go into. There’s a guide, which we’re going to send you. It’s going to come out in the coming days. So keep an eye on your inboxes on this, but you’re going to find a whole bunch of phrases and positioning that are going to be really useful in helping to tell the story of your value, because how you frame it is going to depend on different stakeholders and different contexts for each of your situations.

Whether you are in a position where you think you’re up against layoffs, or whether you are trying to join a company that you think needs to have a case made, or whether you’re in a strong company and you just want to strengthen it. This is the near position, this stuff is going to help give you the context for the ROI calculations that we’re going to be talking about now.

Let’s look at how you can add some numbers to support this narrative. Are we ready for that?

Oh, and Megan will want me to switch to this one. So the guide is coming soon. I’ll take my sip now. [00:15:00] 

Megan Saker: There it is, everyone. There’s a picture. Here’s the picture of the guide. Keep an eye out for 

Janna Bastow: it. All right. So let’s talk about these ROI calculations. Let’s crunch some numbers. All right. Okay. These are the five calculations I’m going to take you through.

Now, some will work better for you than others. I don’t expect these to all work for everybody. It depends entirely on your own circumstances. But what I want to do here is give you a bunch of options from which you can pick. Right. This is how we do product management and choose our frameworks. So pick and choose which ones you like best.

The fact is it’s notoriously difficult. To quantify the value of product management, [00:16:00] but if you don’t make any effort to prove any sort of ROI, people will assume that there isn’t any right. A lot of people look at product management and just wonder what it is we all do. We discussed this with Matt LeMay on last month’s webinar and Matt pointed out that there are too many people who get hung up on the perfect way.

to estimate ROI. But the most important thing is to do something to estimate ROI. He said, if we could perfectly estimate ROI, every business would be infinitely successful. It’s about estimating the impact that you have. So there’s always unknowns in the work we do as product managers, and that stops a lot of people from making an estimate and declaring the value that they drive.

But some analysis is better than none. A flawed ROI calculation is better than no calculation at all. And if you’re not putting forward a suggestion for the return you’re delivering, people might assume you’re delivering no return, right? It starts the conversation around it. So we’re going to go through some calculations.

We’ll show you some examples, give you some [00:17:00] inspiration and start a discussion on it as well. We want to make room for showing you around some of this and opening up questions on it. And so with that, let me show you some ways that you can. Estimate your impact. All right. So metric one is this strategic yield.

The work you do increases the strategic yield of your business, which delivers the increased return exactly in the areas that are most strategically important. Right. So let me explain this strategic yield measures, the amount of output that aligns with and contributes to the strategic objectives of the organization.

So to prove you deliver a high strategic yield, you need to quantify the number of strategically significant initiatives you complete in any given period. So here’s some steps get a strategic Plan of the overall organization, if you’re to craft an argument that says you’re delivering value for the org, you need to be able to, you need to be sure that you know what the organization values.[00:18:00] 

So this is step 1, right? What is the strategy for the org? Are you trying to lift up revenue? Or are you being asked to increase market share or decrease churn or whatever it is now to outline the objectives. Between what you’ve prioritized and worked on and those overall strategic objectives, and then select a time period to report on, right?

Is it the last fiscal year? Is it the last quarter? Is it the last calendar year? What is it? Doesn’t really matter, right? It’s just whatever you need to be talking about and then find whatever roadmap initiatives align to those Corporate strategic objectives. So look one place you can do this is looking at your completed roadmap, your historical roadmap and pull them out.

So I want to show you how to do this in ProdPad because we actually have a completed roadmap view that gives you this exact view. Let me switch screens. and show you around. All right. Okay. So if I go to a roadmap in here, [00:19:00] I’ve got my roadmap in here. I can see that I’ve got my initiatives here and the objectives.

So I can see that for this project, It seems like it’s important to grow our user base and then later it’s getting increased engagement. And then later on, it seems to be things around market share and onboarding and usability. And I can change the order of these. If those strategic initiatives change I can have conversations around this by like grouping things by objective.

So I can see that, growing the user base. Seems to be most important. I can see market share has a good chunk of the roadmap as well. So I can group things up that way, but I can also see how things have been completed. So this is my future roadmap. What’s coming up now, next and later, but I can see what’s happening in the past as well.

So I can see what’s been happening in the last three months. three to six months before that, and more than six months ago as well. So if, let’s say, increasing engagement was the most important thing for the last year, I can see how many things were lined up to increase [00:20:00] engagement over that period. And so I can go back in time and go, okay, in the last year we have, there we go four major things that have been completed that solved that.

And I can now start using these numbers to identify a strategic yield.

Let me flip screens and get back to my

slides. There we are. Cool.

Ignore that 

Megan Saker: slide. 

Janna Bastow: Megan, for the heads up. We don’t have a screenshot of that. We were going to, but we’ll get back to you on that. There might be some more coming in following up on the guide later. So let’s show this as an example. So let’s say there are five core strategic objectives at the corporate level.

You’ve got five product objectives and four of those are aligned well with those top level objectives. So last fiscal year, you completed 27 roadmap initiatives, 22 of which were linked [00:21:00] to the four objectives that align with the overall strategy. So this is the calculation that you need. Number of roadmap initiatives completed in the period are linked to the main strategy, that’s 22.

Divide by the total number of initiatives within that period, that’s 27. Times 100, that gives you your strategic yield, so your team had an 81 percent strategic yield. That’s pretty compelling. All right. So that’s how you can calculate your strategic yield. Again, you’re going to get this in the followup guide.

We’d love to hear how everyone here has fared with their strategic yield and how this works for you. All right. So onto the next one. We’re. This is the ROI of cost savings. So here we’re putting an ROI against the risk prevention work that you do. This is the discovery work. That means you don’t waste resources on products or features that will fail.

So ROI is calculated by taking the cost of investment away from the [00:22:00] benefit and then dividing that number by the cost and multiplying by a hundred. We had a simple calculation here. So in this calculation, benefit can either be revenue or cost savings. And in our case, the benefit is the potential costs saved as a result of the risk prevention work.

Conducted by PMs like discovery work. We therefore need to propose what these potential low costs would have been and center our argument around that. So it comes down to the cost of delivery work or just the cost of discovery work to find out whether an idea is valid or not versus the cost of the development and the delivery and the launch activity and then have that feature generate no revenue.

So how do we calculate that?

So here’s how you run it. The point is best demonstrated by one specific example where a piece of discovery work killed a feature idea when you’ve chosen that example, and you need to map out. What you think the costs would have been if you went ahead and built, market and tried to sell that [00:23:00] feature.

That’s where it’s most powerful. Then you work out how long you spent in discovering this and then work out the cost of that based on your salary or your business running costs, and then you take away your costs from those potential wasted costs and use that to calculate the ROI.

So should we take a look at an actual working example? taking a look at an example that isn’t completely made up. So here’s an idea at BroadPad that we thought had like legs. We were going to do this, but then discovery proved otherwise. So this is my rough estimate of the resource time and therefore cost it would have taken had we gone ahead.

And we’ve based this on US salary benchmark data. Your results may vary because your team may vary. Maybe in different places. So you can use the same base or you can do it based on the salary bands and location of your own company. But remember to consider the full journey post discovery, right?

The way through to the hours, the sales team will spend [00:24:00] trying to sell this product unsuccessfully, if they had tried to sell something that discovery was going to tell you that it wasn’t the right thing to build. So cost estimate here, 46, 000. And next I’ve put a cost against our time for the product manager doing the discovery work that showed us that no one actually wanted or needed our product idea.

And then I take the discovery work cost and I subtract those from the potential that we’re Lost costs from developing that product that no one wanted. And that’s my cost savings, the benefit. And there I have all the numbers from my ROI calculation, right? So it gives me a huge return on investment of 15, 000%.

This is basically proving that had I just taken this idea and pushed it forward to the development team, we would have spent a ton of money. But making use of our product manager and having them run discovery on it saved us. A huge amount and gave us an ROI of 15, 000 percent [00:25:00] great insight to have.

All right. And yeah, I’m seeing some thumbs up in the chat here. Thanks guys. All right. Love this quote. This actually came from somebody in our product design team. They said a rule of thumb for every 1 invested in user experience research, you save 10 in development and 100 in post release maintenance.

And this is from somebody at IBM. So they’re very smart. And I bet they have similar calculations as well to go behind this. So feel free to use this one. All right. This is a good time to take a sip. Because we are at the halfway mark and we still have more calculations to go. You want to see more?

All right. I told you this was heavy. Going deep. It’s calculus next. I’m joking. We don’t do calculus here. You might be familiar with the cost of delay. Anybody here use the cost of delay? This one’s a little bit more middle of the road or popular in the product management [00:26:00] circles. It’s used as a prioritization tool as you make your decisions about what to work on and when but cost of delay can also be used as a tool to help you quantify your value to the leadership team.

So you can use this calculation to illustrate the very real commercial impact your decision making can and does bring. So by showing them your cost of delay calculations. You’ll be putting a tangible monetary value forward to support your narrative around the importance of your decision making. So the main principle of cost of delay is that the realized profit depends on availability.

So in other words, the longer a product takes to be developed or a feature to be added, the longer the product launch is delayed and the longer it takes for revenue to be generated, right? There’s no point working on something for six months if it’s not going to be making money that entire time. So you can use the cost of delay to show how your decision to prioritize one feature over another resulted in higher revenue per [00:27:00] unit of time within a given period.

So here’s how you do that. Find a real prioritization decision that you made between two ideas or initiatives. Calculate the value of each feature, determine the time to develop each, calculate the cost of delay for each. And then calculate the revenue generated from the two features across two scenarios.

The order you prioritize them and the alternative order, the alternative timeline, and then show the revenue impact of your prioritization decision. All right. So let’s give you an example. Let’s say I have two feature ideas. First, I need to estimate the revenue they would make per month on release.

Now, this isn’t easy to do. I’m not going to lie, but remember something is better than nothing, right? You can use broad stroke estimates for this. I’m not asking you to predict the future and you’re not going to be absolutely certain with these revenue projections but you’re using them as estimates.

So you can start a [00:28:00] conversation around them. And as long as you’re estimating as much for one as the other, then they’re going to come out more or less fair. So things that you can think about, like, think about the number of potential users, decide what a reasonable conversion or adoption rate is for those users, look at your existing conversion data or use benchmarks now look at the number of converted users and multiply that by your average revenue per user.

That’s one rough way of doing it, right? And you’re not looking for exact numbers. You were looking for orders of magnitude, right? You know, maybe the lack of this feature or functionality meant that you lost deals. So can you look at your pipeline data and see the average number of deals lost per month as a result?

Now you can look at the average deal value of those lost deals. And that’ll give you an idea. You can project revenue from the launch of this feature. That’s equal to the deal value that you’ve been losing out on each month prior to this. So there’s a number of the ways that you can estimate potential revenue from any particular feature.

You might need to get a bit creative and [00:29:00] no, it’s not ever going to be airtight, but you’re presenting some projections here, and that’s better than no projections and not having anything you can talk about. And you don’t want your leadership team to think that you’re not commercially aware or ready to talk about this stuff.

So put some numbers out there. And we just gave you some heuristics to go by. And once you’ve put a revenue potential, per week or per month or per quarter or whatever it is against each feature, then you can say what revenue you would fail to earn. Should it be delayed? Now we work out the estimated delivery time or development time of each feature.

So we know how long they’re going to take. So therefore we can work out the monetary impact of delaying each feature.

All right. So once you have those calculations for the two features, you want to. You want to use those to illustrate this principle. You can demonstrate how your decision on [00:30:00] which prioritized led to a higher revenue generation in a given period. So you do this by mapping out the two different scenarios and the revenue generated in both cases.

So in our example, it would look something like this. And I’ll leave this up here for a second. I’m going to have a sip of water and also just keep an eye on this chat. Cause it looks like there’s some fun stuff happening in here. I like this quote, as the saying goes, if it’s worth doing, it’s worth doing the fake math.

Thank you, John. That’s a great quote. We’re going to maybe add that to the guide. 

Megan Saker: Yeah, I think that’s worth a pull out quote. 

Janna Bastow: Perfect. All right. As you can see, we’ve got two different examples here. Let’s just skip to the very bottom of that. Big thing that you’re seeing here is that your work for feature B delivered 50, 000 more additional revenue for the organization in six months.

All right, that’s the key thing that you’re going to be taking to the headline. Or that headline is what you’re gonna be taking to your exec team. All [00:31:00] right. So that’s one that you can be using to your benefit. Okay. So let’s talk about another calculation. So the next one in your arsenal is your it’s in terms of cost of saving.

So this is overrun in a similar way to how cost delay looks at what would happen if a feature or product was released later, overrun is concerned with the, Economic impact of a feature taking longer to deliver. Whereas cost of delay focuses on lost revenue, Overrun is concerned with the increased costs when something takes longer to develop.

And you can use both of these. All right. One, two punches. You can use Overrun to illustrate the work that you do to minimize costs for the business. So to present And a calculation for your impact on overrun prevention, you should take again, a specific initiative or an idea as an example and run the calculations across all completed initiatives in a given period, say, let’s say the last quarter.[00:32:00] 

All right. Um, you want to paint a picture of how and where the overrun risks lie and this helps to remove your um, reduce your scope creep and any unforeseen technical challenges you’re also going to be suggesting the potential impact of these overrun costs, right?

You want to be able to calculate in any additional developer hours, additional QA. Testing time, you want to calculate any revenue lost due to the postponed release. So your cost of delay factors into this one, right? So what you’re basically going to be doing here is talking about how this impacts the overrun.

And you can also be using Okay. talking about how you as a product manager did thorough discovery during technical feasibility, right? How you had tight scope [00:33:00] management, what you did in terms of removing blockers, how you answered questions quickly, how you progressed dependencies and what this did to basically detail the work.

That you did to mitigate against overrun. So these are different examples of ways that you can use overrun to prove your value. And how you’ve mitigated against the costs for the business. So a couple of ways that you might express this and put numbers against it. You can say things like, I was responsible for ensuring the total cost overrun was as low as 3 percent in the last fiscal year.

Year, right? So it can be expressed as a percent of the original estimate or as a percent of the initiatives that you kept to the time and cost, right? We all know that most. Initiatives, most projects do run over. So if you’re able to minimize how many of your own projects run over and by how much you’re already ahead of the game.

So you can [00:34:00] put numbers to these and then you can start using these conversations to present to your execs.

All right. And let’s move into product velocity. So we’ve already talked about the ways that your work drives product velocity. So how do you put calculations into those claims? So you’re going to need to start by clarifying what you mean by product velocity. So product velocity refers to the speed and efficiency at which a product team can develop, test, and release new features or updates to a product.

And the benefits of increasing product velocity are obvious, right? If the velocity is high, then The throughput in any given time is more, there’s more to sell. You’re creating more value, more reasons for people to buy, more reasons for customers to stay, more revenue, everyone wins. So the best way to prove your impact on product velocity is therefore to have before and after data, you want to be able to show.

[00:35:00] How the team was operating before you got in there and what you’ve been able to, what impact you’ve had on product processes and therefore product velocity after you’ve implemented and improved process flow. And this is really useful for anybody who is getting their hands in the product operation side of things, which is, I know a lot of product managers moonlight as a product ops person.

Um, really, ideally, the cycle time and throughput of the product team before you joined or, the current state and or before you implemented a particular process. flow, but we appreciate that you don’t always have that data. It can be very hard to retrospectively gather it.

In which case you could do something like this, take a particular feature from your recently completed roadmap column and map out its process from start to finish, right? List out the workflow stages like we’ve done here at ProdPad, right? So these are workflow stages. They’re shown differently in ProdPad if you’re using that, but basically they go through a difference.

Set of stages and you look through the different ideas and you say, well, look at the [00:36:00] discussion threads, the revision histories, the workflow dates and signposts where things like, you helped make a faster decision. You coordinated efforts. You communicated updates. You chase progress.

You improved a process somewhere. You jumped into testing. You prevented a bottleneck. You removed blockers. You expedited a dependency. All those magic little things. Things that you do, you can highlight and you can attribute to the work that you’ve been doing. Anything that helped keep up the pace and the momentum and ensured the outcome was realized in the fastest possible time.

Point to those and help use that to indicate how you’ve improved something as part of the process. This is a brand new view in ProdPad. This is the report that we’ve just turned on as of today. If anybody wants to take a look at it this is all dummy data, but basically what it’ll give you a view of is how long well, lots of different reports in here, but this is the one that tells you [00:37:00] how many days any idea is been stuck in any particular workflow stage.

So you can use this to spot bottlenecks and. Prove the efficiency of some stages over others.

So for example, if we estimate that this feature here’s how product velocity might come through in an actual calculation. Right. So potential time to to reach that outcome without your efforts minus the actual time to reach that outcome with your efforts, right?

What’s that Delta divided by the potential time to that outcome without your efforts. Times a hundred is that improvement, right? So let’s say without you, it took seven weeks to do something equivalent with you. It was a five week project. Therefore that gives you a 29 percent increase in velocity.

great job product manager. This is a huge win for the team if they’re able to see these types of increases [00:38:00] in velocity. And this is a completely reasonable type of figure that you’re going to start seeing that teams would see with a product person in there. 

Megan Saker: And just to mention that what I think is important is you’ll have to go through the exercise where you are Telling the story, painting the picture of all the things that you do across all the different stages of the entire product management process that helps increase velocity.

And then you’ll have to take, it’s best to just use one particular feature example, because then you can, You can make an actual call. It’s quiet, it’s going to be manual, but it’s worth doing. So if you know that you jumped in and did some QA testing because the QA team had a backlog of four days or something, then you know, right, that would have added four days and you just got to go through and add them up to get you that in this example, two weeks time difference.

Janna Bastow: That’s a great bit 

Megan Saker: manual, but I [00:39:00] think it’s worth it. 

Janna Bastow: Yeah, absolutely. All right. We have covered a lot. We’ve talked about strategic yield, the ROI of cost savings, the cost of delay, overrun and product velocity calculations. This is actually only a few ways that you can deliver return on business and the ways that you might be able to calculate it.

We’d love to hear how other people make their point and make, prove this point and we’d love to hear how you’re using the technology. These particular metrics, if you take these forwards there’s other financial metrics that you can impact as well, like customer satisfaction and employee engagement and other things like that.

So use those to your benefit as well. We don’t have time to go into all those today, and I can already see that there’s a bunch of questions stacking up. So I want to get to those. I want to leave you with a final thought once you’ve made your case and crunched your numbers. We want to make sure that you consistently communicate and then prove the return on your activity going forwards.

And it’s infinitely easier to do that if you have a tool like ProdPad that helps you show progress [00:40:00] and track outcomes and prove strategic alignment. So start a free trial today at ProdPad if you’re already on board. Awesome. And if you’re not, then get in there. And as I did say, the guide is coming your way.

Keep an eye out for that or watch prodpad. com slash downloads where we put all this good stuff.

All right. Should we jump into questions? 

Megan Saker: Yeah, absolutely. Let’s do it.

Right, let’s start Jan. We’ve got the first question that came in from Megan was different Megan with an H. What would be considered a strong strategic yield? And this is interesting because, yeah, because I suppose, and actually there was another question I saw somewhere asking about, what would be a what would be an example of an objective that isn’t strategically aligned?

And I think the point is that ideally, [00:41:00] They all are. If you can have a strategic yield of 100%, if you can demonstrate that 100 percent of the work that comes out of the product team is fully aligned with the strategic priorities of the business, that is ideal and that’s where it, that’s where it should be.

So a strong strategic yield is 100%. But there will be, if you think about other teams in the business, if you think about the HR team, the finance team or whatever, there is so much business as usual. There’ll be so much work that isn’t exactly strategically aligned. And the point that you can make is you can run a particularly, you can deliver a particularly high strategic yield versus other functions in the business.

Janna Bastow: And part of it is also showing the delta between it. So saying, Hey, last year, we didn’t have our strategies aligned. And so we built this stuff over here, which actually didn’t have the right impact. It wasn’t aligned. And so this year, we worked on getting our OKRs aligned. We now know what we’re working on.

We’ve come up with the right stuff and we stayed online [00:42:00] with our strategy. And we had a hundred percent. strategic yield or a 95 percent strategic yield. And we only went off piste when this other thing over here blew up and we had to go do this thing. So you’re able to show the improvements in it and where it is that you’re driving differences.

Great question. Yeah, 

Megan Saker: absolutely. What else have we got here? Mike has asked, oh no, Mike’s question was really what we talked about there, what would be an example of a product objective that doesn’t align with strategy. And there might be an objective that you have in the product team, which is about Moving from one hosting provider to another to save a few costs or whatever efficiencies that although you could argue it up to being strategically important if you can show what is 100 percent and obviously aligned.

Then, that’s your strategic view. What else have we got here? Marie asked an interesting question. How would you prove ROI when you’re working on a [00:43:00] platform migration and scope creep is absolutely huge. So users are not happy to move and would prefer to have and prefer not to have to adopt a new platform.

The business wants them to move. The overrun is huge. How does she tell that story? That’s a really, really tricky one. 

Janna Bastow: So how would you prove ROI when you’ve got

Megan Saker: She’s working on a platform migration scope creepers is huge. So I don’t think overrun is huge. So that’s not your calculation. Absolutely. Stay away from that one. 

Janna Bastow: Well, okay. A platform migration is actually a really interesting use case or not use case, but an interesting situation.

And it’s actually an opportunity to actually move the team into a more lean and strategically driven space. A lot of people think that a platform migration means that you have an old platform with a hundred features or a [00:44:00] thousand features, usually. And now in order to migrate people, you need to build a new platform with a thousand features.

And people only move when you build a thousand features and they can go do all the other stuff over here. The reality is that there’s probably a set of like 10 features that most people need, and you can rebuild that sliver of the platform to get. A good chunk of those people over, even if it is just a mini app, a small version of your app, and you say, Hey, you know what?

You use the main product over here, legacy chunker to go do most of your work, all the admin and setting stuff. But when you want to go do the thing that you do most often use our new shiny version over here. And this one is going to be much easier to use and easier to support. And. Customers love it because it actually looks nice and works on mobile and all that cool stuff.

And you just build the few things that work for those customers. And you do so in a lean way. You do the discovery, figure out which 10 features work the best, and you rebuild those. And once you get those customers [00:45:00] over, right, you get a good one. Chunky your customers over onto those 10 features, you build out the next 10 features and the next 10 features, but you follow a lean way of doing so.

Right. So you only build them based on customer needs and whatnot. So you’re not building it because the old product has it. You’re building it because the customers using this are going, yeah, I love using this, but I need to be able to configure this too. Okay. Yeah, we did that in the old one, but how would we build it for this new one?

Let’s think how would you do this at the new platform? So you’re not trying to replicate old and new and rebuild it from scratch and trying to get feature parody before you try to do any sort of migration. You’re actually disrupting your old version of your platform by acting like a startup, building a small sliver of your platform and migrating people over one by one or, bit by bit.

And ideally. By the end of it, you’ve rebuilt enough of it, probably not all the features because some of those features never need to get rebuilt. No one was using them in the first place. So the new version isn’t a [00:46:00] replica, but it’s a better version of the product that serves the needs of your customers today and not the needs of what your customers needed when you built this thing 10 years ago or 15 years ago or whenever it was.

Megan Saker: Yeah, and I think Rebecca and Debra have made a couple of interesting points in the comments. And I think what’s important is not to get hung up on trying to prove the ROI of the product, but the ROI of you, your role as product manager. The decision to do the migration, you can talk about how that reduces risk.

for the organization, the long term benefits of, one code base or whatever, et cetera. But what you want to demonstrate is your work, how your work as a product manager has delivered value. So Rebecca made the point here about without the product manager, potentially the migration couldn’t happen at all.

Or, and Debra says, the same with that [00:47:00] process map that we showed you to demonstrate where, even when there is overrun, even when there is scope creep, where did you add the value to reduce that as much as possible? So you could still paint a sort of before and after picture, or if I wasn’t around, what would this look like?

And demonstrate, the complete show it would be. Without you and put money against that, right? Quantify that. 

Janna Bastow: Yeah. If you were trying to do a rebuild of an entire platform and you weren’t there to guide them, they would probably try to rebuild the entire feature by feature thing. Because they’d say, the spec is this and they’d send it off to the dev team and the dev team would just try to replicate it.

And they’d end up with Pile of junk that looks like the old one, but it’s on new technology and you’ve lost all of that value that you could have done with all that discovery work in the meantime and what was the point of it? So yeah, definitely some ROI proof that can be pulled out of that situation.

Megan Saker: Right. Next question. We’ve got a big [00:48:00] one here from Ian. Curious to get your thoughts on the overlap and contrasts in calculating ROI in one entrepreneurial founder startup BPO perspective versus middle mid level demonstration of ROI in an established company. PlugginJannana’s session last week on product operations, but wondering practically how much of this ROI calculation a PM should do on their own versus trying to scale and delegate to product ops when they’re trying to prove the value.

Like without burning out. 

Janna Bastow: Yeah. It’s such a good question, Ian. Like everything, it depends if you need to put in as much effort into it as makes sense for what’s needed for the business. Right. Don’t drop everything and start running off and doing these calculations if it’s not required, right.

If your business is happy. Trucking along, your division is safe. And you’ve got space and time to go do good product management work. If it’s something that is a contentious [00:49:00] subject and everyone’s going, what is the product and do we actually really need them?

And people are wondering what the return is on this product team, then put the effort into it. And chances are it’s those teams that don’t have. Product operations, right? They, and if they do, then product operations are also probably feeling a bit hot under the color wondering as to what their value is as well.

And so you might want to work with them to say, Hey, so we both need to be able to prove our worth here because it’s going to get tricky soon. The real Thing here is that whether you are in a startup or a mid level or a large business, they just want to survive, right?

They want to see a return on investment. And that investment is they’re hiring people to help add value to the business. The business can continue and continue to grow. And if they’re not seeing that, And times get tough. They’ve gotta make tough decisions. And it’s, it sucks. And so it comes down to the people who are in those roles to sometimes make that case.

[00:50:00] And that’s regardless of whether you’re in a startup or a larger business. 

Megan Saker: Yeah, I think in terms of the effort involved, you don’t have to, like we said, having some sort of argument is better than nothing. So you don’t have to look at this huge daunting task of looking across like all your aggregate data and trying to work out the velocity across everything, blah, blah, blah.

Just, you can just take Like we’ve done a lot, just use one particular product idea or one particular feature that you’ve done and just use that as an example to illustrate the value that you’re doing. You don’t have to make huge claims on exact revenue that you’re responsible for in each fiscal year, but you can show, look, let me, Give you an example and present a smaller instance where you can attribute your estimate of value to it.

[00:51:00] Yeah. Let’s have a look now. Liam’s just posted more questions, so let’s blast through them. I’m just getting so into it. I’m looking at the clock. Oh yeah, we’ve got two minutes. Yeah, we’ve got time. Keep them coming. Is there a risk of seeing velocity understood by stakeholders as a measure of output rather than outcome?

that’s a really 

good point. 

Janna Bastow: Yeah. And actually there’s nothing wrong with being measured on velocity and output as long as it still is tied to outcomes, right? It’s one thing that you are, as long as it’s not everything, right? As long as they’re not saying, hey, it’s velocity at the cost of output.

But what drives those outcomes? Well, you’ve got to be able to get things out the door, right? It’s actually doing things, running the experiments. And it’s not velocity in terms of lines of code shipped or we’re smarter than that, but it is in terms of shots at net, right?

Experiments run. And sometimes those experiments are things like building a new [00:52:00] feature. Right. Or building features faster than ever. Cool. But sometimes it’s changing features or taking features away. And sometimes those experiments aren’t feature experiments. It might be changes in pricing or packaging or process or proposition or other things like that, right?

So if the product person can get the team savvier and moving faster at running all sorts of experiments yes it’s output, it’s doing more stuff, but as long as they have the the discipline to, set hypotheses set target outcomes, measure what comes out of it and understand as to what’s working, what’s not working and are able to do this more and more chances are their numbers are going to go in the right direction, right?

They’re taking more shots on net and more things are going to land. And that’s just the fact of it. 

Megan Saker: Yeah. Right. So should we sneak one more in? We can sneak in a couple more. Yeah. Okay. Here we go. Alex has asked the question, how might you go about communicating expected long term ROI and [00:53:00] timing of that ROI in the long run to executives to justify investment size of the overall engineering design product team when product is a new, is new to the company and long term strategy is not very clear?

Janna Bastow: If you’ve got initial thoughts on that, go for it. 

Megan Saker: Well, I was just going to think that, so if you if it’s new and you don’t have data to tell, then I think you’re, you talk about the, what product management will do, what your process will be. And then again, just give examples.

This is the kind of difference. that this process and this work will deliver. And you can just get into, like, right, imagine now we’ve got this process, this is happening, and you don’t have this function, you don’t have this role. Now here, let me paint a scenario. It’s scenario planning, in a way, and an exec leadership team will know they’re scenario planning.

You, you [00:54:00] can. Run different scenarios with and without the investment that you’re proposing and pitch it that way. 

Janna Bastow: Yeah, exactly that. You don’t know the future, but you can start putting things out there to start the conversation, right? So if the strategy isn’t crystal clear, you can use your roadmap as a prototype for your strategy and say, Hey, so we’re here.

The vision we think is this. Make sure you have that conversation to get people aligned with that have conversations around why it is that they’ve they’ve brought in product or what is it they’re trying to achieve with the product and then say, okay, so we’re here and this is, here’s where I think we need to go next and after that, and then start having conversations around that and start mapping out different scenarios.

Like we go here and here, it gets us here. But if we go here and here, it gets us here. And start. Mapping out what that looks like and what sort of opportunities it unlocks, what sort of revenue it unlocks, what sort of costs of delay it might be able to calculate along those different paths.

But what you’re actually doing is you’re using it as a [00:55:00] starting point for the conversation. So you’re not going to have all the answers, but you can definitely start using that as a point to start calling that conversation out with the execs to say, Hey, like we don’t have a crystal clear strategy, but.

Product is here to help facilitate it and have that conversation so that we do agree on what our long term strategy is, and then we can all get on board with it together. It’s a really key point. Right. One more? Yeah, go 

Megan Saker: for it. Okay, we are over. We’ll just do one more. Vinay is asking, would NPV analysis also work along with the cost of delay?

Now my understanding, net present value is NPV net. Present. Yeah. Sorry. My understanding of net present value is that it is obviously a financial accounting metric. You are drilling down more into the complete cost of sale and all the costs involved. [00:56:00] Cost of delay.

If you, I personally don’t think you need to go that deep. I think you can illustrate with the cost of delay, you can illustrate enough to make your point rather than having to drill down into everything. That every single cost that business will incur with the delay. 

Janna Bastow: And, honestly, it’s something I haven’t seen, but it’s a tool that we can use.

Try it out, see how it might work, and present it. And you might find that it is a useful calculation that could help. Yeah. We said that ours isn’t a complete list. There’s definitely going to be other ways that you can use calculations out there. Net present value might be an interesting one to use alongside it.

So Vinay, give it a try. Let us know what you come up with in that area and get back to us. In the meantime, everybody keep an eye out for that guide. It is coming. There’s going to be more on that soon. And on that note, we are over time. We did have another slide here. We have a guide that we’re going to send you on getting your [00:57:00] stakeholders on board with the Now-Next-Later roadmap.

Oh, and I have a final slide. Q& A. All right, that’s all I have. Somebody said the same time next week. Almost. We’re gonna have another one coming up next. Megan, who is it we’ve got next? Oh god, you put me on the spot. Is it Teresa Torres 

Megan Saker: next? It is Teresa Torres. Is it Teresa Torres next? 

Janna Bastow: We’re into June next.

She’s June. Goodness. And then we’ve also got 

Megan Saker: another webinar where you and I, Janna, are going to be talking through how to optimize your product processes. 

Janna Bastow: Excellent. And I saw a request here. You guys are welcome to make requests. Somebody said something about reviewing risk.

So we could do something about risk. We’ll workshop it. Give us ideas. Yeah, it’s always really interesting. In the meantime, thank you everybody for jumping in on the chat and the questions, giving us lots and lots of things to chat about. Sabella has just suggested the product go to market.

Megan, you’re up for that one. Haha, sure. We’ve got lots to talk about, so we [00:58:00] will see you back here. Same time, same place. Well, we’re not sure about the exact timing, but we’ll figure it out. All right. Bye for now, everybody. Thanks again. Bye. Thanks.