Product Management Webinar: Driving Value with Goals

[00:00:00] Janna Bastow: Hello everybody and welcome. So we’re just kicking off here. this is a series of webinars that we run here at ProdPad called the Product Experts Series, where we invite, as you might imagine, product experts to come along and chat to us. today we’re joined by Maarten Dalmijn, who is a consultant, trainer, speaker, and author. we are gonna be doing a, full proper intro to him in just a moment. but we’re gonna be talking about his new book, Driving Value with Goals. so before we jump in and introduce you to Maarten, I wanna tell you a little bit about this tool that we’re building. you might be familiar with ProdPad, you might not be, but, you definitely should be if you’re a product person. It’s a tool that myself and my co-founder built when we were product managers ourselves. you might know us as a couple of the founders behind Mind the Product. we needed tools to help us do our own jobs.

When we were product managers, it was something to help us keep track of all the ideas and feedback and experiments that, were winging around us. And so we built something to keep track of it. It was something to help us build our roadmaps every month and to get our teammates on board with it. And so it gave us control and organization and provided a sense of transparency to the rest of our team and created this single source of truth for the product decisions that we’re making.

And it’s now being used by thousands of teams around the world. And it’s a tool that you can try completely for free. You don’t need a credit card, you don’t need to, sign up for anything. You can just jump in and, play around. we even have a sandbox mode where you can just jump in and start seeing how example, uh, roadmap data, lean roadmaps, OKRs, experiments, all this sort of stuff fits together. but you can always jump in and get a demo and, we’ll be happy to, tell you more. But enough about us. I wanna introduce you to Maarten. we have been swapping notes for several years now, all online because we got introduced to each other over, the pandemic. I think that’s when we started talking. But, he had been writing some interesting articles about things like the Now-Next-Later roadmap and how he was using it. and he invited me to write the Forward for his upcoming book, Driving Value with Sprint Goals. so we’ve had a chance to work together on that, which is great. Maarten is a consultant, speaker and trainer. he helps teams worldwide beat the feature factory and excel in delivering value. He has articles on Agile, Scrum and product management that have been read by millions, and he is a sought after speaker at Fortune 500 companies. he’s worked with everything from startups, scale ups, and is an ambassador and editor at Sirius Scrum, which is the largest scrum publication on Medium. So everybody please join me in welcoming Maarten Dalmijn.

[00:02:48] Maarten Dalmijn: Thank you very much for this, lovely intro. [laughs].

[00:02:50] Janna Bastow: [laughs]. Absolutely. All right. over to you. 

[00:02:56] Maarten Dalmijn: So I’m gonna be talking today about Driving Value with Goals, or in other words, how to do better than simply keeping the hamster wheel turning or to simply do better than keeping that feature factory turning. And I’m gonna start by telling a hamster wheel story. So once upon a time there was a roadmapping session and we had these every quarter and I really dreaded them. I would up with a headache, I would be dreading the day, and I would ask myself, “Where’s my coffee?”

Because we had to go into meeting rooms for multiple days, talking over and over again about the same things, like, looking at data, analyzing, thinking. And if you look at those people, they all look very happy. We were not very happy. We’re all pretty grumpy. That’s what happens when you put people in meeting rooms for multiple days.

And what I wanted to say is there were so many rules for this whole road mapping ceremony. I call it a road mapping series, actually, like every item had its own color designation. there were rules for how to formulate the business cases and how to map dependencies. And if more rules produced better roadmaps, we totally nailed it. We were the best of the best.

And then that wasn’t enough, right? Then we did our job and then we would be grilled over again by the CEO and domain over discuss the same things, like, should we do this first? Should we do that first? And it was just incredibly frustrating ordeal. So we were in the Champions League of mapping and if roadmaps that [inaudible 00:14:26], like the managers create cry, Joe, we were the best, the best.

But then of course, after the first month, we were already behind. Like people refused to help each other because every team had their own roadmap. And then it basically became a contest just to follow the plan was more important than meeting the objective because after all, we invested so much in those beautiful plans and everybody loved them.

And yeah, you might be thinking this is anecdotal evidence, but actually spoke at, made and to come London and actually asked the audience, who here has ever delivered everything on the roadmap is expected. There were hundreds of people and nobody said they ever did it. Of course there were people that have gotten close, but nobody ever delivered anything on.

So it’s a common problem. It’s not just me and I call it the planning cycle of madness. And I will try to explain and this co- at this company I was just talking about like the hamster wheel I went through it multiple times.

So basically what happens is we feel to meet our plans, roadmaps and timelines, and then management becomes angry. Our plans suck. We must do a better job planning and predicting. So we’ll do a better job this time. We go in our meeting rooms, we spend more time fouling and talking and thinking, analyzing, turning over every stone. And then what happens is we overfit our plans, we inject noise and speculation. Our plans become disconnected from reality and rooted in our imaginations.

And then those plans actually to the opposite, they become an anchor. They stifle our ability to collaborate in depth, and then we’re locked into plans that drag us down. They prevent learning, collaboration, this discovery, and this keeps going over and over again. So in this talk, we’ll talk about what can we do about it and why does it happen?

So we’re swinging for the planning home run, like endless meetings. We’re trying a planning home run that we know will never happen. So what should we do instead? And actually, I’m not gonna be talking about military history and before I continue, I would like to stress, I’m not gonna glorify war anyway, any way or say that building a software com- is comparable. But what I do want to say is a lot of the lesson hard-earned lessons that were learned in the military, we can learn a lot from them because they have a lot of problems with planning.

So this is actually a, German general, and this is a quote from him. The dream of a perfect plan is the enemy of a good plan. And I think that’s very apt for, situation I was just describing. We’re so focused in trying to produce this perfect plan that we actually become our own worst enemies. And von Clausewitz actually wrote a book, it’s called On War, and he coined a very important concept which affects all of our plans.

And he calls it friction. And friction basically is a force that’s especially presents in war, but also in other complex situations. And it makes easy things diff- different, difficult. It’s basically that distinguishes real war for war on paper. And it could be, for example, that you ask a group of, horse rider to go in a certain direction, but it’s muddy. So they take 10 minutes longer than arrive. All these little things can have all these un- unintended consequences that affect your plans.

And Steven Bunge created this really beautiful model. And if you understand this, you can actually explain agile from first principles. You don’t need to talk about the agile manifesto. If you understand this, then you understand like, why is agile important? Why do we need to adjust our plans? So basically idea is you have a knowledge gap, which is the difference between what we’d like to know and what we actually know.

So the more friction we have, the more surprises, and it means the more thence there is between what we’d like to know and what we actually know. So the bigger the gaps are, we have an alignment gap. So if we tell people to do something, they might not do it exactly as expected. So the more friction we have there, that means they’re not gonna be do exactly as what they’re told. And then we also have an effects cap.

So even if we follow our plans and do everything perfectly as expected, it might not lead to the produced results. So if you have more friction, that means you’re gonna have a difference, a bigger difference between what you’re ac- what you expect your actions to achieve, and what the actions achieve.

So why is this important, right? Because if you understand what kind of work you’re doing and the extent to what to which you are, affected by friction, this affects how you do planning. So if you’re in a clear domain where there’s no friction, that means anybody can make a perfect plan. Anybody can predict you, just give people the plan, execute life is great. Wouldn’t that be swell, Is that word case.

If you’re in the complicated of domain, that means there is some degree of friction. It means you need to get experts, you hire experts, let them make the plan, and then you can let people follow the plan. But if you’re in the complex domain or the chaos do- domain, that means that your plans are gonna suck. Even if you have the right expertise, they will need to have to change. Like you’re gonna have so many surprises because you have so much friction that you cannot make really good plans before starting, and that you will have lower predictability.

So on the left hand side, you have the plan driven approaches, right? They work really well. The goal can be implicit because the plan doesn’t have to change. And on the right hand side, you need, you must have a goal because if you don’t have a goal, you cannot change the plan. You don’t know what you’re trying to achieve. So you need to have an explicit goal because those plans before starting are not gonna be good enough.

So on the left hand side, I would call it in the plan, we trust, [laughs], in the other side in the results we trust. Don’t trust the plan. no trust the results. So what makes it really difficult is if you’re in this situation, right? Like when you can plan and predict there are best practices, right? So getting more information and doing more analysis for starting is a best practice when you have f- little friction, it’s also a best practice to issue more and more detail to instruction to people when you don’t have a lot of friction.

And it’s also a best practice to have a lot of checkpoints and controls like, hey, if this happens, do this. and the problem is, if you do this in a situation where you have a high amount of friction, these are actually the anti-patterns. This is actually what you should absolutely not do. And this is actually what we do because actually our natural inclination is actually, work that’s clear or so our natural inclination is to do more information, obtain more information from starting and do more analysis to issue more instruction. This is what comes natural to us. but this does not work when you cannot plan and predict your experience in a high amount of friction and you will have many surprises. And I will get that later to what we should be doing. But this is really important.

So this is maybe a simpler way of visualizing it. So on the bottom, you have complicated, right? So if you don’t spend a lot of time preparing and planning, your plans are gonna suck, right? But if you do spend a lot of time planning and preparing, your plans are gonna rock. Like of course you need to have experts, but you can make awesome plans. Life is gonna be great, but on the top, your plans are gonna suck if you don’t spend a lot of time predicting, planning and analyzing.

But if you do that, then they’re gonna even suck even more. So it’s actually what you should not do. And another way of visualizing it is, so if you’re in a situation where it’s complicated, there are actually a lot more things that you do know than what you don’t know. And then if you do what I call confident planning, let the expert make plan, do a lot of investigation analysis, what you don’t know gets reduced, you will very few surprises. But if what you’re doing is complex, which means a high amount of friction, a lot of surprises you can’t then predict.

That means if you follow that same approach, you’re gonna have this little orange box with speculation and noise. You’re gonna have false assumptions and you’re going to try to make up the things you can know and you will have overconfident planning. Your plans are disconnected from reality and there will be anchored in your imagination. So what shall you doing instead? We should actually start with humble plans. And humble plans are basically plans to acknowledge how much we don’t know, how much we still need to discover. as we do to do work, we discover what’s necessary to succeed. It’s not saying we shouldn’t plan, it should say plan more later. We have more information and a better understanding of what we’re doing. And that produces what you don’t know. And that’s where actually goals come in. So the German army actually solved this problem many hundred years back. It’s called UltraSoC T. So you might know this quotes, no plan survives first contact with the enemy.

So the German army deeply understood this and they developed a way of dealing with it, and it’s called UltraSoC. So the solution is you should provide troops with intent. And basically this quote really captures the kind of thinking, like you don’t want soldiers to wait for orders at a time when you cannot give orders. They should be able to make decisions in the moment as they discover surprises or stuff that they didn’t anticipate.

And, but of course they need to act in alignment with a certain intent, what are we trying to achieve? And that’s why in the German army, but also currently in the US Army, also in Ukraine, like they are using commander’s intent. It’s basically when you have a plan, you need to have an objective, which is called commander’s intent.

And it basically represents what are we trying to achieve and why does it matter? And when you understand that, that means that the people who are in the battlefield who see, stuff unfolding and happening can change plans and actions to achieve the desired results because they understand what we’re trying to achieve. ‘Cause that’s provided by the commander’s intent. So here’s an example. This is a real world example from D-Day, which as depicted in saying by Ryan.

So there are two parts, the what and the why. And from Operation Overlord, basically the what was, they wanted to secure these key bridges, these road junctions and other locations in Normandy, because that would allow it around invasion forces to advance in land. So it contained both, and that would super important because imagine like all key bridges or road junctions would’ve been, uh, destroyed, right? They would’ve sabotaged them.

They, then they would understand like, Hey, we cannot do this anymore. What will we do? It provides a lot of context. So that’s why like whenever you work with goals, you should, it should include this intent. What are we trying to achieve and why does it matter? Because that means that people can change the plans as necessary to achieve the desired results.

So now to get back to this original model, right? What should we do? What is the best practice when we have friction and a lot of surprises. So when we know less than we’d like to know, we should clearly communicate intent. Because when people understand intent, then they understand what are we trying to achieve and why does it matter? And when people, need to change their actions, right? Because stuff happens and it’s differently than expected, let the teams come up with the plans and they can do that if they understand what we’re trying to achieve.

And then they can also report it back to the higher levels, but they can also adjust it. So not our best practice is adjust the actions and plans in line with intent. So actually an example from the German army was that, it was even okay to make decisions against the intent, right? Like that may seem very weird, but there was a situation, for example, that, something happened and a general made the decision to go against intent. And normally you would actually say, they would be course marshaled, right? You need to follow out the orders.

But they actually wanted that. They wanted to be opportunistic that people could make the right decision in the moment. So what’s really important is if you are doing competence work with friction surprises, you need to start with humble plans. You need to provide intent and work with what you do know to discover what you don’t know, and then adjust plans as necessary.

And it’s not about planning less, it’s about planning later when you know more. So delivering value in theory, right? This is what many stakeholders believe, and it’s also what our roadmap approaches suffer from with the Gantt charts. Like you have a feature, you deliver it as fast as possible. That’s the main problem. And then they ask you how is it gonna work? And when is it done? [laughs].

But as we all know, in practice, it’s much more messier, right? It’s unpredictable, it’s messy. There are learnings, there’s stuff that gets discarded, and sometimes you deliver value, maybe the best comparisons like a bottle of ketchup, right? Sometimes lot comes out, sometimes not, you cannot really predict it. [laughs].

So what I always say is delivering a features like telling a joke. Like it doesn’t matter unless next people laugh. So now to ch- tie this back to the world of goals, and this is maybe a nice way to look at it, is what we build and what we do, those are features, those are outputs, right? That we want to influence outcomes. one to make a difference for the customer, and then hopefully that also results in more money for our business.

But the problem is that on the left hand side, all those things are leading and that’s stuff we can influence. But on the right hand side, that’s something that happens as a result, we need to check it and it takes time. And it, doesn’t happen in one week, it’s something may happen over. So you need outputs and outcomes. You need to make the relationship between both. And that’s where goals come in.

And to give this is just a simple example, right? Like you improve the page on time on e-commerce website and the customer experience reduces, reduce friction and then you will have more revenue. It’s just a very concrete example. But you do need to understand the relationship between all these things. If you don’t know that reducing the load time results in, less friction, right? Because stuff loads faster and that has an impact in revenue, then you cannot make this relationship.

And then you can also not set a goal on the outcome level to, achieve the desired results. And I want what I want to stress, right? If you make roadmaps, they have to include goals because they are not the plan. Like we’re limited by the fog of beforehand. We don’t know enough before starting work, we can suffer from the fog of speculation. If you do the stuff I just told you shouldn’t do, and we have to keep it to cloud, our plans will suck.

They will be imperfect, our execution will be flawed, and the results will be unpredictable. And that’s why we must have intent. So in short, like whenever you make a roadmap, you need to include goals together with intent, because when you do complex work, your plans will suck and you need to change them. And our roadmaps should guide the creation and adjustment for plans to produce desired results.

And intent is a very powerful tool to achieve that. And whatever I said about planning uncertainty applies even more to value uncertainty, difficult it’s to plan accurately. Making sure that something is valuable is even more difficult. And that’s why we should start with humble plans that give us room to learn and discover what’s necessary and what produces the best results. Thank you for your time. [laughs].

[00:19:10] Janna Bastow: And thank you so much. And, you’ve got that up there, can you tell us a little bit about the, the book that’s coming out, when it’s coming out, where we can get it and that sort of thing?

[00:19:17] Maarten Dalmijn: Yeah, the book is called Driving Value with Sprint Goals. It’s coming out in August. what I can say is you can already pre-order it in Amazon if you want it quicker, you order it from person, but it’s gonna be an honest, because they first ship it to person and then to Amazon. but order whatever suits you best if you want to order it, of course, assuming. And yeah, the reason why it’s called Driving Value with Sprint Goals, not Driving Value with Goals, because goals is a very crowded market.

This is the first book in the world on sprint goals. so I wanted to plant my flag, but a lot of the stuff in there actually has very little to do with Scrum. it has a lot to do with product management linking those worlds together.

[00:19:52] Janna Bastow: Yeah. And actually, I love how you did the forwards. You had, uh, two of us doing the, forewords, one from one angle, one from the other, showing that linking of two wor- worlds. Isn’t that right?

[00:20:02] Maarten Dalmijn: Correct. Yeah, because yeah, so upload is like a big name in the agile world a, a big name in the product management world. And I think, yeah, it bri- I tried to bridge both world. That was my intent. And I leave it up to the reader whether I succeeded that.

[00:20:14] Janna Bastow: [laughs]. I, I think that’s a fundamental truth of, product people is that we live in the intersection of a number of different spaces. So this is a book for anybody who is in that intersection of product where we are and agile and trying to understand how they can, make most of, you say, Driving Value with Sprint Goals.

[00:20:31] Maarten Dalmijn: Yes, absolutely. 

[00:20:32] Janna Bastow: So 

thank you for setting us up for a, a great, conversation here today. for everybody listening in, feel free to get your, questions in the Q&A, jump in on the chat. We’d love to hear what you’ve got to say for, with all of this. I actually, particularly the, you’re starting off, you’re talking about, your question to the audience about who here has actually delivered their whole roadmap.

‘Cause it reminds me of early days in ProdPad, because we built the first version of ProdPad based on how I used to do roadmaps. And the first version of roadmaps that we built was a timeline roadmap ’cause that’s what I used to do, right? I would make this pretty looking Gantt chart thing and I would, show it to my boss and they would say, great, now go deliver it.

And I could never deliver it, but I just thought that was me being, a somewhat, not great product manager. I just figured everybody else was able to deliver theirs. And so when I, productize it, when I turned it into a SaaS type tool, and gave it to other people, they loved the idea of making this timeline type roadmap.

But the first thing that we started getting back in terms of feedback about a month after we launched it was that everyone wanted to take everything on the roadmap, move it over by a month, because no one else was delivering the roadmap. And I was like, “Wait a second.”

[00:21:41] Maarten Dalmijn: [laughs].

[00:21:41] Janna Bastow: And had I built what the customers asked for, I would’ve created some sort of like multi-select drag and drop to move everything over by a month, But I sat back and asked why, and I was like, why is no one delivering the roadmap? And these were even like really good product managers, right? People that I really rated. I was like, if no one’s delivering the roadmaps, then why do we have a timeline? What is wrong with this roadmap?

[00:22:02] Maarten Dalmijn: Yeah.

[00:22:03] Janna Bastow: And I, we had a crisis of confidence, particularly because we’d just spent months and months building obviously the wrong type of roadmap. And this concept of a Now-Next-Later roadmap hadn’t been around, right? And so we sat down and that’s when we came up with this idea of time horizons, this three buckets of, of, levels of confidence. And, that’s where the Now-Next-Later came from.

[00:22:24] Maarten Dalmijn: Yeah. and what I really like about your comment is basically, um, I’m, first of all, I’m a big fan of Now-Next-Later, I use it all the time. And, but second of all, I think it happens because people want the illusion of control. They want their glorious plan, like these-

[00:22:36] Janna Bastow: Yeah.

[00:22:36] Maarten Dalmijn: … Gantt charts, they look like these people know what they’re doing.

[00:22:40] Janna Bastow: Yeah.

[00:22:40] Maarten Dalmijn: And then when you have a Now-Next-Later, it looks like, yeah, okay, it doesn’t look as impressive, doesn’t look like there’s as much but into it. And then they become skeptical.

[00:22:48] Janna Bastow: Yeah.

[00:22:48] Maarten Dalmijn: And I think that’s one of the jobs like that managers are looking for. And where a Gantt chart is very good at providing the illusion of certainty. That’s how I would call it. [laughs].

[00:22:57] Janna Bastow: It is, it’s an, as you say, it’s an illusion of certainty. And I call it it’s a comfort blanket.

[00:23:02] Maarten Dalmijn: Yeah. 

[00:23:02] Janna Bastow: The boss’ love when you can give them that level of certainty when you can say, here’s what we’re gonna go deliver. Because what it’s doing, it’s absolving them from having to take the risk because they’re basically just saying, you know what? Jan’s gonna go do it now, or whoever’s gonna go do this thing. And if you don’t do it, you’re in trouble.

Whereas what you’re actually saying is, “Hey, we’re not actually sure how we’re gonna do this, but we’re asking for permission to spend the time and the team resources to go break these problems down. here’s what we’d like to be able to, here’s the goals that we’d like to try to break down. Here’s how much we’d like to put towards it. but we’re not gonna be able to tell you exactly which features are going to do that. What we can say is that we’re gonna run as many experiments as we can in this quarter. Last quarter we ran 50 experiments. Maybe this quarter it’ll be 60, maybe it’ll be 40, half of them might fail, and that’s fine because the other half will succeed. And by doing so, that’s gonna bring the numbers up.”

[00:23:58] Maarten Dalmijn: And so basically what I hear you say, like, the fundamental question is, do they want to know what we’re doing as much as possible, or do they want to make the most progress, like, uh-

[00:24:07] Janna Bastow: Mm-hmm.

[00:24:07] Maarten Dalmijn: … towards our goals?

[00:24:08] Janna Bastow: Yeah.

[00:24:08] Maarten Dalmijn: And those are two very different angles.

[00:24:10] Janna Bastow: Yeah.

[00:24:10] Maarten Dalmijn: And unfortunately, there is this preference for this control and knowing what we are doing well, the thing that they should care about is are we making the most progress towards our goals?

[00:24:18] Janna Bastow: Yeah. Yeah.

[00:24:18] Maarten Dalmijn: Yeah.

[00:24:19] Janna Bastow: And I’ve actually got a theory as to why. It’s because product is considered a cost center. The cost, like the role of being cost center is that you just try to keep the costs down. You just try to, make sure that, you’re operationalizing and you’re keeping the costs down so you you know where every dime is being spent. And so this is how we end up being measured by burn down charts and velocity and, how many story points we can get in one quarter versus the next quarter and that sort of thing.

What that gets you is a whole bunch of points, sorry, a bunch of features built, right, points. Is that any good? Are features any good? Who knows. whereas if you turn it around and look at profit centers, sales and marketing-

[00:24:56] Maarten Dalmijn: Yeah.

[00:24:56] Janna Bastow: … they get away with exactly what we’re hoping for, right? And so you can actually turn this conversation around for yourself, right? Because the VP sales doesn’t sit at the board and presents a roadmap of who is going to buy and when they don’t have a Gantt chart of, looking ahead for the next year, customer X is gonna buy this week and customer Y is gonna buy this week. They don’t know that.

At best they have, if you’ve seen sales pipeline thing, they have a thing that says-

[00:25:22] Maarten Dalmijn: A funnel.

[00:25:23] Janna Bastow: … a funnel that says, “Oh, we’re 60% sure about these ones and 30% sure about these ones,” right? And they’re warming up this funnel, and they say that, they’re going to take the resources, right? They’ve got a team, it’s gonna cost a certain amount of money, and they’re gonna spend the quarter doing a whole bunch of experiments.

[00:25:39] Maarten Dalmijn: Yeah.

[00:25:39] Janna Bastow: And by experiments, I mean, picking up the phone and calling prospects or doing emails or whatever salespeople do these days.

[00:25:47] Maarten Dalmijn: [laughs].

[00:25:47] Janna Bastow: And half of those experiments are gonna fail, probably more than half, right? They’re gonna get hung up on, right? Most of the time they don’t get hit. but some of them are gonna pick up, some of them are gonna land sales. And so they don’t know who, but they can guarantee that if they do enough of this, if they have a process by which they do experiments, then enough people are gonna buy and someone’s gonna buy the big packages by the end of the quarter and by the end of the year that they have permission to go back and do it again the next time.

And we’re not asking for anything different. We’re just saying, “Hey, give us some resources, some people to run experiments. Give us the space to create, the equivalent of our call scripts, our experimentation process, and give us space to run these experiments and let us fail, let us succeed and let us report back on what worked and what didn’t work.”

[00:26:29] Maarten Dalmijn: But I do think that salespeople do one thing really well, and that’s maybe where we can do better it’s results transparency, right?

[00:26:36] Janna Bastow: Mm-hmm.

[00:26:36] Maarten Dalmijn: Because, like deals closed or not, they’re very transparent about that. And I think one of the challenges we have, it’s not as black and white as closing a deal with a certain number of euros. Like we’re talking about your product helps a customer to level up. Like it makes their life easier. Every situation is different.

[00:26:52] Janna Bastow: Yeah. 

[00:26:52] Maarten Dalmijn: but we do need to make that transparency, and if we focus on the transparency like they’re doing, then I think you’re spot on. That’s the way to go. But I think that’s what makes it more difficult. It depends on your context-

[00:27:02] Janna Bastow: Yeah.

[00:27:02] Maarten Dalmijn: … your product. And I also didn’t answer that question intentionally in my presentation, but I think yeah, that, that’s the key thing. depends on your context, what value means and how you can capture that value for the business.

[00:27:13] Janna Bastow: Yeah, absolutely. I this is why, here at ProdPad, we’re such a big fan of what we call the completed roadmap, or I’ve called the validation roadmap this concept that the roadmap isn’t just this forward thinking thing, but actually once you finish something, you move it over to a space where you can say, here’s what we have done in the past. And it’s not just the things that were completed successfully, it’s the things that you tried and even failed on.

So got this running history of the problems that you tried to solve and what came out of it. it’s a little bit like math class where you still get half the points you’re trying, right? So you can say, hey, we spent a quarter trying to fix engagement and we did all these things and it got worse. but hey, now we know how not to do that. So we spent the next quarter doing all these things and actually got better. And so now you’ve got this running history of things that works and don’t work, and, your team learns from that. You get better from doing this process as opposed to just throwing things at the wall and-

[00:28:04] Maarten Dalmijn: [laughs].

[00:28:04] Janna Bastow: … building features that you never roll back. And-

[00:28:07] Maarten Dalmijn: For you never afford a plan. [laughs].

[00:28:08] Janna Bastow: Yeah. exactly that, Exactly that. we’ve got some good questions coming in here from, people in the, in the Q&A. let me get some of those out there. Um, Steven asked, he said, “I think the inclusion of military learning is a fascinating comparison. Militaries have been transforming the processes constantly of the years the technologies come in. Much like product managers. Do you have other examples of applicable comparisons?”

[00:28:30] Maarten Dalmijn: Yeah. Yeah. So I think as well, I think it, it’s in the Marines they have the rule of three. So basically you, they cascade down, like you have a squad and then there are three team members, and it’s always three, three. And why is that? If it’s more than three, we cannot remember it. And I think this is also super important when you set goals, like the biggest challenge I see in organization, they have 100 goals, or, that doesn’t help.

Like you need to focus because people cannot remember more than three things. so that’s something the military does really well, like in their organizational structure, but as well, when they provide intents, it’s never more than three. McKinsey also does this, like three bullet points. yeah, this is not perfect, of course, it’s not exhaustive, but yeah. Do you want clarity or do you want exhaust? It’s not, you have to choose, I think. And, this is another example, I think.

[00:29:14] Janna Bastow: Yeah, really great. takeaways. Thank you. and also I think there’s so much we can learn from other industries about how we do our, how we do our work. I, wrapped my head around how kanban works by, somebody making a comparison to how it works with McDonald’s, like the fast food process- like why you wouldn’t make 15 more burgers and put 15 more patties on the, on the grill when you’ve got, a backlog of them. It’s “Oh, that’s why we have, whip limits.” 

[00:29:41] Maarten Dalmijn: another good example from Corona was supermarkets.

[00:29:43] Janna Bastow: Yeah.

[00:29:43] Maarten Dalmijn: I don’t know if they did it over there in the UK, but they limit the amount, limited the amount of shopping baskets to control how many people could come in. At least they did in the Netherlands.

[00:29:50] Janna Bastow: Yeah.

[00:29:51] Maarten Dalmijn: So there would just be 20 shopping baskets, and then if they’re empty, you’re not allowed to go in. That’s another example of a common system. [laughs].

[00:29:56] Janna Bastow: Oh, nice. Yeah. That’s really cool. Yeah, I love learning from, other industries and how it’s working, in the real world and how, it applies to our, to our digital kanban boards and our digital OKR systems and that sort of thing. Excellent. Very cool. Good question, Steven. Thank you. Chloe says, “Thanks for the presentation. What would be some examples or, examples of goals or intent at ProdPad for one quarter? the why and the what?” This might actually be a, question more for me. so I guess you’re asking about how this would work, within our own team. we’re a B2B SaaS company, so the way that, we think about things is in terms of, how we can get, more people signing up, more people sticking around for longer, reducing churn, increasing customer satisfaction. So we’ve got different goals that happen at, uh, different times. We work in sets, what we call tracks, which are six week cycles as opposed to, quarters, because we found quarters just too long. so what we do is we set our OKRs per track, and we also work in a similar way of the what and the why, right? at any point in time we’ll say, okay, so our goal is to, increase the, signup flow or increase the amount of people who get from, wanting to sign up to actually sign up so that we can, make sure that we’re maximizing, actual trials this quarter, this for this cohort.

[00:31:23] Maarten Dalmijn: [inaudible 00:43:10]. 

[00:31:23] Janna Bastow: Maarten, do you have any examples from, clients that you’ve worked with or, uh, companies that, times that you’ve done this sort of exercise?

[00:31:30] Maarten Dalmijn: Yeah, I think for example, when I worked at an e-commerce company, I think that it’s always a bit easier of course in that sense.

[00:31:35] Janna Bastow: Yeah. 

[00:31:36] Maarten Dalmijn: but when I worked at a SaaS company, we did a lot of things by making a North Star Framework model for our product and kind of discovering so maybe a bit of context, right? Because I’m just dropping a buzzword. basically in the North Star Framework, which you do is you try to make a, a North Star, which is a proxy for how your products delivers value.

In the case of, Spotify for example, it could be time spent listening to music- 

[00:32:00] Janna Bastow: Mm-hmm.

[00:32:00] Maarten Dalmijn: … which means it reflects those customer value, right? So if people are listening more, they are getting more value ’cause they’re enjoying the songs. But it also means that if you have more customers signing up, more people paying it can also increase. So it, it needs to reflect the totality. And then you create this whole constellation of inputs. So basically stuff that influences this North Star.

And then the assumption is if you influence these inputs, you will influence North Star and that will result in more money, for example. You can check that.

And I had a lot of success with that because basically you have a mental model for how your product delivers value and you can link that to your goals and then when you fill right, or you do something that doesn’t succeed, you will have more information for your next experiment. So yeah, I had a lot of success with do- doing that and I think that approach can be applied with all kinds of products.

[00:32:49] Janna Bastow: Yeah, absolutely. I to put that in context for our B2B SaaS, we have a North Star of maximizing usage from companies who’ve been with us for 12 months or more.

[00:32:58] Maarten Dalmijn: Yeah.

[00:32:58] Janna Bastow: So put it this way, it’s one thing to get a client to sign up for one month, and it’s okay, good job, pat on the back. But oftentimes people are just experimenting for the first month, right? They’re, haven’t wrapped their head around it, they haven’t got all the integrations going and that sort of thing. It’s something else to get them signed up for, to keep their card in and keep using it for three months, six months.

But 12 months is a really big milestone at that point in time. It’s okay, they’re now embedded. They’ve got their team using it, they’re increasing usage. and so that’s when we really celebrate. And in order to get somebody to, keep using it for a year, you don’t, it’s not just about impressing them from, the landing page and the initial onboarding emails and the first demo.

[00:33:35] Maarten Dalmijn: Mm-hmm.

[00:33:36] Janna Bastow: It’s beyond that honeymoon period, right? You’ve gotta build a really great product. and so we’ve got the whole team thinking of ways that they can, build a great onboarding, but also build a great post-sales experience. Build a great post sales experience that lasts for and months and months and just, making sure that the app is secure and stable and, building for feature, building features that help support, product managers who are using it, who are getting increasingly adept at using it, more advanced customers, still making sure that we’re onboarding new customers.

So we have this North Star that helps us, focus not just on getting new customers, but making sure that we’re keeping the old, which has been a really healthy goal for us. So I really like the idea of having a North Star and then everything cascading from that. And that’s what the OKRs, system classically helps to do. somebody, anonymously asked, [laughs], “Now-Next-Later, is indeed the best way for a product manager to describe the steps in the plan and del- and, and, deliver value. However, working with stakeholders outside product requires talking about timelines and setting clear expectations, which is usually done via a Gantt chart type roadmap. How do you approach this need?” 

[00:34:53] Maarten Dalmijn: I think it’s very important to engage in a dialogue. Like, why do they have this need? Where does this come from? And start talking about, this whole presentation was basically about that, why it isn’t possible, right? And I think you have to take them along this journey. that’s the, we, you cannot provide that certainty. It’s let’s say you have a wedding one year from now. Somebody ask, are you, can you pre- predict when a hundred percent confidence it’s gonna rain? No, you can’t, right? So you always need to have a plan B.

And I think that’s the same thing here, and I think it’s important to talk about that. And of course, what I do agree with is if you are working in an organization, they’re expecting this scan, check with timelines immediately, like removing the timeline completed of the equation may be difficult. What you can do is, for example, start with a Now-Next-Later roadmap, and that you have a forecast for everything. And now, and then in next, maybe you have a quarter.

And that’s then a way to slowly nudge away from the Gantt chart. yeah, I always say you have to meet them where they are, right? But you also need to get ’em slightly out of their comfort zone. But of course, you don’t want them to panic. So this is, I think, a good, 

[00:35:54] Janna Bastow: Yeah.

[00:35:55] Maarten Dalmijn: … between situation.

[00:35:56] Janna Bastow: Exactly that I call that, weaning them off the timeline roadmap, sometimes you’ll see people with this quarter, next quarter, Q3 plus sort of thing in the roadmap, or just, in the now using dates here and there. And the reality is, one thing that’s really important to point out is that just because you’re using Now-Next-Later does not mean that you can’t have dates on your roadmap.

[00:36:15] Maarten Dalmijn: Correct.

[00:36:16] Janna Bastow: A lot of people think that Now-Next-Later means no dates ever, no deadlines ever. And we don’t live in lala land.

[00:36:22] Maarten Dalmijn: [laughs].

[00:36:22] Janna Bastow: If something has important dates that you need to communicate, then communicate them. But what you’re doing is, instead of having a timeline at the top of your roadmap, that means that everything underneath it has a due date just by where it’s placed on that roadmap. you can just put the date on the thing that has a date on it. So if there’s a regulatory due date that’s coming up, if there’s a hard date that’s tied to, a conference or a, a Christmas rush or whatever is important in your industry, you’ve gotta hit that. then include that on the roadmap. So you can communicate that in, loud letters in, add an emoji, add some images, add something to make sure people can see it, but don’t penalize yourself by adding dates to everything, just by having a format of roadmap that shows it like that.

People just assume that they should have a timeline roadmap, because that’s what people think roadmaps look like. But if you actually take away that and say, what we’re trying to do is understand what we’re spending our resources on and when, then a Now-Next-Later roadmap does that, it tells you the order in which you’re tackling things, how big each thing is, relatively speaking.

You’re putting as much information as you have for each one, why you’re doing each one. What sort of things are you gonna tackle as part of each one? if you have that much information, and if there are dates, if there are dependencies, if there are milestones, you’re putting that on each card, each area of the roadmap as appropriate, but you’re not putting in anything that you’re making up, which unfortunately with any timeline roadmap, you’re making up something somewhere. [laughs].

[00:37:51] Maarten Dalmijn: Yeah, absolutely. And I also think this really helps because problem is you always have cascading delays, right? So if you put a date on stuff you’re working on now, and then that’s delayed, everything that comes off there is also delayed. But in the-

[00:38:02] Janna Bastow: Yeah.

[00:38:02] Maarten Dalmijn: … again chart, you’re screwed from day one-

[00:38:04] Janna Bastow: Yeah.

[00:38:04] Maarten Dalmijn: … you’re gonna be set up for failure and everybody’s gonna be like, you’re late. You filled, even though it was maybe even only the first item that was delayed.

[00:38:13] Janna Bastow: Yeah, absolutely. Now, the other thing is, when moving away from a timeline roadmap, there might be different people who, get upset for different reasons, right? Like I said, it’s a comfort blanket. Some people are used to seeing the timeline roadmap. they like seeing it that way. Some people, it might be investors, it might be, customers, it might be, salespeople and marketing people. They all have different reasons why they might have been comfortable with that old version. but I can tell you that there are ways to handle their objections and to work with them and work them around to using the Now-Next-Later. I’m not gonna go into those specifically unless somebody has a particular stakeholder that they wanna talk about. I’m almost happy to talk about this in lots of detail, but I will share a guide that I’ve written, in the chat here, which is a, it’s a six page guide. And the last page is, literally about how to deal with tricky stakeholders and how to get them on board with the Now-Next-Later roadmap. William asked a good question here. how, as you say, it’s considering companies that are still doing annual planning, I think this might be similar to the last question. How have you influenced leadership to change from features delivered by end of years to goals achieved by end of year? I think this is a great question.

[00:39:28] Maarten Dalmijn: Yeah. So what I think is really important is when you’re doing timeline roadmaps, it probably also means, usually in my experience at least, there’s not a lot of discovery happening. It’s a lot of, like somebody says we have to do something, so we do it. So that means you’ve got a treasure trove of stuff that isn’t working usually. I think by starting with something like the North Star Framework, you can actually show like, “Hey, we did these things. They didn’t make an impact.”

And then you can start doing small things, small experiments where you show actually, hey, this big project where you six min- six worked six months on didn’t make any impact. But here we did some small things because you actually focused on certain results, and then you can shift away the conversation like, “Hey, like maybe we should be doing this more.” that’s how I had great success, because the problem is, big changes are always difficult to sell, but if you show and lead by example and show them like, hey, we could be doing more of this. then they suddenly start saying, hey, like they’re delivering nice results, then maybe let’s do it more. I think that’s a really good way. I don’t believe in practical change is very difficult. It can happen, right? Like that you’re like, you’re an amazing at influencing, you can just flip the switch.

But I’ve had the best results with nudging them away or weaning as you, yeah, I think that’s more realistic, especially if you’re not like a magician, influencing people. Like, I’m not a magician. That’s what I’m trying to say. [laughs].

[00:40:50] Janna Bastow: [laughs]. Yeah. And you know what? I think you’re absolutely right. one of the things that, I always like to do is, try to get down to the why. Like, why are they attached to that way of working? What is it that they are, trying to do? is it that they assume that if you write out this list of features, then it will magically be done?

‘Cause again, you’re not a magician. and they should be able to see that, past results, you made a roadmap last year and you weren’t able to deliver it all for reasons. and they shouldn’t assume that if you made this roadmap this year, it’s just gonna magically deliver because things happen, right? Like things do disrupt timelines. And so leadership, what’s their role? their role is to try to get the best ROI, ROI out of the team, right? their goal is not to just build a whole bunch of features. So if they’re trying to get the best return on investment out of the team, and, improve the prospects of the business, then you can show them how you can best help them do that by being goal-driven. point out that by, if they’re asking you to work in this project mindset, spending all this time planning stuff, show them that you’re having to add buffer just to make up for this way of working, show them that it’s slowing you down.

It’s adding in, extra time. It’s making things, more difficult to build. it means that you’re not having time to do rework. So there’s more tech debt. know-

[00:42:16] Maarten Dalmijn: Developers are miserable. [laughs]. They don’t like it.

[00:42:18] Janna Bastow: Developers are miserable. [laughs]. Yeah. There’s, there’s so many downfalls, right? point out all these things that aren’t going, that aren’t gonna work in their favor and how it’s not good for business, 

[00:42:28] Maarten Dalmijn: That’s right.

[00:42:28] Janna Bastow: … and point out the risk that they’re putting the business in, right? Because they speak in terms of risk and reward, right? Like they’ve got a, possibly a portfolio, a team, a series of teams, and they want their teams to do well. And if you’re saying, “Hey, you’re putting your investment at risk, you’re putting your, your career at risk, you’re putting your name at risk. If your teams do not perform well, here’s how we can perform better.” And it’s not like you’re the first team to do this, right? There are lots of case studies out there, companies who have moved to leaner ways of working, who move to experimentation ways of working and outperform others who work in this IT mindset, IT project mindset. And you’re not asking to reinvent the wheel. You’re asking to work in a known way that, known, proven way that is likely to result in better results.

[00:43:17] Maarten Dalmijn: Absolutely It just does offer the same comfort, for many. That’s the biggest, I think. Yeah, sure.

[00:43:22] Janna Bastow: Yeah. It’s uncomfortable. Most of the time they’re not doing it outta spite, So it’s just a, it’s an uncomfortable conversation, but, usually not a, an impossible one. not to say never, though I do understand that sometimes it just becomes impossible. And I do get that and I empathize with folks in that situation. Justin’s asked a good one here. “How would you translate this into writing key results? How do you quantify these types of goals?”

[00:43:44] Maarten Dalmijn: Yeah, so basically if we’re talking about OKRs, right? You have the objectives. So it’s kind of like answer, like, what are we trying to achieve and why does it matter? But how do you make it tangible, right? And those are like the steps, the things, for example, in the North Star Framework, like the kind of stuff we’re trying to influence, like what are the outputs that drive certain outcomes? What are the experiments we’re gonna do? I think that’s what kind of should be in the key results.

Like, we’re trying to influence these outcomes and we expect them to achieve this. yeah, I think that that’s, how should be done. What is your, how do you do it? Because maybe I that’s similar. [laughs]. 

[00:44:16] Janna Bastow: yeah, key results is more of an art than a science. it’s the type of thing that, we encourage everybody in the team to take a stab at. And it’s not about getting it perfect, it’s about setting a, a goal, something that you can measure by-

[00:44:29] Maarten Dalmijn: Yeah.

[00:44:29] Janna Bastow: … and so that you can report back on and say, hey, this is what we thought we could change. This is how we were able to report on it, and this is, what we actually got out of it. And as long as they’re, as long as the objective is directionally right-

[00:44:45] Maarten Dalmijn: Yeah.

[00:44:45] Janna Bastow: … then as to how much they’ve set the key results, as long as they’re not going wildly like way too small.

[00:44:51] Maarten Dalmijn: Yeah.

[00:44:51] Janna Bastow: And you should have a gut feel for that, and they’re not going wildly way over the top, and they should have gut feel for that. And even if they do get it wrong, you’ll get it right within the next couple quarters, what you’re actually doing is like you’re setting the, the axis as to what they’re gonna be measuring it by. So you say, oh, we think we can do this. And then over the course of the quarter, you see the numbers creep up, and at the end of the quarter, you created yourself a nice bounding box for the chart that you’re gonna report on saying, this is what we did. that’s really all it is, right? Takes the pressure off. It’s not, you’re not trying to come up with this perfect number. You’re just saying this is the bounding box of what we’re gonna measure. and you know that the KR is directionally right, because it sets to the objective and you should be able to say, if we were to do this key result, then I can reasonably say that it would help us hit this objective.

[00:45:34] Maarten Dalmijn: Yeah.

[00:45:34] Janna Bastow: And you should be able to read back your key results and say, yes, we did all these things. And therefore objective is-

[00:45:40] Maarten Dalmijn: Yeah.

[00:45:40] Janna Bastow: … likely met. All right. And we have, a, deeper one here. somebody said, “There’s product and there’s Now-Next-Later planning, but the bigger picture of complexities that product decisions operate within power structures that shape company’s social factors, the stakeholder and user needs change. New solutions often emerge along the way.

The next is always in flux in pretending that it isn’t, feels a little bit like self-deception. Can you have humble planning that accepts and embraces these political social factors?”

[00:46:17] Maarten Dalmijn: Okay. I wanted to make sure I understand the question because-

[00:46:19] Janna Bastow: Yeah.

[00:46:19] Maarten Dalmijn: … the way I read it, and it’s gonna be wrong, is basically, stuff emerges and that’s the case. That’s exactly what I believe humble planning is good for. It’s about like allowing this emergence, it’s about not making plans that you assume you know everything. It’s about you’re gonna like the way I call it every step you take shapes the way, and I think you’re actually embracing it.

And what I do agree, right, is that if you are in the next and you don’t change it and you’re not learning stuff, so you’re, yeah, then it’s sells deception. But there’s exactly why, like humble planning means you can change your plans, you can change what’s next. You can change what is now like, the most important thing is are we mo- making the most progress towards what we’re trying to achieve?

[00:47:02] Janna Bastow: Yeah.

[00:47:03] Maarten Dalmijn: That’s leading. And the plan is up for anything can change as long as it helps us meet their goals. 

[00:47:09] Janna Bastow: Yeah. Perfect. I like that, that quote, every step you take shapes the way.

[00:47:13] Maarten Dalmijn: Yeah. 

[00:47:13] Janna Bastow: I like to see product management a or road mapping as, like this new shore you’ve stepped on, and you’ve gotta make your way to this distant mountain in the distance. And the best teams are the ones who work together to say, here’s what I can see now, and here’s what we think are the next steps. and as they take each step, they regroup to say, okay, we just did, and here’s what we think is the next best thing. they remap their path together to find the best route forwards. And there is no one right path, but the best paths are the one, the best paths are found by the teams who actually work together to find that path. I like to take some of the pressure off the roadmap by thinking of it as a prototype-

[00:47:51] Maarten Dalmijn: Mm-hmm.

[00:47:51] Janna Bastow: … right? It’s not this perfect plan, but it’s a prototype that is outlining, it’s just laying out your assumptions. And as your assumptions change, as you check them, as they get closer, they shift. And so something in your next is just saying, “Hey, this is coming up next, but it’s unvalidated, right? We’re trying to validate it and that’s why it’s sitting right there so we can validate it next.”

And if, you get closer to it and you realize, oh, that’s no longer a problem, or, oh, that’s a bigger problem than we thought, or, oh, we need to switch the order of those problems. Cool. Switch ’em. Like now, really good thing that you laid them out so people could see them and decide what to do with them as you got close to them.

[00:48:25] Maarten Dalmijn: It also be something you’re working on and now is so much more valuable than anticipated. You just push back, “Hey, we found something. It’s really working, we’re gonna double down on this,” right? So-

[00:48:34] Janna Bastow: Yeah.

[00:48:34] Maarten Dalmijn: Yeah. Opportunistic, like that, I think that’s important. if you discover-

[00:48:38] Janna Bastow: Yeah.

[00:48:38] Maarten Dalmijn: … what you’re doing is more valuable, anticipated, you should be opportunistic, you should not be like following the plan because-

[00:48:44] Janna Bastow: Yeah.

[00:48:44] Maarten Dalmijn: … we promised something. No. if this is really having a big impact on retention and we’re making a lot of money, let’s do more of it.

[00:48:50] Janna Bastow: Yeah, absolutely. we are just about out of time.

[00:48:54] Maarten Dalmijn: Yeah.

[00:48:54] Janna Bastow: We might have, time for, one more, question, which is how do you define a quantifiable objective? 

[00:49:00] Maarten Dalmijn: This, one to be honest, is difficult to answer because 

[00:49:02] Janna Bastow: Yeah.

[00:49:03] Maarten Dalmijn: … connectivity incl- it is very like, general, like configurability in what sense? I we talking about configurability of a computer system, of the admin interface? I don’t know, like I, me, yeah, I have, I mean, I dunno if Elliot Nora can elaborate, but I dunno time for that. But it’s difficult to answer, to be. I then I’m just gonna answer a two hypothetical question to be honest.

[00:49:25] Janna Bastow: So I think we’re down to the right answer for, in product management, which is, it depends on the context of what it is that you’re trying to, answer, or what you’re trying to make a, quantifiable. it depends on the context and, sorry, won’t be able to have a clear answer on that. But, yeah. good question. and thank you so much for ask, answering the questions that, we’ve tackled, today.

[00:49:44] Maarten Dalmijn: Okay. 

[00:49:45] Janna Bastow: I’m just gonna get the, screen back up here again. because I wanna say a big thank you to, Maarten for, jumping in for his, presentation and his questions today. Thank you for taking the time to chat with us today. 

[00:49:57] Maarten Dalmijn: Thank you very much.

[00:49:59] Janna Bastow: Take care. Bye for now.