We’re two years into the pandemic by now, and things have changed forever. One of those is the way we build products. Not just team-work wise, but product ownership has changed just as much.

Kai Stevens is one of the most awesome Product Owners/Product Managers that I know, so I decided to ask him to come on the show and talk about what he feels has changed and how deals with these changes.

 What you’ll discover in this show:

–        The pandemic has provided opportunities, for instance by deleting location restrictions
–        Due to missing body language, new ways of stakeholder engagement are needed
–        OKRs are still highly useful and might even provide more guidance than ever before

Speakers:

Kai Stevens
Group Product Manager Device Experience at tado° || Product Leadership || Product Owner Trainer at Scrum Facilitators

Passionate product owner driven to build game changing (software) products together with inspiring people. Guiding and collaborating closely with leadership teams and multi disciplinary development teams to maximise value. I am experienced in all aspects of product ownership ranging from vision and strategy all the way down to the tactics. Colleagues find me pushing the limits to release early and often to validate assumptions and deliver value in rapid pace. When working with me you will experience a compelling WHY at anytime while I leave the HOW to others with clear boundaries to become successful.

Besides my work as a product owner I also co-train Scrum.org’s Professional Scrum Product Owner and Professional Scrum Product Owner Advanced classes at Scrum Facilitators. During these courses my real and recent experiences as a product owner add value by connecting the course theory to real stories from the trenches.

Contact Kai:
Linkedin: https://www.linkedin.com/in/kaistevens/

Sander Dur (host)

Scrum Master, Agile Coach, trainer, and podcast host for ‘Mastering Agility”

Sander Dur is a Professional Scrum Trainer at Scrum.org, podcast host of Mastering Agility, Professional Scrum Master and Lead Agile Consultant and trainer at Xebia. Besides this, he’s an avid writer for predominantly Serious Scrum on Medium.com. Sander has a major passion for the human side in complex domains. Ensuring a high level of psychological safety therefore is a critical part of his work. Organizations in complex domains can only survive when innovating. Innovation can only take place with the right balance between low social friction and high intellectual friction. While most organizations now understand how to apply Agile frameworks, they struggle with delivery of value. Psychological safety is the next step in this evolution and Sander has a huge drive to help organizations reach that step.

He gained experience as a Scrum Master, Agile Coach, and Leadership consultant in many different top-tier organizations, including Nike and ASML.

 Sander is enthusiastic, open-minded, and ambitious. He finds interpersonal relationships and intrinsic motivations very important in team dynamics. Besides his work, Sander loves to spend time with his family, enjoys sports and eating healthy, barbecuing, riding his motorcycle, and traveling.

Let’s connect! Sander is always up for new connections and discussions!

Masteringagility.org
https://www.linkedin.com/in/sanderdur/
https://xebia.com/academy/nl/trainers/sander-dur
https://sander-dur.medium.com/ 

Additional resources: 

PSPO-A by Kai: https://www.scrumfacilitators.nl/etn/pspo-a-19-20-may-2022/

Mastering Agility events: https://www.meetup.com/mastering-agility/

Discord community:https://discord.gg/6YJamBJxUV

00:00:00
Intro

00:01:17
Welcoming Kai

00:03:17
The impact of the pandemic

00:09:22
Missing body language

00:18:13
What if the CEO doesn’t like it?

00:27:17
OKRs

00:39:14
Product Goals

00:42:14
The difference between PO and PM

00:51:51
Outro

SUMMARY KEYWORDS

product, scrum, people, sprint, organization, team, data, product owner, pandemic, dependencies, formats, roadmaps, work, goal, stakeholders, hardware, review, product development, remote, product manager

SPEAKERS

Kai Stevens, Sander Dur

Sander Dur  00:00

All right. Finally, we’re back with an all new episode of the mastering agility podcast series. Unfortunately, sometimes you have these periods of where you’re just not in the right mental space to create new content. And unfortunately, that happened to me too. A lot was going on, finally became a professional Scrum, Scrum, the dog trainer, PST. A lot of other things were going on. Finally, we’re back with new all new episode of this podcast series that aims to inspire you and others by bringing in the best of the business into this show. As always, my request to go to the website of mastering agility.org subscribe to the newsletter, or join the discord community server. Link in the description in the show notes. And I’d love to see are there already a lot of people who joined Thank you very much for doing doing so. I would love to see this community build more and more. Now, as for today’s show, I’m talking to Kai Stevens, I think he’s one of the most outstanding product owners out there. And we’re talking about how to be product owner and remote and hybrid environments. Things have been challenging, and now we’re at the end roughly, of the pandemic, but how are we going to continue doing so? And what what kind of tricks? Does chi know that can help you be a product owner in this challenging environment? Hope you learn as much from him as I did. This welcome Kai. Kai Stevens, thank you very much for joining us today. How are you doing?

Kai Stevens  01:37

Hi Sander, thanks for having me on your podcast. It’s an honor. I’m doing great. It’s exciting times at Tado where I where I work. Yeah, so doing great, thanks.

Sander Dur  01:48

What makes it so exciting at Tado?

Kai Stevens  01:54

Yeah, maybe to give a short introduction for people who are not familiar with, with Tado, we are a smart thermostat. Throughout the whole of Europe, our products are offered. And we intend to allow everyone to enjoy smart heating and cooling. So that’s Tado started now 10 years ago, so the company now exists for for 10 years. And as our ambition also with all the developments in the energy energy markets today with the electrification of of heat, for example, to play an even more central role role in a home’s energy management. So that’s, that’s what we’re working on. And yeah, I joined Tado three months ago, four months ago in October. And I think exactly at the moments where we now making the first steps towards, let’s say, beyond our current product lineup that’s aimed at heating a home with gas fired boilers more efficiently. And we’re now making the next step towards the electrified heating setup that you will see more and more in the market in the future.

Sander Dur  03:17

Is the remote environment making your job easier than because you’re working with the entire part of Europe? How’s this pandemic helped you move forward?

Kai Stevens  03:30

Well, I think the pandemic literally helped me move forwards. Because before the pandemic Tado, Tado was located in Munich, and I live in the south of the Netherlands near Maastricht. And before the pandemic Tado only worked with people who could work fiscally from the office in Munich. So before the pandemic, joining together would not even have been an option because I would live too far away. And even when I started to consider moving on to the next position, I didn’t consider approaching Tado. While it’s exactly the company I’d like to work for. Because I still had this thought in my mind, like, yeah, they’re in Munich, it’s too far away. And then, through a former colleague of mine, I was linked to my colleague Dominic, who’s the Head of Product Management at Tado. And he suggested hey shall we have a talk? And then I was still thinking because back then I was still working at my previous employer na goals. I thought, Oh, he wants to discuss some kind of partnership between Tado and Eneco. And I said, No, actually, I would like to discuss if you would be open to join our team, and I was like, but they are in Munich. I will work and then he shared that because of the pandemic they learned that working remotely, actually turned out to be working way better than they thought and had a lot of troubles finding talent in the Munich area. So the Tado decided that these for certain positions decided to, to open up for remote, fully remote work. So I think I should be thankful for the pandemic, in that sense, because before the pandemic, I mean, I can tell I remember conversations also with the previous employers about working one day from home, right, that was done. It was like, wow, it was really special if you are allowed to work one day from Home Instead of being five days at the office. And I think not only Tado, but many companies out there learned that the value of increasing your range where you can look for talent is way higher than requiring everyone to be at the office at at altos.

Sander Dur  05:47

Do you think there’s ever going to be changing back that we’re going back to the office full time?

Kai Stevens  05:57

No, I don’t think so. There might be companies but I think especially the the tech companies who really struggle also to find talent. I think for them the value of having this wider area to recruit within to find people in this is way bigger than going back to the value that being all together in the office building every day. Brings out obviously there’s also some some challenges when you fully work remote, right? So it’s not that it’s all better than when you’re physically at the office. But I just think that the scarcity of talent is a big reason to stick with this, this hybrid model.

Sander Dur  06:44

How’s this gives you? I think you’re when you’re one of the most highly regarded product owners, product managers, let’s let’s dig into that. That topic a little bit later, I think you’re one of the most highly regarded product owners that I personally know, has this affected your ability to deliver your job other than the geographical benefits?

Kai Stevens  07:09

Overall, I can’t say there is a difference, to be honest. So we have all the tools available to do the things you need to do as a product owner or product manager to maximize the value of your products. There is however things that you have to change in your ways of working right. So while I’m not in Munich, so I can’t jump into a room. And it’s really needed with some people and grab them together and say, hey, now we really have to figure this out. So that all works a little bit more difficult remotely. For example, if you can’t access your answer users physically to interact with them, you also have to find new ways to learn about the problems, right? That’s all a bit more difficult to get a screen in between, I would say. But after doing this now for, let’s say, almost three years, I can’t say it is. In the end is there’s a difference there. There are other things that have a way higher impact on your success than the question if you’re physically present at the office or working remotely.

Sander Dur  08:20

What do you consider those things? Because you say there are different things that are impacting your ability to succeed? What are those things to you? What does it mean?

Kai Stevens  08:33

I think that, let’s go back to the principles of how you can be successful as a product manager. For example, if you go to the Agile Manifesto, where you take customer collaboration over contract negotiation, how do you collaborate with the customer, if you can’t be physically together in a room, right? The Pitfall, for example, when you do a remote meeting, is that you have less interaction or that you have less creativity in that meeting with with a person that you tried to collaborate with. So you have to learn new tools and tricks and formats to make sure that that same level of Interaction and Creativity is present and in the digital room. So to sort of say,

Sander Dur  09:22

as the body language for instance, affected your ability to read the stakeholders needs. I mean, it’s good to listen to stakeholders. I mean, you should it’s also good to see their, their their body language. Read read the things that they’re not saying hasn’t. It hasn’t had an impact on your ability to let’s let’s stick to stakeholder management has it limited your ability to do that stakeholder management.

Kai Stevens  09:55

Yeah, recognize this right. So normally, you can read a person metaphysically Gotta is easier to read a person’s face or overall body language and then ask another question or plan a one on one because you notice that person is a bit jumpy or whatever. And some of these design state, they fade away in a remote, remote setup. So I think it’s even more important to set up moments. And also think of formats where you can neutralize that, right, that loss of information that the passive information that you would usually gets in the physical, physical world. That’s a matter of attention, right. So just making sure that you have this one on one with that stakeholder, but also about setting up more interactive formats in the in the meetings that you have, so that everyone is actually heard. So you could use liberating structures online, for example. You could use digital whiteboards, like euro and my row, where you visualize these emotions that might be inside of your stakeholders. So for example, in my early days, at Tado, we had to discover a certain new feature idea. And then I ran a workshop around the question, how can we possibly make this the biggest fuckup ever in Tado history? And that unlocked a lot of insights of what was going on in the minds of some people, right, and then we could discuss, okay, but how can we prevent that from happening? And then, rather soon, we came to a good, good plan of, or a good approach to tackle those, those concerns? Yeah.

Sander Dur  11:49

What other kinds of formats do you use to contain these kinds of things to unlock what what’s inside your stakeholders? Because this is one and I guess this comes from liberating structures as well. They think that’s a really interesting topic that a lot of a lot of listeners would benefit from, like, what what other formats do you use?

Kai Stevens  12:14

To be honest, it’s not, it’s not really, besides celebrating structures, it’s more about, it’s hard to explain, having a sense for when you should make that interaction happen. And then in my experience, it doesn’t, the format doesn’t matter too much anymore, as long as you take a format that makes these things surface. So it can be a brainstorm, it can be a liberating structure that you use, for example, I would always recommend in such a session to use breakout rooms, because you always have a few people who don’t speak up in the in the bigger group, right. So just think of formats that depending on your audience, make sure that everyone shares their Yeah, their input their ideas, and also their their concerns,

Sander Dur  13:07

the actively and try to engage those who are less as vocal, because it’s what I noticed, personally, that’s really easy. Gradually, it becomes more accepted in a lot of organizations that I that I encounter, that your camera’s shot is shut off, it’s off during the meetings. And that makes it even harder to read. But people are thinking about how people are feeling, let alone the fact that it’s a lot more easy to get burned out. Because people don’t signal it’s mean. I mean, it’s, let’s say you have a shitty day, and you just have your camera off. As always, no one can see that, if you’re physically in the office is really easy to see. And it’s harder for people to wish that way. Now, people just close their lids of their laptops and they could start crying for for all we know, we don’t know, because we can see that. How do you actively engage people that are less vocal?

Kai Stevens  14:10

Well, like I just said by by breaking up in smaller groups, so that already lowers the barrier for them to, to speak up, sometimes by approaching them one on one right? To really create a small, small setting to where to discuss things. And also by asking specific questions, right? So if you ask a very general question to a person, you can get a very general answer. But if you ask like specific questions like a which of these three features, do you now like more? Or what do you think we could do to make this a 10? Out of a nine? So try to ask more specific questions. I mean, you’ll also get more specific answers. Is my experience.

Sander Dur  14:54

Make sense? The sprint reviews are usually already challenging in person Let’s say you have a physical product, you want to put that in the hands of the customer, and see what happens as much as possible. A B testing, for instance, is a lot easier when it’s actually in the hands of the customer. How has this remote working think affected your ability or your team’s ability to check those things out?

Kai Stevens  15:23

Yeah, so maybe it’s better to refer back at my last time at na ko here, because at Daddo, we are a little bit differently. We’re not following a exact scrum process with the sprint review. But we have weekly iterations with really small internal team reviews. And then there’s more periodical review where we exchange with divided organization. What I’m going to say also accounts for a situation of Tado. But I think the example of inequity is a little bit more clear where we really at these remote sprint reviews, but with many stakeholders from the business presence. And when we just switched, we’re just have switched to remote working, we of course, easily set up a remote remote sprint review. But after two or three reviews, we noticed that we were Amelie presenting slide decks because that was what felt most comfortable to most people in a remote setup was like, Okay, I share my screen, I saw some slides and I tell my I tell my story we had 16 sharing their their sprint results, right? So it was six times a slide deck of, of 30 minutes death by PowerPoint. No. And of course, we tried this with parallel tracks so that stakeholders they didn’t have a sprint review of three hours, etc. But even with that we saw that we were losing the attention of of the participants because we were just submitting data to them without much, much interaction. And what we did then is we tried to spice it up, right, I also wrote a blog about about this. You can run a quiz, for example. So you can activate the brain. So I think the best thing to do in a remote sprint review is to actually make the brains of your participants work instead of make your own brains work, right? So start to start with a poll and they will be hooked up to the topic, right? Because you you activate their brains, they start thinking, How would this be for example, you might ask some kind of statistic, like in the terms of a smart thermostat, you might ask how many cubic meters of gas that we saved last month that you can show for four numbers on the in the poll, right? These kinds of things they can they can engage your audience with with your sprint, sprint review. When there’s like an important milestone, I like to do run a more elaborate quiz. So I could really use a quiz, using Mentimeter, for example, or cowards, and then do a quiz and give some prizes away. There’s a lot of things actually, that you can do to have a different kind of Sprint Review than just sending a slides. It just requires some courage and some time, right? Because you need to experiment with these formats. Especially when there’s important stakeholders there, like the CEO is coming into the room. Some people are afraid to actually try things out, right? And I would advise, don’t be afraid. Just try it. And if you’re working in a good organization that CEO should appreciate or will appreciate that you put in efforts and try new ways to get more value out of of such a events.

Sander Dur  18:48

I think people are very reluctant to have that in general. Because of fear. Like what if it’s not? What if he doesn’t like it? What if the CEO doesn’t like it? Then what? What’s the worst thing that has ever happened to you in such a case?

Kai Stevens  19:04

You mean when it didn’t work out? Yeah. Nothing ever happens. Then was like, oh, yeah, next time we try something else. What happens? Yeah, maybe you sometimes with maybe sometimes you ask for some input. And again, zero response. Right. So you you’re all set up depends on the investment of your audience, and making that event a success. And sometimes, yeah, somehow it didn’t resonate, or maybe they were just tired or, and then when that interaction doesn’t happen, but all format is aimed at that, at that way of interacting with each other. Either you notice that the engine starts to like rattle and in hindsight, you’re like, Okay, this didn’t work out really, really well. In the end, you shouldn’t be too are harsh on yourself here, I think, even if you got some value out of it, even if it’s just learning, oh, this formula doesn’t work with this, this audience or oh, this format could work better this in this way, that’s also value that you get out of the session and you try something else next, next time,

Sander Dur  20:19

you feel, or you seem to be really open and very curious to experiment with this. I can also imagine that you have teams who are less willing to do so how can you get people into such a flow of experimentation being vulnerable, because this has a lot to do with being vulnerable, vulnerable as well, which I really appreciate about you. I mean, if I look at your LinkedIn, for instance, and the way that we communicated in the past on Syria, Scrum slack, when it comes to writing, you’re really open, really vulnerable, but can still be a difficult thing. How do you get your team members engaged to to display the same level of vulnerability?

Kai Stevens  21:03

I think it starts with displaying that vulnerability yourself in the organization or towards your your teams, right? Lead by example, show that you try something and show that you also try some things that didn’t work and show that nothing, nothing happens when it doesn’t work, right. So when people see that they might get the confidence that they that they should also try try out something. Or you can also help them by slicing down the steps towards towards these more interactive ways of providing a sprint review, for example, by suggesting something small. So for example, what we did the times at the enago was like, have you noticed that? Some, some team members were less comfortable with a organizing request or whatever. And we encourage them to at least after three or four slides, put in a poll, right and ask a question to the audience. And that was the first step towards more interaction. And then they saw that there was excitement, or that there was a positive response from the participant saying that they actually liked this and other oh, maybe we can do three questions next time. And that way, you can make it a bit safer to them to to experiment, because you make the experiment a bit. A bit smaller.

Sander Dur  22:24

Yeah. There is a misconception there, at least, every view is different from a demo, and those which are in underpinning here as well. A demo is just sending information, right? It’s one dimensional, whereas what you did with enago is two way communication. It’s really getting the feedback and talking to people that reading your emotions getting their their ideas, is that you mentioned that you’re not doing that with Dotto. That’s more into the pragmatism, I guess, how is that different from and from? To explain

Kai Stevens  23:00

a bit. So this is happening within thought. But we are not following the scrum framework within Daddo. It’s it’s even shorter cycles, I would say so, it within Tado. We don’t have a sprint review where this happens, but it happens when that happens. So I would say we have many sprint reviews and many moments where there is a conversation around Hey, what should we do next? And and what what should that entail? What should be inside of the thing that we’re that you’re building, and then there’s a constant dialogue with sales, customer support, and all these crucial departments to make a new products work. It’s old enough to do too. Well Scrum, Scrum, red and the scrum framework. We didn’t put in title.

Sander Dur  24:00

Now. So you’re basically doing the exact same thing as what Scrum is telling you except in a different chronological order. It’s not necessarily at the end of the sprint but just continuously throughout. Yeah, yeah.

Kai Stevens  24:13

So our roadmaps, for example, sometimes don’t even use roadmaps anymore, because we changing so often that roadmap is always outdated. So then there was no value in the roadmap. So we threw it away. Within the group that’s that I’m responsible for we develop hardware products, those have a bit more lengthy timelines because it’s hardware. So there we still have F roadmaps. But I would say that it was an organization that’s that’s so closely designed to break upon the Agile principles that went beyond Scrum and actually scrambled with actually slows down if you look at the maturity of the organization, in terms of agility and competence. So, of course, I’m also a scrum trainer at scrum facilitators where I teach people how to use Scrum as a product owner. And I always say Scrum is absolutely your best friend to get to know agility, and also to go pretty far on that, on that journey, but at some points and for some types of products, like very complex smart home products, like don’t back in the days when I worked there and Daddo being a consumer electronics hardware product with very intelligent software behind it is current process can be can be slowing you down. So you should always assess the nature of your organization is Scrum is a framework that actually is the best fits to your organization or not. And again, at Tado we work in one big cycle, so you could call it a one week sprints. We have a planning, you have, we have retrospectives. So so many elements of Scrum, get back, we just don’t call it as is. And I think the most important ingredient in our product development organization, that Tado is that we work in truly autonomous cross functional teams. So that means that every product team is responsible for a specific product or part of the product, and can deliver their their value independently from other other teams. So that also enables us to apply lightweight processes, because there’s very little alignment in the daily work needed between individual product teams and other product teams.

Sander Dur  26:45

Yeah, a couple of hooks, because I think this is a really interesting direction. How going back to those roadmaps, how do you ensure them or ensure relatively ensure that you’re still somewhere aligned with their product goal? I mean, the people are that they work with typically already struggle on the longer term. How should how does that relate to our protocols? And how does the future look like? If you’re not working with roadmaps anymore? How do you work them?

Kai Stevens  27:17

Yeah, so we’re using OPR as at Tado. So we have company OPR, set up from the company vision. And then we have what we call Product Development Organization OKRs. That bring focus to all the product development teams within within Tado. And the interesting thing to mention here is that they provide focus. So for example, at this point, we have to objective key results for the whole product development organization. While there’s way more going on in the product development organization, but top down, there’s three things of which management has said these two things are the most important things to achieve. And they bring guidance, but leaves still a lot of room for autonomy in the themes on how to maximize, maximize value. And there’s some things we still have problems because they have value because we talk about somewhat longer timelines to be able to release something if you have to develop hardware, you are always talking about months of development before you can really release a product into the hands of your of your customer. Of course, we try to make them more agile by iterating and working with prototypes, etc. But the real release that it always takes takes rather long. But more on the Tado app side of things. For example, we noticed that the insights of how to maximize value change so often based on developments in the business, changes in the marketplace new feedback coming in from enthuses that this roadmap only cause confusion because we’re all very busy explaining like, oh, no, no, no change again. So the roadmap, I think transformed more into a storyline of what is the mission of this team? And what are the anticipated most valuable next steps for this team. And because we know that the further you go in time, it will change again, we don’t reflect any more in a timeline, a roadmap, a sequence of things. But there’s always every team as starting from the product vision, a sensible story of what are sensible next steps. And then we continuously validate validate these IDs, right? So we continuously run product discovery. And then based on that discovery, this plan changes again, and we update each other on that plan by by just simply sharing that.

Sander Dur  29:43

That’s pretty awesome, man. That’s cool to hear it like the book related to OKRs measurable matters by John Doerr. So anyone listening to this and thinks this sounds really cool. I can highly recommend this book and I’ll include it in the show notes as well. But this is something where I’ve really gotten hooked into the OCR parts, which indeed would you say, are different from roadmaps but make it really tangible to still strive for a goal and what, what, how to get there. A little while ago, we had your an upload in the show, talking about Floki. RS OKRs with flow was a really interesting discussion as well. So if you want to know more, read the book, as well as listen to that episode. It seems to me what like what you were just describing that you’re not specifically using Scrum. You focus on the state of the thing first, that’s most important, does scrum fit within our organization? I think that’s already escaped. Many organizations, a step that many organizations skip, like, what’s the problem that we’re trying to solve? And does scrum really fit into that issue into the complex issue with adaptive solutions? But also, if I hear you correctly, you’ve tried scrum Dido has tried scrum as is and then evolves from that point on, is that correct?

Kai Stevens  31:10

I’m not sure if that will ever really tried Scrum, to be honest, that that would have been before my times. And I would have to ask, I never discussed that before. So when I arrived, in October, we just launched a new product development organization with a cross functional team. So that’s something that’s that’s very recently improved in the organization. So I, I don’t know if if we ever use Scrum, or tried something else, or had this this Tado kind of process in place already. Before that, what I do know is that some time ago, these cross functional teams were not yet in place. So there were many more dependencies between teams and more silos, right. So you had like, embedded engineers who worked in a embedded engineering team, for example, or you had all the hardware engineers that worked in the hardware team. So then people came to them and said, we need some new hardware for for this feature, or this thing that we want to bring to customers. And then they would list the requirements and build that hardware. And the significant changes that we now made is that those disciplines now work together on a dedicated product. So for example, we have a smart radiator valve. And in the we call it the room control team, because these radiator valves to give you easy control over a specific room in your home. And the room control team has all the disciplines, including a hardware developer, to to discover new new wishes from our end users, and translate that into a new hardware products that we can develop and bring to the to the market. So there’s a auto developer, but also a embedded developer. There’s, there’s a plastics engineer. But there’s of course, also a product designer and a product manager. These kinds of disciplines are all in the same team so that they can together think of this, this new product to to build.

Sander Dur  33:12

That’s pretty awesome. It’s a really, it’s a very different from organizations that you work with prior.

Kai Stevens  33:23

Well, I think at Qubee as a daughter company of Eneco, before we were merged into Eneco, we went through the same process, starting with components, teams, maybe before I joined QB in 2017, then transitioning to semi feature teams. But we still had a design team and mobile app team, for example. We were like dedicated teams just focusing on that. That skill set. And then at Qb, we transformed to the QB value three model, which was basically the same idea like like with all the disciplines needed to autonomously deliver a part of the value of the product. So that you reduce dependencies between teams, and that you simplify prioritization in your company. And I think that is the essential part of successful product organizations is that you simplify the alignment within the company by reducing these entity dependencies.

Sander Dur  34:29

Do you visualize those as well, those those dependencies, because we talked about dependencies a lot, but how do we make sure that those a are really understood and be that their did their work with

Kai Stevens  34:42

so that’s a tip when you work in a company right? When you feel there’s still many dependencies between teams a tip is to start visualizing. So before we did this transition towards the QB value streams back then at qB. We had this we call it the epic wall and every year To save you would, we would gather around the epic wall with all the product owners or sub representatives from the teams and the stakeholders. And we would discuss progress towards the most important objectives. And at one day, a colleague suggested hey, let’s take some wires and wire all the the issues, or the epics or the PBIS are depending on another team. That’s why a demo each other and see, visualize how many dependencies are there at that we were like, we were like really flabbergasted by the result, it was this huge spiderweb of wires going everywhere. And that’s really helped. Also, senior management’s realize, like, hey, so much time gets lost in in tracing those wires and managing that one thing is finished in time and managing that if it’s not finished in time that the audit team has work to do, instead of the thing that they now need to wait around for the audit team to be finished first. So the more you’re able to reduce those dependencies, the less waste, of course, in those kinds of alignments in your product organization. And by visualizing that that can be a first step and starting this valuable process of designing a new product development organization. does benefit reduce these, these dependencies?

Sander Dur  36:19

Do you think that we’re still in general, visualizing those kinds of things? Too few. For instance, not necessarily the roadmaps, but the short term versus the longer term goals. How does the sprint goal for instance, relates to the prodigal? What are the steps in between? How are we relatively to that because we can discuss our our goals and our progress right here. But it’s difficult and different, not difficult, but different. When you visualize that it’s more tangible. Do you think that we’re doing that too few?

Kai Stevens  36:52

Yeah, definitely, definitely. At the other place where I worked, I saw that, from one side, leadership struggle to visualize what’s now really most important to the company. Most of all, because often, it’s hard to decide what is actually most important for the company, right. So that’s where it starts. It’s like, if you select 20 things, there’s nothing most important to the company, because there’s too much right. So refer back to our OKRs. At Tado, we now have for q1, two OKRs, from the management layer, that’s communicated to us the product development organization. And there’s way more than that’s valuable to the company. But just to send a clear message of what’s really most important only to write. I’ve also seen situations where there’s 10, or 20, or even more objectives that’s being sent towards teams, and then they then they get lost again. And then referring back to Scrum. Before the new scrum guide was released, there was no product goal. So you had a product vision, and then you add a sprint goal. And that’s just too big of a leap. Right. So from the team perspective, it’s too much to ask from teams to fill in that link themselves between that sprint goal. And the product vision. And a good product owner also, without a product goal can tell that story, right. So it’s about storytelling, and keep engaging with your team to make sure that they understand. But I was personally really happy with the product goal being added to the sprint. story, because that was really the gap. The most important gap that I saw in the scrum framework is that you jump right away from product vision as far as scrum tells anything about that, right. So it tells Well, that’s probably efficient. That’s basically it. And then all of a sudden, there’s this sprint goal that that brings direction on the timeframe of a of a sprint. At least at this body goal. I also discriminate Of course, Dallas, there should be one product goal at a time for a scrum team. So that brings focus, just like we did. Now we did that limiting ourselves to two OKRs. Okay, well for the goal. And then at least it’s super crystal clear for the team. What’s the most important material objective towards that longer term? product vision application in general spends three to five years Well, that’s that’s way too far away,

Sander Dur  39:27

especially when you’re working with products like that, that continuously change. But they also took out the product division in general as the scrum guide. Caught seems to be causing confusion at times and what do you think is the difference between those and how do you work with still incorporating a product division? Do you still do that? And how does it relate to your to your product goals?

Kai Stevens  39:54

Yeah. So there should always be a product vision right? No matter what To what framework to use, and also a scrum there should be a product vision. And then there’s multiple ways to break that down to sensible objectives. Right, you can use OKRs. Or you can use the product goal within the scrum framework. But at least be sure to build in the right levels of granularity from that really big, hairy goal be hack towards something that’s achievable enough for an individual in your organization to engage with, right, something that’s too far away, that doesn’t feel like reality that doesn’t feel like something you will be achieving soon, and it doesn’t reward a individual and a individual team. So I always say it’s better to have an imperfect story, but start telling it and like we just mentioned, repeating it. In my last periods, working with QB Elliniko, I was really responsible for the whole product lineup of tone. And I just started, there were a lot of unclarity is back down because you were migrating into Eneco. It was not clear what the strategy was a way forward exactly would be sort of a lot of reasons for me to say no, I don’t really have the story ready, then we have to wait until this decision is made or this direction of the company becomes more clear. There’s tons of arguments to postpone telling the story. And I would advise, don’t don’t fall into the trap. Because the value of telling a story and again being vulnerable and telling the story like hey, this is what I really know. This is what I don’t know yet. But irata tell you the story now and the queue, maybe next week a change and I’ll update you. But I’d rather do that than keeping you totally in the dark. Right? Yeah. Because if you go for the latter themes will start filling in for themselves. And worst case, you end up in this feature soup, right? Every individual team interpreting what’s most important themselves, or you do a little bit of everything.

Sander Dur  42:14

Yeah, and the remakes in the last episode with with Lauren’s Bonomo and Lila, Lila, new yet, I, we were talking about tons. There’s always a next sprint, which seems to be a corporate disease, where indeed, where you don’t focus on what’s most important right now. So that kind of relates to what you’re saying right here. That story, that narrative is most important at this point. If you do that as soon as you possibly can, then you’re going to avoid cluttering all that features cluttering that fluff. Till you get to the feature soup that you were saying, I’m going to be using feature soup more often than I’d like to turn. Now, what I noticed is that your LinkedIn title may change from product owner to group product manager. Is there a difference?

Kai Stevens  43:02

interesting topic, right? So it’s like I, I switch sides, right? was when I was asked to join, Todd will say, Well, I’m not going to be a product owner anyway. But soon after I started talking with Dominique was held product management a bit, a lot of people within thought, oh, I noticed that there was not really a difference between what I’ve been doing the past decades. So discovering value, and focusing on your customers problems first, before thinking of solutions, translating that in a sensible strategic storyline, and then chopping that up in an actionable plan together with a development team. Yeah, that’s what I did the past 10 years when I was a product owner. And that’s what I still do now as a product manager at adatto. So yeah, the name is different. But my experience so far after us for four months, and I don’t think it will, it will change this I’m sure. I’m doing the same thing, exact same thing, as I’ve been doing. But then better, different, differently.

Sander Dur  44:10

Why do we need a different name then?

Kai Stevens  44:16

Yeah, I don’t really care about the name. But you could say product owner is tied to Scrum and Tado is not using Scrum, right. So that it doesn’t make really much sense to use that name. Well, there’s another name of rounds already for a while. But in a sense, having the two names is confusing, right? Because it’s it’s suggested something different. Well, actually, it should be. In my opinion, I know there’s a lot of opinions about it. But in my opinion, it should be exactly exactly the same thing. Of course, where the difference comes from, I think it’s in the misconceptions of both roles. So if you look at product management, then especially in the past, before the digital era, era, the product manager was sometimes Just type of person who was in an ivory tower far away from the people developing the products, writing down requirements. And then shipping those requirements to another department and the company, we started a development phase. And then at a certain point, we presented back to the product manager had a receipt, oh, no, it is not what I what I wanted to add, of course to with a free, really black and white. And I think the opposite direction, the product owner sometimes has become this tactical clerk of a, of a scrum team. And above him, maybe even a product manager or some other kind of people who really decide on the strategy division, the strategy of the product. And the product owner is some kind of tactical clerk who makes them sure that that plan is executed together with the development team. And that’s not how the role is intended to be. And I also think today, the product management role is not intended to be this ivory tower, kind of man or woman is intended to be exactly the same as a product owner, someone who understands agility, and is able to collaborate really closely with a a product team or development team to discover a value and together maximize the value of the product you’re

Sander Dur  46:21

building. Yeah, exactly. That was my next question. Is there a difference? Because those are the names of the role and the accountability in Scrum? Is there a difference between the activities? I mean, if we’re looking into practice, is there really a difference between product management and product ownership?

Kai Stevens  46:41

In theory, it shouldn’t, right, because both roles are responsible for understanding the market, understanding the target audience of your product, their problems, and then together with a product team translating that into a solution that can relieve them from that frustration problem paying with something with building something smart. So in theory, it students if you look at how the rules sometimes are defined a blueprint in organizations, I understand where the idea comes from that it’s, it’s something different. Right? Because, yeah, the product owner role sometimes is this tactical clerk. And then if you just only see that pattern, that you feel it’s something totally different, because the product owner is not involved in the in the product vision, strategy, pricing, market segments, these kinds of business related related topics.

Sander Dur  47:47

Do you think that we’re losing pragmatism? Or do you think that we’re focusing too much in either doing the execution of the scrum framework or any other agile, or even scaling frameworks, that we’re focusing too much on doing that right? Or are we doing too much, on the other hand, are not doing that at all? And just focusing on the product itself? Do you think that we’re losing pragmatism in solving the issue at hand?

Kai Stevens  48:16

I mean, if you look at the discussion in the Agile community, I think we’re missing the point, right? So these discussions about who the product owner product manager, I think we shouldn’t care that much, we should care about building healthy product development organizations, where the craft of truly understanding your markets, your customers, their problems, and translating that to solutions as as developed, no matter what name you give that person, or that group of people, even who take care of these responsibilities to build a successful product. So in that sense, I agree that it’s really more valuable to ask the question, how can we make sure that these parts of product development are covered? Then that we ask ourselves the question, which person of which or which role or which name to take care of that? Right? So that sounds like fully agree that it shouldn’t matter?

Sander Dur  49:16

I was curious about your opinion, because there’s the both these will be topics in future episodes, where we’ll be looking into losing the pragmatism in product development with Anthony Murphy, and having a debate between Martin domain and Willemijn ATHLEAN. When it comes to product ownership versus product management, and product development, they seem to be on the opposing side.

Kai Stevens  49:39

I think it’ll be a really, really interesting discussion. I know they also have this Martin I know is that he is also having a strong view on the topic. Right. So really looking forward to hearing that and at the end, I think it’s okay that we all have our opinion about it, right? So it’s more important that organizations Regardless if you use Scrum or not learn the foundations of how you can maximize the power of the people actually building your product. So the developers, the designers, how can you maximize every hour they spent on coding or making a new design, right? So look at what’s needed to achieve that. And forget about the name of the role or even the script or the framework that you’re using.

Sander Dur  50:32

Focus on fixing the issue, get it done. Exactly. I got it for people who want to know more about you, where can they find you? Where can they interact with you?

Kai Stevens  50:43

And they can find me on LinkedIn, that’s the best. That’s the best channel. So just browse me on LinkedIn and send me an invite or something. Yeah, PM. I also have a website. It’s it’s chi stevens.com. Maybe I should update it. No, no, don’t mention it. Link there. This is actually the best channel on my website. You can also find my contact details there.

Sander Dur  51:08

Cool. And then you mentioned that you’re teaching courses for people who are now very inspiring, where can they find your courses,

Kai Stevens  51:16

they can find my courses at scrum facilitators.com. And we actually a group of, well, all BSTs except for me, I’m not a PSD. So I’m not allowed to give a scripted org training all by myself, I always go train the trainings. And we give all struggled our course. But I obviously focus on the product owner course because product management, product ownership, that’s kind of my my passion, my thing. So I teach the pspo and pspo. A course with this group facilitators.

Sander Dur  51:51

Awesome. Also, that will be included in the show notes. Say hi to your colleagues from facilitators for me. Thank you very much for being here. Really appreciate it, man.

Kai Stevens  52:01

Thanks a lot again for inviting me and it was a great pleasure.

Sander Dur  52:04

You’re most welcome. Definitely was. Don’t you just love this guy? I know I do. Thank you again for being here. Kai. And as well as you guys, listeners, thank you so much for being here. I hope that you’re going to join the mastering agility, Discord community and help me grow the platform as well as connect to all those other people who are aspiring, agita smart add to this themselves, who are struggling who need help, who just want to connect, discuss specific topics, share their content, share their events. This is a community that’s really built for you, for the community itself for to develop. And that’s the whole reason behind this podcast to help people grow just fire people. I hope I’m gonna see you there. Thank you again for being here. I hope that you’re going to join us again next week. Until then,