EPISODE TRANSCRIPT
[00:00:00] Announcer: Ladies and gentlemen, it’s time for the Agile for Agilists podcast, the series made by Agile enthusiasts for Agile enthusiasts. And now for your hosts, Drew Podwal and Brad Nelson.
[00:00:30] Hey Agilists,
[00:00:30] Brad Nelson: it’s Brad here. In the kickoff, Season 3, we invited back our dear friend and industry expert in behavior design and product management, Dom Michalik, to talk with us about the importance of creating clarity while acknowledging that the people we’re working with are just that, people. They’re humans.
[00:00:48] So in this episode, we’re going to talk about transformational goals. We’re going to talk about creating a clear vision for your organization, for your product, and for your sprint. Thanks If you enjoyed this episode, let us know by following us on your favorite streaming service or leaving us a comment, sending us a message on social media, or sending us an email, or you could go to our website and leave a voice message.
[00:01:11] Now, without further ado, here’s Season 3, Episode 1 with Dom Mikalik. Alright Dom, so thinking about behavior design, where would you start when you’re walking into an organization?
[00:01:24] Dom Michalec: Where I have started in the past, that has helped me is clarifying with the folks who are bringing me into the organization.
[00:01:33] Hey, what would make this engagement like a smashing success for you? Let’s think about 6 months down the line, 12 months down the line, I know it’s kind of hard to think about and I’m looking for a perfect answer, but what does success look like for you? And rarely does the topic of, well, you know, these, I would like to see, uh, our product teams exhibiting these certain behaviors.
[00:01:54] Usually it’s more higher level than that, but as a coach, I’m coming in from the lens of helping to transform the organization’s behaviors as well as their mindsets and helping them adopt helpful behaviors to help them reach an aspiration. So I spend a lot of time doing two things. A, aligning on a clear picture of how the organization looks by the time I leave.
[00:02:19] And when I say what it looks like, I mean like what behaviors are people actively doing that they are, they are either aren’t doing today or they’re not doing enough of today. Um, and that’s really helpful for me because then I can help paint the picture for addressing some, some gaps in. Our engagement strategy, if you will.
[00:02:36] Like, what am I trying to do from a strategic standpoint? If I know what the end looks like, if I know what the ultimate behavior change of the outcomes look like, that helps me work backwards. Um, but I also spend a, a fair amount of time assessing as well, interviewing folks, uh, asking other folks in your organization to introduce me to.
[00:02:54] Folks that I may not even be engaged with or it may need to be responsible for engaging with, but at least can help me help paint a picture for me to understand is this organization aligned on certain aspects of their business, right? Does, can everyone recite the product vision? Does everyone know how the company makes money?
[00:03:11] Can everyone give me a, uh, an example of how they would, you know, describe, uh, their products to, as one of my colleagues likes to put it, their old aunt Rita. Someone who is unfamiliar with what they do or what their product does, but can you explain it in simple terms? So once I get a sense for what success looks like and where people are today in terms of alignment towards that success that gives me enough to begin working with and move beyond observation and To begin building trust and credibility with the teams.
[00:03:42] I’m ultimately responsible for coaching
[00:03:45] Brad Nelson: How often do you go into an organization and they know what success looks like, they know what they want, or do you have to help guide them to get them there? Where I do
[00:03:54] Dom Michalec: most of my guiding is getting to the uncomfortable point of being very explicit about the types of behaviors that they want to see.
[00:04:02] in their organization. Now, sometimes I’ll admit when we do this, um, together, I noticed some anti patterns, right? Like I, you know, I just want my engineering team to be able to deliver the features that the business wants faster. And we’ll address that, um, at the, you know, at the onset of it. And, and, and we’ll, I’ll be curious and understand, you know, where you’re really coming from, what’s the true aspiration behind that.
[00:04:25] I’m sure they care just as much about delivering value to their customers as delivering product as quickly as possible or delivering features as quickly as possible. But that to me is, again, whether I hear exactly what I want to hear or I hear the exact opposite of what I want to hear, I can begin to see where the walls are in the room that I’m sitting and it helps me understand.
[00:04:48] where we might be aligned on the overall success of this, of this engagement, and maybe where I need to even do some coaching of the stakeholders and the sponsors of this organization who brought me in to help them coach their teams, [00:05:00] because rarely do stakeholders and sponsors pay you to coach them.
[00:05:04] They pay you to coach their teams because their teams are the ones who need to change, not necessarily at the higher level, but we still address that nonetheless.
[00:05:13] Drew Podwal: So I was actually thinking about that part as you were talking about helping the leadership to outline the types of behaviors that they want to see.
[00:05:21] And the question of, well, what are you willing to do? Or how do you feel like you might be preventing those behaviors? Uh, from actually maturing and happening or, you know, so let’s think about it from that perspective, right? You’re in that meeting with stakeholders, you know, maybe one of them does say, you know, I just wish that they would deliver faster.
[00:05:46] What are some tiny habit or context triggers that you could build in to those reoccurring meetings that you have with leadership and stakeholders? To, you know, or even like what you said before, is that people don’t want to change when they don’t feel good. They want to change when they feel happy and good.
[00:06:03] Dom Michalec: Yeah, absolutely. I think when it broaches the subject of a team isn’t doing something that I want them to do, I’ll start at a high level here. We normally start with, okay, well, what. is happening in the organization that is preventing them from doing that. Rarely do I just come out and say, what are you doing specifically to hold this team back?
[00:06:23] Like that, that doesn’t help anyone, right? So you got to have a little bit more tact and a little bit more, what I call coaching curiosity. Um, but that right there. It’s not necessarily a tiny habit, but what we are addressing in behavior design is this idea of clarifying the aspiration and ensuring that the things that need to happen, the behaviors that need to be exhibited, um, are easy enough to do, because rarely do people just not do something because they We’re told to do it and they say, well, I’m just going to abstain from doing it.
[00:06:54] Usually there’s some conflicting motivations. There’s, uh, competing motivations. There’s sometimes even invisible motivations, right? But nonetheless, when we talk about behavior design in this context, I like to pose the question of, okay, well, I’m curious if they’re not doing it today, what is happening in the organization that is making this behavior hard to do?
[00:07:15] And that is usually a really, really good starting point because it flips people’s perspective of the team’s the problem to. Hmm, maybe there’s something in their way, especially if it promotes agility. Usually there might be something in their way. So how can we remove that barrier and make it easier for them to do?
[00:07:33] I
[00:07:34] Drew Podwal: love that. As we’re talking, I’m trying to look through the lens of the different things that I’ve learned from you. You said celebrating just the smallest of smallest wins that we forget to celebrate those wins, and it’s suddenly dawning on me that like, you know, starting out that conversation, when you walk into the room with the leadership standing there, the first opportunity to celebrate a win is right at that moment to say, you guys made a great decision.
[00:08:02] You’ve invested your time in coming together and making a change in this organization so that you guys are able to get software out faster, higher quality, greater innovation, or, or whatever that is. And I was thinking about even further, like you could first start with an idea of an exercise where everybody puts a sticky note up on the wall or be the digital, whatever.
[00:08:27] When you think about the idea of this change right now, how does it make you feel, what are you guys feeling in the room? And then maybe doing another round where it’s like, well, what opportunities do we have ahead of us? If we could overcome those fears? What do we stand to gain? And I feel like that kind of celebration there with leadership.
[00:08:51] I’m thinking about it. I’m like, Oh God, I’m going to be the guy with the tambourine again and the bongos, right? And now there’s all these people in suits who are looking at me, you know, pulling out my bag of tambourines and bongos and are they really going to want to play? But I don’t know. I feel like now that feels a lot more approachable.
[00:09:10] Dom Michalec: Yeah. I’ll give you a very specific example of a habit that I designed for myself as a coach to help me check in with the sponsors of. The engagement that I was a part of. So I’ll give you an example. The company I was working with, uh, late last year, I was working with a fairly, I would describe her as a, as prickly VP of product who didn’t bring me in.
[00:09:37] She wasn’t the sponsor. It’s a, it was actually the director of product who brought me in. So the, the guy who, who reported to her brought me in and she was very skeptical. of my presence, the things I was doing. She was very curious, but also from a perspective of, like, I don’t know if we made a wise investment here.
[00:09:57] And it had nothing to do with me per se. It was just the, I [00:10:00] think the underlying theme was, well, if we can’t coach and develop our own people, it’s going to look bad if we have to bring in an external coach, whatever it may be. But I actually, And this is inspired by, and I know you and I talked about this Drew, it was actually inspired by an episode of Ted Lasso, and I called it the Biscuits with the Boss Habit, where every morning I logged into Microsoft Teams, I just sent her a quick note.
[00:10:24] Hey, what’s on your mind today? What are you paying attention to today? 90 percent of my time was focused on the teams that reported to her, but as a key stakeholder, as a key influencer of the success that I was going to have or not have as a coach, I made it a habit for myself to check in with her literally every single day.
[00:10:42] And I would switch up the question, it wouldn’t just be like copy paste, Hey, what’s on your mind today? Like, you know, I would just find an opportunity in the morning when I logged in. So quite literally flip open my laptop, I fire up Microsoft Teams. As soon as Teams loaded, I just checked in with her and I’d ask her.
[00:10:58] A question like, hey, what’s top of mind for you today? Um, where are you feeling stressed today? Where can I help today? One of my favorite questions I would ask is, hey, what are you seeing that I can’t see? Because you, you know, you said, uh, you sit from a different perspective. Just checking in with her.
[00:11:15] Having that biscuits with the boss type moment with her. And sometimes it would turn into a pretty lengthy conversation. It would turn into, you know, 10, 15 minutes of our mornings, chatting back and forth. But over time, I don’t want to say I ever won her over, but it showed her I was invested in aligning my strategy as a coach with some of the incentives and some of the things that she wanted to see, even though she wasn’t the one who brought me it.
[00:11:39] Drew Podwal: I love that. I love any Ted Lasso. Ism that you could pull into this. Yeah, that’s great. Yeah, there’s so much potential there right as a coach you do you have the time for that and You could send those out in the morning to a bunch of different people, right? And maybe there’s sending it out again in the afternoon
[00:12:00] Dom Michalec: Um, that was just a tiny behavior that I again, I designed it.
[00:12:05] I adopted it. I practice it It became, I don’t wanna say it became automatic. It definitely wasn’t a reflex. It wasn’t just like, I was like, Oh, Microsoft Teams, I have to, I had to, I still had to think about it, but it was easier for me to do because it helped me reach that aspiration. Because I think it just from, from past life experience, I learned, I got burned, right?
[00:12:24] I got too focused on helping the teams. I was brought in to help and I failed. To also pay service to the folks who I don’t work with on a day to day basis, but have a heavy influence in my effectiveness in the day to day.
[00:12:38] Drew Podwal: You know, one thing that I did is an experiment a couple of times now, actually, this team was having poor turnout to their, their sprint reviews from, from leadership.
[00:12:49] There were some people that would come sporadically, there were some that came less sporadically and whatnot, and so what we started doing was, at the end of every sprint, sending out publicly the team putting together a gratitude to say that, hey, we’re so glad that you showed up. By you guys showing up or by you, this person showing up, we were able to gain this level of clarity and insight, which is, which helped us to then understand this problem to a greater degree.
[00:13:20] And now we’re really confident that we’re going to be able to deliver this, these capabilities in the next sprint. So, thank you. And what we started to notice was that people were showing up with greater frequency. And the people who weren’t showing up very much at all, they started showing up because they started to see this buzz going on between stakeholders and, and the scrum teams.
[00:13:46] And they wanted to figure out what that buzz was all about. And so they started making the time for that as well. Uh,
[00:13:52] Dom Michalec: I think, uh, the, the kids call it FOMO. Yeah, I think that’s really what I heard you say, drew, is you somehow some way turned the sprint review into something special that people wanted to be a part of.
[00:14:05] And the more, the more people wanna be a part of it, the more they influenced others through the, almost like a scarcity mindset. It’s like, well, I’m missing out on something. Like what am I missing out on? And it ultimately influenced them to, to come join you. Scarcity complex works in product. It works in.
[00:14:21] Individual behaviors, it works in group behaviors. People don’t like missing out on special things. And I think what’s really interesting about that is, let’s think about it from the flip side, we think about a lot of these events in Scrum, they’re recurring events. And usually when you have a recurring event, it becomes very easy to not care about the purpose of the event.
[00:14:44] And it becomes even less important to make the invitation to the event special and personalized to the people who you want to show up. And this is something I actually, it’s top of mind for me because I was talking to a team about this the other day. It’s people’s [00:15:00] attention is earned. not owed. When it comes to recurring events, we get into this mindset that people just owe us their attention because it’s far enough out on their calendar and they shouldn’t show up because, well, they shouldn’t have any conflicts because we scheduled this months and months and months in advance.
[00:15:15] But that’s, that doesn’t matter. What matters is that you need to make something purposeful. Intentful, you need to make the invitation special enough, personalized enough, that takes a lot of effort, but when it comes to recurring events, and that’s, and I guess that’s always been my, my curiosity about scrum is how do we make purposeful, intentful events out of recurring events that are supposed to add predictability to our ability to inspect and adapt our processes, our dynamics, our products, whatever it may be, it’s just something curious to think about.
[00:15:49] Thank you. from a coaching perspective is the more recurring an event is, the less attention we pay to making it special. And I almost think we’re doing ourselves a disservice sometimes by not addressing and making things special enough.
[00:16:03] Drew Podwal: Yeah, I definitely hear what you’re saying there. It’s eye opening, right?
[00:16:07] Because the thing is, is that it’s easy to create a reoccurring event. But the fact that it’s reoccurring makes it easier to ignore as well. And you know, as I’m thinking here, like what I’ve done in the past is before reoccurring events, I always make sure that I update the invite, but I kind of feel like even one step better than that would be to create a brand new invite with, what are they going to get out of this?
[00:16:34] out of attending it. Why should they show up? And then deleting that instance of the reoccurring event. So now you’ve replaced it with that thing.
[00:16:44] Dom Michalec: Yeah, that’s a lot of work. I think my mind just went to this idea, you know, how do we embrace scarcity? So folks feel incentivized to show up to these things when these events aren’t very scarce at all.
[00:16:56] In fact, if I miss this one, well, I’ll just show up to the one in two weeks. Well, I missed that one. Well, there’s another one in two weeks. I’ve missed six months worth of sprint reviews because it’s so predictable, I don’t need to show up. And in fact, the more I miss and the less pain I feel from missing out on that, the less likely I’m even going to show up in the future.
[00:17:16] So it’s a weird dichotomy between adding predictability, but also making it. special enough and worthwhile enough for people to attend and participate. You have me
[00:17:27] Brad Nelson: reflecting too, because I mean, we’re talking about sprint reviews for the most part here, and it makes me think about my sprint reviews, where as a scrum master, I was either responsible for kind of like organizing the PowerPoint deck and setting the agenda or as a product owner, which I am currently helping out at a client as a product owner, I’m the one that’s kind of taking the lead on the event and facilitating.
[00:17:50] and doing the handoffs to whoever is going to participate. And it’s really easy to be like, I made this deck, this deck is now my template, I just, last minute, like, oh shoot, gotta update the deck, throw in the last minute update, and just run through the motions every single
[00:18:06] Dom Michalec: time. Yeah. And then we’re surprised why people don’t care.
[00:18:09] And that’s not a, that’s not a, a shame on you, Brad, but it’s very common that like, Oh, well, Oh man, spring reviews in two, in two hours, I need to update the deck and send it out to folks. It’s like, we have to be more intentional about this stuff. I guess what I’m saying. And the more recurring something is the more likely we are to be unintentional and just kind of go through the motions.
[00:18:28] Um, even though having that predictability is. In theory helpful, um, our behavior sometimes reveals some anti patterns in, in making those, uh, in highlighting the, the benefits of it being more predictable.
[00:18:40] Drew Podwal: Well, and ever, you know, the one who’s trying to like automate stuff, right? I’m always trying to automate stuff.
[00:18:45] I’m always trying to make it so that if you want the data, it’s right there because everybody’s filling out their things properly. The data should just be right there. If the team is setting their sprint goals. Appropriately at the beginning of the sprint and the teams are drafting their stories in user story voice, the outcomes that they’re trying to achieve.
[00:19:08] Like, I see way too often that stories are just like technology, a story that’s called like stand up new database or something like that or whatever that is. But if they’re writing it in a way where, Where they’ve got the sprint goals and each of the stories or the defects that have been resolved or the technology debt has been resolved is written in that shared language between technology and stakeholder.
[00:19:35] Could theoretically create a plugin that would extract that information at the end of the sprint and insert it into that invite. Or even a deck, Brad, right? Like, I’m not a fan of decks in, in the sprint review. Like, I’ve often just said, like, if we don’t have anything to demo from the front end, we’re going to demo it from the back end, as opposed to [00:20:00] showing a slide deck, but.
[00:20:01] Brad Nelson: Oh, we definitely demo the back end. The slide deck is just like, here’s the agenda, here’s what we’re going to talk through today, and then it’s like switching between screens. I definitely agree, like, death by PowerPoint is a bad thing. Yeah, although
[00:20:14] Drew Podwal: you’re a PowerPoint master, I forgot about that. Like, you are, like, you touch a PowerPoint and it turns to gold, so.
[00:20:22] Dom Michalec: I don’t know about that. I try. This does touch on aspects of behavior design too, because when I hear… When I hear things like, you know, you know, setting a strong agenda, what I care more about is what should people who show up to these events be able to do because they came to this meeting? Like, what behavior should they be able to exhibit?
[00:20:42] What should they be able to say? What should, what, what should they be able to sense about the direction of this, of this product or this project that we’re working on, whatever it may be, thinking more in terms of like the intended outcomes, the new behaviors, the new insights, um, the new things that they can say about this product or project, whatever it may be, I find that that is more intentional than maybe an agenda.
[00:21:07] I mean, I think we’ve all seen it, right? Like we’ve been in plenty of, of, of events that had really strong agendas and we’re still a massive waste of time. And people show up to these things wondering, like, why am I here? What’s the purpose of this? What should I, what should I be able to do? And maybe they don’t even, maybe don’t think about it from that direction, but innately that’s what they’re thinking is, okay, I’m here.
[00:21:28] I’m investing my time. Um, you are earning my time to be here. Where’s the payoff? And if we just, you know, kind of run through a list of agenda items and they walk away like, well, I’m, I’m more informed, but it didn’t help me do it, do my job easier. It didn’t help me provide clarity to folks who didn’t, who weren’t able to attend.
[00:21:47] I think that’s where we need to spend more time and we can use behavior design. Clarifying what it is we’re ultimately trying to do, making it easier for folks to do during these types of events so they can walk away feeling like, wow, because I went to that sprint review, I’m now able to go to my boss and clearly articulate how this team is performing, whether or not they hit their sprint goal, things that they learned and new features and functionality that are just waiting for the CI pipeline to pull it into production.
[00:22:16] But again, going back to the topic of recurring meetings as a product manager or as a coach or as a scrum master, sometimes we just fall into the routine of, well, okay, it’s Friday at 8am. We have sprint review here in two hours. Who’s got the slide deck? I need to update it real quick. And then we just kind of run through the motions again and again and again.
[00:22:36] And then we’re surprised why people don’t show up.
[00:22:39] Drew Podwal: The way that I coach like sprint goals or PI objectives or any sort of like outcome based writing is I’m, I’m a huge fan of the late great Clayton Christensen with jobs to be done. And I love his quote where he talks about a product is a problem solver that solves the problem that is an end user’s job to be done.
[00:22:59] And so from a sprint goal perspective, which jobs to be done, uh, which problems have we solved for which types of customers or which problems are we setting as our goal to solve for which types of customers in this sprint and that by writing it in that way. And it feels a little weird at first, right?
[00:23:20] Because it’s an exercise of stripping it down to the studs and getting back to basics. But I find that it’s very helpful in getting teams to think about their work as the problems that they are solving for very specific types of users, which will then enable additional types of outcomes for those users.
[00:23:41] So I’m thinking about it from a perspective of How do you sensationalize that invite? Come join us today to see how we’ve solved the problem of X, Y, and Z that enables A type of persona to achieve B type of outcome. You know, and then to take what you’re talking about, Dom, the idea of like, if you join.
[00:24:05] Imagine how awesome it’ll be when you go back to your boss to tell them that the teams were able to deliver this. Yeah.
[00:24:12] Dom Michalec: It’s like the same thing. A product is there to make the users and the customers rock stars. Your sprint review can be used to make your stakeholders rock stars. It’s like, Hey, I’ve seen.
[00:24:25] So of the teams that I’ve coached, one team was really, really good at doing this where. In the invitation, they said, Hey, by the end of this Sprint Review, you should be able to answer any question that your boss has about our product. Like, that’s really powerful. That’s much different than 10 minutes on this, 20 minutes on that, 5 minutes on this, and then 3 minutes of Q& A, even though we buffered in 10 minutes of Q& A, because we didn’t have enough to review with you today, and demo with you today.
[00:24:52] They were very, very clear about, if you show up, you will be able to do this.
[00:24:57] Brad Nelson: So, I’m going to throw a wrench in here, [00:25:00] because I’m that guy. I do not read meeting descriptions almost ever, and if it’s recurring, I’m even less likely to read it. I don’t, like, I know what it is, I will show up. If you want something from me, you can ask me.
[00:25:12] Don’t give me homework before I meet with you, because I’m probably not going to do it. And it’s not that I don’t care, it’s just, like all of us, I’m busy. And the point of the meeting is… to get together and talk. If you want me to look at something, send me an email, or send me a DM, or whatever. And so, I love this idea, but at the same time, I’m a little skeptical, because, you know, I know I’m not the user, but I’m a user, and I’m like, well, that wouldn’t work for me.
[00:25:36] Drew Podwal: So I’m now, okay, I’m gonna say it. Now I’m thinking about, like, well, maybe we should start using Evite, right? Like, like, how cool would it be to have, Video attachments of the person who’s hosting the meeting, why you should care about this meeting and what you’ll get out of it. 30 second
[00:25:58] Brad Nelson: clips. Do I get a TikTok dance in there too?
[00:26:01] Drew Podwal: You can get a TikTok dance, yeah, yeah. And I’ll have sticky notes all over my face as well.
[00:26:07] Dom Michalec: And Brad, actually, you and I are more in alignment than not here. And here’s why. More often than not. We use these events to inform people, us presenting to you, I am talking at you, I am showing you, I am not making this a collaborative experience, but if I’m not mistaken, one of the key reasons why the Sprint Review is even there is to inspect and adapt, bring your stakeholders into the conversation, Collaborate with them, figure out where do we need to make changes?
[00:26:39] Where do we need to make adjustments? And then commit to that going into sprint planning. So I agree with you. Like if you’re just going to sit there and talk at me for, you know, an hour or two hours, like send me an email, send me a loom video of you giving a presentation. But we need to make these events more collaborative.
[00:26:57] And again, that involves behavior change. Some people may not be used to being drawn into a conversation about what to do next, or maybe why we didn’t meet our sprint goal and what adjustments we think we need to make, and how you can help unblock us from, in order to make that easier to attain. And again, maybe, maybe I’m just not working with, with the teams that do this really well, but rarely do I see the sprint review actually turn into a workshop.
[00:27:21] It’s more of a presentation, me talking at you, me showing you this thing, me hoping you don’t notice the thing that I didn’t build, even though I said we were going to build it two weeks ago, please don’t, please don’t catch that. Um, but I, I, all joking aside, how we make it more collaborative and invite people into the conversation and ask for them to engage and behave.
[00:27:43] That’s the real value out of these things, and that’s how, that’s what we need to take into consideration. Well,
[00:27:49] Drew Podwal: you know, the barrier to entry that I’ve seen, more often than not, back when I was a Scrum Master, if I can get the stakeholders to show up, then I can make it interesting. Like, I’m a good facilitator in that regard.
[00:28:01] But the barrier to entry that I’ve always experienced is the mindset of stakeholders who are like, don’t invite me every two weeks, just invite me when it’s done. I only want to see it when it’s done. And so what I’ve I’ve tried to work on there, right, with the idea of when I get my team to give praise to the people who’ve joined is to demonstrate that if you show up, you’ll be able to influence how we’re building this, and we’ll have better results, higher quality and whatnot.
[00:28:34] But to me, it’s not about the Like, and I’ve definitely been in very boring sprint reviews, especially when, especially when the organization has every team is split with front end teams and back end teams and the back end teams never have the ability to demo something, you know, from the front end, it’s always.
[00:28:52] We’ve inputted this value as a happy path, and look, we got this value out as a happy path, and we’ve inputted this fail path, and now we’ve got a fail path, and that’s like ridiculously boring, so I think that’s one of the things that I’ve taken away from like the Team Topologies book, is that’s why you don’t structure teams front end and back end like that, you want to have them blended together so that stakeholders want to that’s why you want to participate more, and that’s why you Things can actually be demoed in a way that we can get quality feedback.
[00:29:23] But again, the barrier to entry that I’ve always seen is less about the how do we make this exciting and more about the how do I convince people to give a crap before The entire feature is done, so yeah,
[00:29:39] Dom Michalec: if you don’t mind, I might ask you gentlemen a question like in the context of let’s say you’re, you’re a product owner, it’s Friday before sprint review.
[00:29:48] How would you structure the intended outcomes? Like in your opinions, like what should people be able to do having attended the sprint review? And Drew, if you want to go first or Brad, I, it’s up to you guys. I’m just, [00:30:00] I’m just really curious, like how you guys would approach this. Rock, paper, scissors. I’ll let you go
[00:30:05] Drew Podwal: first, Brad.
[00:30:05] You go first.
[00:30:06] Brad Nelson: Uh, well, to me, there’s, there’s multiple personas for a sprint review. One of them is the team. The team is hoping to learn, to get feedback on the thing that they’re working on. So any way that you can show something, demo something, talk through something, in order to get feedback. There’s also, on a psychological level, the component of the person that built the thing is the one demoing it, so that they get the praise, and they also get face time with these stakeholders, and it really kind of like builds people up to be able to to be the one showing it and getting that feedback.
[00:30:45] Then when I think on the other side, it’s the stakeholders. The stakeholders want reassurance that the thing that they’re paying for is well underway. They’re going to get it when we said we’re going to give it to them, or that it’s turning out how they want it to be, um, and they want to be able to communicate that.
[00:31:03] Kind of to your point earlier that you talked about DOM, they want to be able to communicate that up to their leadership and to the people that they’re accountable for. And so a lot of times when these stakeholders come, I feel like a lot of them care less about the demo and they just want to know, where’s the roadmap?
[00:31:21] Are we on track? What’s the budget? Like, just tell me that and I’m good to go. And if you try asking them questions, they’re just like, uh, no, that’s okay. I
[00:31:31] Dom Michalec: mean anything. Definitely been there. Definitely been there. What about you, Drew? I’m curious. How would you structure the intended outcome for a sprint review as a product owner?
[00:31:40] Drew Podwal: Um, you know, so what I am thinking as a product owner, um, and that’s good clarity as a product owner, you know, there’s two things I’m focusing on. First is demoing what’s been built as a product owner. I also want to get that feedback. So it’ll help me to figure out how to best sequence. The rest of the backlog.
[00:32:00] And then the other thing that maybe not as a product owner, maybe as a scrum master, but if I may, as a scrum master, I’m trying to create a valuable experience for everybody involved. I’m trying to create a valuable experience for the team. I’m trying to create a value experience for the stakeholders, right?
[00:32:19] It’s. Product owners don’t care about that. Well. I think that in some regards they do, but I also think that they’re more concerned about the information, or at least that’s been my perception, right? They’re more concerned about the information that’s being presented and the optics around how it’s being presented because they don’t want to look bad.
[00:32:41] And I think that it’s the scrum master who’s really looking at it from a perspective of, it doesn’t matter if what we’re showing them is not to a degree that it’s polished enough, it’s how do I set the stage and create a pace to ensure that people are participating and that this exchange of information is moving back and forth across the table and that they’re going to show up again the next, the end of next sprint and not throw their hands in the air.
[00:33:11] Gotcha.
[00:33:11] Dom Michalec: Gotcha. Okay. Yeah. I just, I guess to reveal the why behind the question, what I was looking for is why does anyone need to show up in order to achieve these things? Um, I think, I think Drew, uh, we can touch on that last one here, but like things like getting feedback, uh, maybe even having an opportunity to get praise and recognition, getting reassurance that things are on track or whatever it may be, being able to articulate progress to the people that we ultimately are responsible to, uh, reporting back to, that doesn’t take a meeting.
[00:33:44] Right? That could be someone recording a presentation, recording a demonstration, sending it out to a hundred people, and saying, Hey, here’s where we are today. Here’s what questions we could answer. Here’s maybe some questions that we answered during this presentation and during this demonstration. Um, I think, I think it gets away from the spirit of the Sprint Review, but if I may, there were just, there were not many things I heard where it’s like, well, this requires us to have a special event outside of maybe Drew, what you’re talking about, where we want to be able to draw people into the experience and, and give them a seat at the table and where we might want to make adjustments to our process, to our product, to how we approach our marketplace, whatever it may be.
[00:34:27] Drew Podwal: Yeah, and that’s the big part of it, right, Dom, is that it’s an opportunity for, especially in a early phase Agile organization. Developer doesn’t oftentimes have the pathway to be able to say, Hey, here’s another way of slicing this feature. And the demo actually becomes a great way to kind of horse trade a little bit.
[00:34:50] Where the team can say, all right, you know, what we’re thinking about in building out the rest of this is we’d love to be able to split this and [00:35:00] focus our attention here and getting to a spot where those kinds of conversations can actually happen and that. That stakeholders can hold the space for that kind of conversation in a sprint review is the next step for enabling stakeholders to hold the space for ID.
[00:35:17] Like it’s helpful to the product owner because the product owner oftentimes knows that when they’re being given this shovel ready feature that they’ve got to just put on the feature factory, uh, conveyor belts, that if you can get the stakeholders in the room with the full team to then kind of back up the.
[00:35:34] the, the product owner to say, here’s what we’re thinking. Then the product owner is more likely to then be able to just have that conversation with the stakeholder one on one so that the features that are now flowing in are better sliced and put together as a hypothesis, you
[00:35:53] Brad Nelson: know. I do want to touch on it.
[00:35:55] I think it also goes back to agile principles of like face to face communication. As well as removing kind of that telephone game. I think it’s really important for developers to hear firsthand from stakeholders what they like and don’t like.
[00:36:09] Dom Michalec: I love this conversation and I promise anyone listening to this, I didn’t pay Brad or Drew to say this stuff, but what I’m hearing and what I, what I really ultimately, and again, everyone’s mileage will vary.
[00:36:20] They can agree with me or disagree with me. To me, the purpose of the Sprint Review. The goal is to create and hold the space necessary to figure out if we can get to our destination faster than we thought we could today. That involves stakeholder engagement, that involves stakeholders presenting their wants, wishes, desires, and it ultimately helps the team understand, okay, I know what you want, but if we can get there faster by thinking about it differently, We ultimately win and we can only get that if you show up to this review to give us that feedback, right?
[00:36:57] It’s very much, like, it’s very much in the purview of the business to know the what. It’s a purview of the technology team or the product team to figure out the how. If we can get to the what faster by thinking about the how differently, isn’t that a great sprint review? I don’t know, what are your guys thoughts on that?
[00:37:12] I, it’s a strong opinion, Lucy held. Yeah,
[00:37:15] Drew Podwal: you know, real quickly, right? There’s three principles that are at play here. The first one is, is that business people and developers must work together daily throughout the project. One of the biggest challenges in a waterfall way of working is you’ve got your business stakeholders way over to the left, closest to the money, and they don’t want to make much time to come over and hang out with the developers too much, right?
[00:37:41] So that’s the first principle of play. The second is build projects around motivated individuals and give them the environment and support they need and trust them to get the job done. So showing up once every two weeks to a demo is giving them the support they need and going away for two weeks and giving them the space to actually.
[00:38:02] do the work is giving them the support and trusting them to get the job done. And then the last one that Brad mentioned is the most efficient and effective method of conveying information to and within a development team is face to face conversation. Now, does video work? Like, does this work? We are having amazing conversations, right?
[00:38:23] None of us are located together and it’s been wonderful, but could we record an episode of a podcast? where I read my scripts and Brad reads his scripts and Dom, you read your script, and now we put it together. The other part of it, too, is that my fear, and I don’t know if this is accurate, is that if we do the sprint review as a video and just put it out there, like you said, right, Brad, you said this, Dom, you said this, you don’t read the descriptions of meetings, you just show up.
[00:38:54] So are you going to watch the video? Are you going to watch a half hour or an hour long video? I won’t.
[00:39:01] Brad Nelson: Yeah, honestly, like I know me even meetings that I’m like, man, I wish I could really go to that or events that like LinkedIn events, whatever. If I miss it, I’m not watching it. It’s just, I don’t know, something with me.
[00:39:12] Drew Podwal: Yeah, you know, like I am terrible at remote learning, like self paced remote learning. If I have to do self paced remote learning, I’m not going to finish the course. But if there’s at least once a week or twice a week, ideally a live instructor led me. Workshop, or something, then I’m, I’m eager for that.
[00:39:32] Brad Nelson: I do want to touch on, on your comment about the sprint review and, and getting things done faster.
[00:39:38] I would not use the word faster personally, personally, I would link it more to value. To me, doing something quickly isn’t valuable necessarily. It’s how do we maximize the value? Yeah.
[00:39:48] Dom Michalec: Just some nuance there. I chose my words. How do we reach our destination faster? That doesn’t mean build things faster, but how do we get to that destination faster?
[00:39:58] And I think you actually [00:40:00] double clicked on it appropriately, Brad. That’s kind of what I’m talking about. There’s, okay, how do we get to our destination? How do we deliver value faster? By reducing waste, maybe reducing the, you know, I don’t want to say take shortcuts because that has a negative connotation, but how can we take a more direct route to our destination, which is delivering value in a way that, Solves problems for our customers while also provides the business with what they need to sustain growth, profitability, whatever it may be.
[00:40:27] Drew Podwal: So politely speaking, um, and now I’m just going to tear you down, but no, um, politely speaking, right? Like that is in and of itself, the mindset of many of the stakeholders, because the reality is, is that rarely does a stakeholder know what they want at the beginning of development. Rarely does a scrum team know what they’re going to build and how they’re going to build it at the beginning.
[00:40:52] And it’s the journey of collaborating together face to face with the stakeholders and the developers and ideally with some customers that come in every now and then. So it’s not the destination per se faster. It’s how do we actually maximize our learning together and our collaboration together to make sure that we discover.
[00:41:15] the optimal destination and breaking it down into sprints and smaller increments of delivery helps us to then the incremental part is what helps us to deliver faster if we can break things down into smaller
[00:41:30] Dom Michalec: increments. Drew, you, you hit on something that when I do an initial assessment with product organizations, sales organizations, marketing operations, whatever you hit on the thing that.
[00:41:40] Everyone is most misaligned on, which is the product vision. I ask a very simple question. Yeah. And it could be to a salesperson. It could be to the product manager. It could be to the designers. It could be to someone in marketing. Hey, what does the world look like with your product in it? What are people doing differently with your product in their hands?
[00:41:59] Rarely do I ever get alignment on that question in terms of answers, but that is where we need the most alignment. And I actually, if I, if I may tell the story. I didn’t realize what a good product vision looked like until I saw a case study, uh, from, from Leah Hickman, uh, Leah Hickman is a, uh, well, she’s now a partner, uh, at Silicon Valley Product Group, but she walked us through, there we go, Adobe’s, uh, so as you guys probably are well aware, Adobe used to sell physical boxes of their products, right?
[00:42:31] You go to the store, you buy it, you download it, blah, blah, whatever. But as they were transitioning to Adobe Cloud, They knew from the onset, we need a strong product vision. Why? Because our strategy depends on it and every decision that we make needs to help us move closer. To your point, Drew, we need to discover how to get there, but we already know what the world looks like with Adobe Cloud out there.
[00:42:56] People using it. It actually went as far, and I’m not saying like every company needs to do this. But they literally created a commercial for Adobe cloud years before Adobe cloud was actually a thing where it started off with, they use this fictitious persona of, you know, this, this person who wanted to ultimately create their own design agency, but they didn’t have the money to do it.
[00:43:22] They couldn’t buy all these different products from Adobe because it’s just too expensive. Well, with Adobe Cloud, she was able to start her own design agency. She was getting clients. She was able to utilize the parts of Adobe Cloud that she needed, and she was able to keep the rest on the side because she was only, she was only paying for what she was using.
[00:43:42] And it allowed her to start her business. And she had, you know, huge growth and huge success. Basically, Adobe Cloud allowed her to change her life. She went from working at a design agency that she didn’t like working at to starting her own design agency and living on it by her own rules, the beat of her own drum, and she was doing great work.
[00:44:03] That was a really compelling product vision, and I realized, I mean, I’ve been doing this for a while, and I realized, like, Wow, I’ve never seen a product vision quite like that. So while I agree that discovering what needs to be built or discovering the direction we need to go is important, so long as that is serving our destination, how do we get to our destination faster?
[00:44:24] How do we achieve that product vision faster? That’s what I’m talking about. Not necessarily how do we, you know, build the four or five things that my stakeholders said they want to build three months before we said we would build it. That’s a completely different story. I’m talking more of like that product vision.
[00:44:38] And. I’ll just, like I said, I’ll just, I’ll, I’ll cap this off. It’s rarely do I ever get alignment from people across an organization as to what the world looks like with their product in it.
[00:44:50] Brad Nelson: If only I could get Illustrator and Photoshop without buying the whole thing. This struggling podcast designer.
[00:44:55] Come
[00:44:56] Dom Michalec: on Adobe. Yeah. Yeah, right. I I, it was just very eyeopening to me, so when I, I guess. [00:45:00] Whenever I talk about the word destination, 99 percent of the time I’m talking about that product vision, not the destination that our stakeholders think we should go, you know, in sales or in marketing. I’m talking about like that true overarching North Star.
[00:45:16] That is what the world is going to look like with our product in it. How we get there, we don’t know, but we’re going to figure it out. That’s what I’m talking about.
[00:45:24] Drew Podwal: So when I was in digital publishing way, way back at the beginning of my career, One of the things that we became acutely aware of is the piracy that was happening with mp3s.
[00:45:34] The reason why that came about was that mp3 players became available before an actual store to legally purchase mp3s. I didn’t, I
[00:45:44] Dom Michalec: didn’t realize that. That’s, that’s interesting. Oh, yeah.
[00:45:46] Drew Podwal: Um, I think it was the Rio was like with the first MP3 player and then, you know, the iPod came out and whatnot. And even, I think when the iPod came out, there still wasn’t an Apple music store.
[00:45:58] Um, or I guess the iTunes store is what they called it back then. And so in the publishing space at the time. We were actually looking at the same sort of thing is that the hypothesis was that the reason why piracy occurs is because it’s easier for somebody to take the risk to pirate something than it is for them to purchase it.
[00:46:20] And I know that Adobe faced. the same challenge is that like in the 90s, early 2000s before Adobe cloud came online. I don’t know what the exact numbers were, but like they were definitely one of the biggest pirated platforms out there. And so I would imagine that Well, yes, the product vision is this woman who wants to start her own design business and you know, needs an affordable way to do it.
[00:46:49] I would also believe that there’s another persona, which is, how do we make it easier for a pirate? Somebody was pirated before to pay for our products instead of continuing to pirate it. I don’t know why that was relevant for me to go into that story, but it’s, it’s something that I’m kind of passionate about, like the story of the rise of piracy in, for MP3s and how that transitioned to eBooks and software and other things.
[00:47:16] Brad Nelson: That’s the same argument for Netflix and the Steam market and, and all of those media types.
[00:47:22] Drew Podwal: Yeah, yeah, how do you create a pricing model for Netflix that makes it easier for somebody to just create their own account than to ride on the coattails of their parent’s Netflix account or whatever it is?
[00:47:34] Dom Michalec: But you spoke to something very astute there, Drew, which is we talk about solving problems, jobs to be done.
[00:47:41] How do we solve this problem for someone? In my mind, while that’s helpful, you can even think about it in terms of like how like Teresa Torres likes to talk about it. She talks about in terms of like opportunities, wants, needs, desires, problems, things that we need to take into account to achieve an outcome.
[00:47:57] To me, what’s even more helpful, and you spoke about this Drew, is the aspiration behind the problem. The problem is just the thing in our way to reach our aspiration. But if we have a line of sight into that aspiration, again this gets back to like behavior design, what we’re talking about. If you can clarify the aspiration at the top and break it down into those tiny behaviors to help us reach that aspiration, we’re going to realize that, wow, some of these behaviors are hard to do.
[00:48:20] There’s something in our way. Let’s remove it. Let’s introduce a tool. Let’s introduce a new skill to make it easier to overcome that problem. So the same way that we talk about a product vision being this aspirational thing that everyone should be aligned to, even at the team level. We need to understand what is this team’s aspiration?
[00:48:38] What is in their way? How can we introduce new helpful behaviors, new helpful tools, new helpful skills to make it easier to overcome those barriers so the team can reach their aspiration? There’s a lot of, and I hope, I mean, it makes sense in my head. I can draw this out in my head and I hope it translates well for people listening to this episode, but at the end of the day, everyone has an aspiration and an enduring motivation to do something.
[00:49:03] We need to clarify that. And then break it down into those smaller behaviors and help the teams do the things they want to do and help them feel the success of doing that to reach that aspiration.
[00:49:12] Drew Podwal: You know, I realized now in hindsight that my story kind of poo pooed on this idea of a critical aspect of everything that we do, which is the product vision.
[00:49:21] I love that Amazon requires all product managers to do the postcard from the future exercise. Or, uh, Jason Little talks about how one of the exercises that he runs is he does role playing where he puts two people from leadership around the water cooler and says, I want you guys to envision that you just walked up on each other at the water cooler and it’s nine months from now, 12 months from now, a year and a half from now, or whatever it is, and you guys, I want one of you guys to start off the conversation By saying, you know how we just released this thing and I heard that it’s improving [00:50:00] the lives or doing whatever it is and have a conversation about that.
[00:50:04] And I think that’s absolutely important. One of the challenges I’ve seen and experienced to creating a product vision. Is that oftentimes what will happen is that the C suite or executives will pass the buck down to the product suite to say, go put together the product vision in absence of like OKRs, in absence of business vision.
[00:50:26] And then the product team, then instead of them taking the bulls by the horn, they pass it down to the engineering team to say, hey, what can we build? And then that becomes the product vision, is what can we build as opposed to the way that you’re talking about it, improving the lives of the end users.
[00:50:45] This,
[00:50:46] Dom Michalec: this, this touched on something we talked about last episode too, which is this idea behind scaling leadership instead of scaling process. How often, and this is a. Not a rhetorical question. How often do we lean on canvases and frameworks to help us create sprint goals, product goals, product visions, whatever it may be.
[00:51:06] And I’d say, I’m not here to say like those tools aren’t helpful, but in some cases we, we almost over rely on these. Madlibs, if you will, to help us get to a place where we can articulate something that is inspirational, visionary, whatever it may be. And those help with process. But unless you have someone in the C suite who is incentivized and their whole job is to help create a value engine for the business through products, it’s going to be really hard to get the whole organization to align on that product vision.
[00:51:40] I think that’s why I’m so encouraged by Seeing this role of like a chief product officer make it into the C suite because that person, more often than not, they’re really strong, you know, and again, if they’re really strong at what they do, they’re going to push the context down. They’re going to give the problems that need to be solved down to the teams that are responsible for solving them.
[00:52:00] And they’re going to bring in leaders who, who are also aligned with that and they continue to push the context down. So the teams have not necessarily features to build, but tough problems to solve. Now I’m not going to go out and say like every company that has a CPO or every company should have a CPO.
[00:52:17] That’s not what I’m saying. What I’m saying is every company needs strong leadership. Process can help, but if you’re scaling process and you’re not scaling leadership, you’re in for some tough sliding. At least that’s what I’ve observed.
[00:52:30] Brad Nelson: Definitely, I would say the same. So, kind of back on this Jedi mind trick stance here, what would you do, Dom, if you had this situation where you have stakeholders who are like, Hey, just build me this thing.
[00:52:47] And the vision is it makes me more money or gets me promoted. Um, like what are some, some habits or tricks or things that you could do to try to either draw out this product vision or draw these stakeholders into caring more about what it is you’re
[00:53:04] Dom Michalec: doing? To clarify, Brad, is there a product vision in place already, or is there, is the product vision weak or missing altogether?
[00:53:14] Uh,
[00:53:15] Brad Nelson: probably weak. I think that tends to be pretty common. Like, they don’t realize that their vision isn’t really a vision. or isn’t
[00:53:22] Dom Michalec: aligned to anything. Sure. Yeah, it’s interesting because now we’re talking more about influence than, than habits. But nonetheless, I think it’s still really, really helpful to think about it in terms of not making one person the key decision maker for everything that the product should be or should not be.
[00:53:41] And I, it’s again, it’s easier said than done because usually there is like that one person. It’s like, I employ all of you, go build this thing. And there’s this concept of curl habits. That we haven’t talked about yet, but also from a, from a coaching perspective are really, really helpful, which if you remember the anatomy of a tiny habit is there is an anchor moment.
[00:54:00] There’s something that happens that prompts us to do a behavior. We can use Pearl habits to help us be better coaches in this specific context. Meaning. Uh, when you talk about a Pearl Habit, a Pearl Habit is basically using an anchor moment or using a prompt that agitates you to get you to do something that is a little bit more helpful, right?
[00:54:21] So it’s like, I’ll give you an example and then I’ll get back to your question, Brad, which is like, I’ve worked with some folks who said, you know, I have this habit of every time I hear my… Neighbors car alarm going off. I take a moment to take five deep breaths. So taking something that annoys them and using that as an anchor moment to prompt them to do something that’s helpful for them is really powerful.
[00:54:42] So in this particular case as a coach, we can have these coaching moments, these coaching habits, where anytime I’m presented with a question or a situation where there might be an anti pattern introduced, I’ll stop and ask a question. And quite literally, in this particular case, I’d be like, well, if I’m [00:55:00] hearing that there’s no real true product vision present, therefore we’re kind of at the whim of whoever has the most sway or influence in the room, um, how can I use that as an opportunity to see where we can possibly help articulate a product vision?
[00:55:14] It’s like, well, you know, in this case, like, uh, you know, I need you to go build this thing. In my mind, I like to ask the question, like, how do we know this thing is going to help us generate revenue or generate usage? Not to say like, you know, show your work, I’m not to the fire, but hey, what was the thought process behind this?
[00:55:33] How do we know this is going to be something that helps our business while also helping our users and our customers execute on things that they want to do? Um, and it might open up a really interesting conversation and you might find out that, hey, this might be the right thing to explore. But understanding the assumptions behind the ask and being, and showing deference and not showing like, you know, not sticking your thumb in their eye and saying, ha ha, see look, you made all these assumptions, you didn’t test these assumptions or you didn’t validate these assumptions.
[00:55:59] That’s not what we’re aiming for here. We just want to address the ask and the assumptions behind the ask to see if there’s any risk in doing a thing that they’re asking us to do. So creating that partnership using that agitative moment of this person is really asking me to do something that I don’t think is right and use that as an opportunity to open up a more of a coaching stance and more of a collaborative stance.
[00:56:20] I think it shows deference, it shows respect, but it also helps shield the team from maybe going down a path that is not going to benefit the business or the customers that we ultimately serve. I know I kind of danced around that question a little bit, um, so if I didn’t answer it directly, let me know.
[00:56:36] But that’s, I try to be thoughtful about my response and how I’d approach that.
[00:56:41] Brad Nelson: Yeah, it reminds me a little bit of something that Jason said last episode was be curious, not furious. So I don’t know, I don’t know if I feel like it’s necessarily fully answered, but at the same time I think I get the gist of really just You know, how can we, how can we spark a conversation?
[00:56:59] Drew Podwal: Well, I think, Brad, the thing that I’m hearing here is when stakeholders talk about solutions, we’ve got to build this. What Dom is talking about is the question of why and how will we know that building this was the right decision. And so to me, that’s the jump back to OKRs, like what is the outcome that we’re trying to achieve?
[00:57:20] How will we know that we’ve achieved it? What are the initiatives that we could then do to test this out? And so like, with the Adobe analogy, Adobe could have said, All right, we’ve got to build this entire suite that we’re calling Adobe Creative Cloud. And that by the end of Q2, three years from now, we are going to make sure that all of our off the shelf boxes are removed from the shelves and sent to the shredder.
[00:57:48] Or if that’s the case, if you’re walking into a room where that’s the plan, the question becomes, well, how can we actually bake in a roadmap that enables us to get more information about whether or not this is the right decision earlier? You know, maybe we just released Creative Cloud for one of our products as a test and then If, depending on what we learn from that, we’ll have better understanding of pricing models, we’ll have better understanding of subscription models, we could pivot towards maybe doing the second major product, or maybe what we do is, the next step is, what are the bundles that we can create on this product?
[00:58:31] So, If it’s Photoshop, what are the Photoshop specific related platforms? If it’s Illustrator, what are the Illustrator related platforms? If it’s Premiere, what are the Premiere related platforms? We don’t have to do Premiere, Photoshop, Illustrator all at once, right? Because it’s going to take us forever to figure that out.
[00:58:52] But how do you incentivize that?
[00:58:54] Brad Nelson: Yeah, that’s where I’m struggling too, cause like I totally agree with what you’re saying Drew, I’ve been in multiple situations where asking why, like hey, why are we doing this, or what’s the thought behind this, is like rude to that person, right, it’s a more Tayloristic situation where it’s like, because I said so.
[00:59:11] Drew Podwal: Yeah. And like, I think the only way that I’ve used to work on that is to focus now, what are the risks involved? Right. But that’s, that’s negative motivation as opposed to positive motivation. So now you’re trying to scare that person out of their chair to realize like, Oh, this is going to be a three year long effort.
[00:59:31] That’s probably a project. Um, and it’s because I said, so, well, here’s the reasons why you should care, buddy, that negative motivation factor usually doesn’t work, you know?
[00:59:42] Dom Michalec: Yeah, no, definitely. I think there’s. Again, there may be some nuance here in that when presented with something to build from my own experience, usually when people usually the people who are coming to you from a leadership position telling you that we need to build something where at one point in time, great individual contributors who are [01:00:00] promoted into leadership and think it’s their job to continue to provide solutions instead of problems to solve for the teams ultimately decide how to solve them.
[01:00:08] And that’s natural. That happens a lot, but I’m not necessarily saying like, Hey, we need to put These people on the hot seat and say, Hey, you need to answer all my questions before I, before I say yes to this. It’s opening the invitation, truly being, we talked about like being curious. It’s like, Hey, listen, like I hear you, I hear what you want us to do, but man, wouldn’t it be great if we could collaborate on this and identify the risks to this ask.
[01:00:30] So we both know that we are sure that this is the right direction to go down or that this may not be the right direction to go down. Right. And it’s usually the engineering side of the house. It’s like, They’re the ones who know the technical feasibility behind a lot of these asks. What if we can get to this destination faster by leveraging their understanding of the how, by figuring out some opportunities for the what to get there, right?
[01:00:55] So you have a feature request. What if our engineers can think of us getting to a similar path that you ultimately want behind this feature request faster by building something else? or optimizing something else. Ultimately, I think that’s what people care about. They care less, I would even go as far as that stakeholders themselves, truly, at the end of the day, care less about the features and more about having big wins from a product perspective.
[01:01:18] And they may present that as feature requests. Hey, I need you to build this because if you do this, we’re going to win this 18 million deal. Okay, well, what is the, what is the true underlying problem behind this feature request? Because our engineering team, we’re going to collaborate on this because our engineering team is filled with really, really smart people, probably the smartest people in this entire organization, know the technical feasibility behind what you’re asking for and may be able to get there faster.
[01:01:43] Then both of us are anticipating, so it’s not a no, it’s what is the comments like? Well, it’s a, the one word that product owners need to learn is no. Like that’s to me, that to me is really counterproductive. Why now and why this, and let’s collaborate on this and let’s bring our engineers into the conversation.
[01:02:00] Cause these guys and gals are super smart and they may be able to get us to get us here faster than both you and I are even thinking about right now. Yeah.
[01:02:08] Drew Podwal: Getting back to the Adobe thing, to me, the problem to solve wasn’t let’s enable more women or men and women who want to quit their job and open up their own design studio, the problem was more of a, how can we generate more revenue?
[01:02:23] And the hypothesis is that if we make it easier for more people to buy an entire suite, Or if we’re talking about the piracy thing, it’s a bottom line thing, right? We’re losing money on the bottom line because people are pirating our, our software. How do we create better ways of packaging our software and distributing our software that decrease piracy, that make it easier for somebody to Pull out their wallet than to do something illegal.
[01:02:54] And to me, that’s a problem that gets solved by marketing. It’s a problem that gets solved by finance. It’s a problem that gets solved by, by product and technology. And that’s a value stream in and of itself is a value stream. That’s focused on reducing piracy and increasing the number of small business owners who are purchasing.
[01:03:15] Yeah.
[01:03:16] Dom Michalec: Yeah. How, how can we save our customers money while getting our business? better visibility into future revenue by switching to a subscription model. It’s so it’s aligning those problems. And that’s really difficult. It’s like, how do you align your business problem to your customer’s problem and figure out how to figure out a solution to that that satisfies both?
[01:03:37] Because I think we talk about this a lot. The whole point of a product and the whole point of a product team is to solve tough problems on behalf of customers in a way that works for the business. And I think a lot of businesses have a difficult time articulating how to align those two problems with an elegant solution, because normally we think about our business problems, revenues down.
[01:03:58] Profitability is negative. We know we’re actually losing money per capita per person that we employ. And rarely do we think about, okay, well, how does that problem translate for our customers and our users too? So I think aligning those two problems, ultimately the aspirations behind solving those problems, that’s the genesis of that product vision.
[01:04:16] And that it’s just hard to think about. And I don’t fault anyone for not being able to do it. It’s takes a really visionary leader to think about it in those terms.
[01:04:26] Drew Podwal: Well, if you think about it from the solution perspective, then that’s the solution you’re going to get. Like one of the things that I observed also, when I was trying to figure out the piracy problem in the book publishing space was that, you know, I was looking at.
[01:04:40] other verticals where piracy was going on. And one of the things that always stuck out to me is that, well, piracy for TV shows, it prevents um, ad revenue. And so, if the problem is how do we stop piracy for TV shows, then the solution is stop trying to figure out how to stop piracy for TV shows. But if the problem is a level above that, [01:05:00] How do we retain revenue in the face of piracy?
[01:05:04] Then the solution could be selling product placement within the TV shows. Let’s sell product placement so that people are holding Coke cans or that they’re holding an iPad. And so even if the show gets pirated, we’re getting revenue that way. That was something that we were trying to figure out with books as well is maybe we use advertising in Well, not in books, but like thinking about like from an Adobe perspective, right?
[01:05:28] Wait, maybe they make a version of Photoshop that’s entirely free. And that as long as you watch ads, those ads then give you credits that enable you to either create X number of files or X number of hours using it or like incentivizing, you know, I don’t know. But if the problem is, let’s stop piracy or let’s make it easier and cheaper for a small business owner to buy a suite, then that’s the solution you’re going to get.
[01:05:59] And you’re missing out on the group think tank solutioning of the problem at the higher level.
[01:06:04] Dom Michalec: Absolutely. Yeah. And I think transformation, whether it’s at the personal level, team level, organization level is really difficult. If that aspiration is not clearly articulated and clearly understood by everyone in that context, I think what’s really important to this conversation is in order for transformation to happen, let’s talk about just at the organization level in order for transformation to happen.
[01:06:29] What types of behaviors am I looking for to signal that transformation is likely? If I walk around an office or if I ping people on Slack or, you know, whatever in Teams, Zoom, whatever it may be, and I ask them, Hey, what does the world look like with your product in it? What are people doing differently?
[01:06:46] And everyone can clearly articulate in a line on a, on the same answer. The conditions for transformation are possible. If I’m asking 20 people, Hey, what does the world look like with your product in the world? And I get 20 different answers. I know that the aspiration of this organization, the vision of this organization, the thing they’re ultimately trying to achieve is not clear, but I’m keenly focused on making sure that everyone, even at an OKR level, it doesn’t have to be at the product vision level, but everyone can clearly articulate What the overall aspiration is for this initiative, whatever it may be, it was actually exercise I did with the client last year, um, where we were coming up with OKRs across a program of five, six teams.
[01:07:28] And part of the exercise was to, at the completion of, of creating the objective statement, taking that objective statement and going out into the cafeteria and handing it to someone who you’ve never worked with before and say, Hey, Read this statement. Is it clear what my team’s trying to achieve? No context, no nothing.
[01:07:45] Is it clear what my team is ultimately trying to achieve with this objective? And if they got more and more answers, yeah, yeah, it’s pretty clear. Yeah, you guys are trying to make it easier for folks to forecast how many genes need to be in the Asian cluster by the end of the year. You want to make it easier for folks to be able to project those forecasts.
[01:08:03] Then I know we’re on the right page, and then I know, okay, as we go into like sprint reviews or we go into the day to day, we all are aligned on what this team is ultimately trying to achieve, the aspiration for this particular context, and then it starts to address the things that Brad was talking about.
[01:08:18] Uh, hey, can you build this feature for me? Well, if they know what the objective is, if they know what the overall aspiration is for this context, then we have some benchmark to address that in a way that is coachable and collaborative and not us versus you.
[01:08:35] Brad Nelson: Awesome. You heard it here from Dom firsthand.
[01:08:38] We’ve definitely talked quite a while. It’s been a great conversation. Thank you for joining us.
[01:08:42] Dom Michalec: Absolutely. Thanks, Brad. I appreciate it. And thanks, Drew. Uh, I don’t know. I think between these two conversations we’ve had, I just really appreciate the, the questions, but also the reflection moments. I think it’s as much fun as it is for me to be on here and talk to you guys.
[01:08:58] I think it’s, and I mean this genuinely, it’s also really cool to hear you guys, uh, reflect on things and try to contextualize it and challenge things. I think that. That makes for a really great conversation and, and it helps me clarify how I approach my work as well. So thank you for your questions, but also your reflections on a lot of things that we talked about.
[01:09:20] Thank you,
[01:09:20] Brad Nelson: Dom.
[01:09:20] Drew Podwal: Well, I want to say that the part that stands out the most to me is that the, uh, how many genes do we want to, do we want to see in the Asian cluster? It took me a couple of minutes to realize that you were referencing back the other episode.
[01:09:35] Dom Michalec: Yeah, I guess I was, yeah.
[01:09:38] Drew Podwal: I feel like you’re probably the only product manager in the history of the world to utter those words, um, is, uh, as a success criteria.
[01:09:50] Dom Michalec: Yeah, again, more perspective, more reflection. Uh, and I love it. I’m here for it. That’s great.
[01:09:56] Drew Podwal: Well, Brad, as always, thank you for being an [01:10:00] amazing host here and partner and Thank you for bringing Dom to the table on this, right? Like you guys knew each other and you bringing Dom to the table here. I learned so much as a result of
[01:10:12] Brad Nelson: that.
[01:10:13] I’ve learned from Dom all the time. That’s why I love chatting with him and safe travels, buddy. I know you’re traveling for weeks on end now and hopefully we’ll, we’ll be able to catch
[01:10:23] Dom Michalec: up soon. Sounds good. Thanks again, Drew. Thanks again, Brad. Appreciate the time as always.