Learning product management by managing Nancy Drew & The Hardy Boys

Episode 174 · 42:50 · SRT · archive.org · all Tanzu Talk

Well, hey there, listeners. SpringOne is coming up, our annual user conference. It's on September 2nd and 3rd, right quick now, in a couple of weeks. If you're interested in it, you can go to springone.io. It's all online. You can register and attend for free. Now, in this episode, we're highlighting one of the speakers from there, which we'll get to shortly. So I helped put together the Agile Leadership Track, which is full of all sorts of great stories and actual users, if you will, people going through how they've changed and improved their organization so that they can do software better, run their organization and their businesses better. It's a good track, if I don't say so. But there's also lots about programming, DevOps, site reliability, engineering, SRE, Kubernetes, and all of the stuff you'd expect from a cloud native conference. So again, it's on September 2nd and 3rd. It's online and totally free. If you want to register for it and attend, all you have to do is go to springone.io. So hopefully, you'll show up there and as an example, get to see our guest in action. Also, I wanted to add that the quality of the recording here at first is a little shoddy, just for whatever, the usual nonsense reasons. But then it improves quite a bit, not too far into it. So just put up with the crackliness of it. Well, why don't you introduce yourself? My name is Jen Handler. I am a product management professional. I have been in product management for more than 15 years. I joined VMware as a pivot with Pivotal Labs, and that's how I came into VMware. I joined about four years ago. I joined as a product manager, actually embedding with teams and building software. And then I moved into a group called Agile Practice Leadership Enablement, where I was working with leaders of teams to get the best outcomes from their teams. And now I'm with the services strategy team, which is an internal team that looks after our services,

much like products. In that context, what's a service? A service is one of the service offerings that we provide to customers, consulting services, where we help customers figure out how to use our products, get better outcomes from our products, that kind of thing. So what does that mean to product manage a service? What's that cycle look like? So applying product thinking to a service? Yeah, like you're saying you're kind of on the team that's doing that, I presume, which I hadn't really thought about how you evolve consultative stuff as if it's a product. Yeah. Our team does a bunch of things, but my focus is primarily on applying product mindset to our services. And what this means for me is really thinking about our services like products and figuring out what are the outcomes that we want from each service offering? Are we maintaining service market fit? Meaning, are our services continuously in demand by the market and solving problems for customers? What are the indicators that we look for to note whether or not things are working or not? Make sure that we're measuring those indicators. You know, making sure that we are enabled internally to be able to deliver the most commonly needed solutions through services to customers at any given time. I mean, if you were to pick like one thing, or however many you want, but like, what do you think the primary difference is between like, software product management and service product management? Like, are there different metrics that you're looking at? For the services, we have like, we do have all these end users, and they're our customers. And we have, well, I've been thinking a lot about this lately. So this is very timely. We have our end customers who are paying for our services. And it's possible to think maybe of our users as the people who are actually delivering our services. So we are working to enable our consultants to be able to

deliver really, you know, great services at scale to customers. One of the things that's different for me in in this role is on a software team, you know, we have a team of dedicated people who are dedicated to developing the product, building, designing, you know, doing the work to actually develop and deliver that product. With service management, we have all of these people around the world, who are actually doing the work of delivering the thing. And also, we're trying to leverage their thinking, and their smarts and their feedback based on their experience with customers to improve the way we enable at scale. Yeah, yeah. Yeah. I'm thinking if there was like a diagram of the layers, it feels like maybe there is, I don't know, the layer, the layer lineup is different for who the end users are and things like that. Like to your point, like, yeah, who you're, that's interesting. Yeah. Yeah. Huh. I like that idea. That is fun. Yeah. I find it very interesting too. And I find myself thinking about it a lot on weekends and, you know, coming up with new hypotheses, um, for how, you know, how do we effectively measure service health? Um, there are some obvious indicators like customer experience, like CSAT, and then there are all these other, you know, potential leading indicators, um, and getting those right is part of the fun. So, so what are the, uh, what are the two talks that you have, uh, you know, you're doing them with several other people, but the two, the two sessions that you're involved with at Springwind platform. Yeah. Um, so I'm running a session, a session called what makes a great product manager. Um, and I decided, um, I didn't want to do all the talking. I wanted some other people to help me do the talking. Um, and so I enlisted a little collection of people. Ken McDougal from Kessel Run is going to be

participating in this. And so as Adrian Hensley, who's from the Boeing company and Mike Gresham, who is a colleague at VMware. So, so that's a talk that I'm running. And then I'm in another talk that is around, uh, labs leaders and leadership enablement. One of the reasons that I thought I wanted to do this talk and I thought we should talk about it is because several times in my experience with this organization, I've encountered customers who don't currently have a product management function or are starting to develop a product management function, or maybe like they're thinking thing, they're thinking about things that they need that product management could solve for as a discipline. And, you know, I think it matters a little less what you call the person in title, but just the discipline of it. Um, and so like literally a couple of months ago, I was contacted by a colleague who is, you know, custom customer facing, um, right now saying that she was talking to a customer who is just kind of like, you know, very much in the throes of figuring out whether or not they needed product managers. I think going through the, the experience of going from project to product and, and thinking about how can we get more value out of our software, um, in a continuous fashion and just thinking about whether they needed this or not. So I thought, let's just like, you know, keep it really basic. Like, what is it? What is it not for the people who are, you know, maybe not product managers and thinking that maybe they want to be, maybe they think that, you know, they might need them so that they can kind of start seeing themselves and seeing whether or not they need this kind of function within their org. They sort of like filter out. I mean, just like you were saying, do, do we need this function in the org or not? But then, but then also I would imagine, I mean, and tell me if I'm wrong, that maybe it helps identify those latent functions that people are doing. Like if, if you can kind of say like, this is sort of what

product management looks like, then, uh, maybe in a positive way, this isn't always positive when people say this, but they can say, oh, we've been doing that. Yeah. Like it's, it's very, very possible that, you know, if you decide you need product management and I think like product management is about, it's just, you know, it is the discipline of thinking about whether or not the thing that you're doing at any given time is going to deliver value for the business. It's like, if you're worried about not, you're not delivering value for the business or not making those trade-offs or those decisions in order to, you know, consistently have people working on the most valuable thing, you might benefit from some product mindset and product thinking, but, you know, it could be what we're going to do in this talk is we're basically going to expose what are the responsibilities? What are the qualities of this kind of person? And also talk a little bit about, um, what kinds of like, you know, what roles tend to sort of find their way into product management. I ran a little survey within VMware and I ran a little survey through my LinkedIn network. And I think Ken is going to run a little survey through Kessel Run to just ask, you know, before you were a product manager, what was your title? Right. Just so we could see, because a lot of product managers that I know did not, um, start with that as their title. They started in some other part of the business in some other discipline, but they were kind of doing the stuff or they had a passion for the stuff that is product management. And then, so, I mean, do you have a preliminary idea of what those roles look like? Who, who are the, uh, what are the types of people that kind of, not people, but the types of jobs that end up kind of filtering to product management? Yeah. I mean, and so like through our surveys, we found different things, um, because it was different populations, like not surprisingly than VMware, there were a big, um, a big part of the pie is software developers. And I've personally seen this happen, um, in my time with VMware

and Pivotal Labs. And then out, uh, to my broader LinkedIn network, it was more project and program managers, which is also, that makes a lot of sense to me. I seeded the survey with some titles that I know, I know kind of like overlap a little bit like business analyst, you know, project manager, program manager, scrum master, um, and designer also sometimes find their way into product management. I have, um, certainly worked with a few folks like that, but yeah, they come from, they come from everywhere. It just takes a certain passion for value. Like, am I working on the most valuable thing right now? Like if you are super, if that keeps you up at night, um, and you want to get it right and you want to have the metrics, the measurement, you want to know the outcomes, you know, I think product management may be for you. Do you, uh, stay up late at night wondering if you're working on the most valuable thing? Yeah, I do. I really do. That, you know, that makes me realize like in, in all the years for quite some time as being kind of like on the periphery of, uh, following product management, I don't know if like, I have a concrete idea of the tools of actually finding value, like beyond like, you know, I don't know, really simple things like making money or like, uh, I don't know in, in the, in the case of government stuff, right? Like, I don't know, people can file their taxes or not like, like really binary types of things, but how, like, like what, what is the toolkit for actually putting yourself back to sleep at night when you wake up and, and you want to know if, uh, you're focusing people on doing the, the most valuable thing. Like for example, as an example, right? Like you could say it is valuable for people to not spend a lot of time filing this government form. They could take five hours to do it. And like,

that's not cool. Well, or, or, or, or if, or put differently, is it valuable to get the form submitted in the first place? And what we want is for users to have such an amazing experience with that form. It's short, it's easy that they're like totally doing it. One of the things a product manager needs to do is pull on the strengths of everybody else that they're working with to actually understand what is value. And so it's, it's, you know, people on the team, um, that you're working with directly for us, like in our paradigm of product management, um, on software, you know, we think a lot about design, development, product management, working very closely together to figure out what is the most valuable thing. How can we deliver that in the easiest, simplest way, most efficient way. And can we make sure that users have an amazing experience and they even want it so that we can get that value. And that's kind of like, so I think product managers need to fit. They can't do it alone. They like figuring out what is most valuable it takes. And this isn't really, I don't know if this is a trick. It's just, it takes a lot of conversations and a lot of time with other people, um, and being very efficient with their time to extract the Intel and the insights that we need to understand at any given time and make a decision to go forward and say, this is the thing that we need to do now. One way of finding out what's valuable is what does it take to get a person to finish this process? Right? Like, like we, we may not know what those things are, but once, once, once we get them to finish the process, we've done valuable work, right? Like that's a way of gauging what, uh, what's, what's useful, which that is good. Cause obviously there's going to be no value produced if people don't follow the, you know, finish the process. Everything is just a half

done. Like when I try to get my kids to clean their room. So, so that, you know, that, so that reminds me of one of the lines, I forget which abstract it was, but you know, I think you've kind of hit on it that there's sort of like these lurking, uh, product managers or lurking functions within the organizations that are, to use another L word, they're sort of latent in there. And, and like, I think, you know, in, in, in your experience, like, does it work to sort of pull those roles into product management? Like, like, what is that process like of converting people into product managers? Like, is it, is it difficult or hard or, or how, how do you go about doing that? Wow. That's a big, hard question. And I, I do think I, I have personally worked with like in my time with this organization and worked with companies who were trying to like, you know, one company that I work with that I'm thinking of right now, try to kind of get a developer or was it a developer or a scrum master? I think it was a developer kind of like juggle the responsibilities of being a developer and a product manager. And it failed. It is a full-time thing. Like if you want to invest in the work of prioritizing the backlog, keeping it in sync with the roadmap, keeping it in sync with the strategy, keeping it in sync with the vision in times of change, which is always maybe particularly now, but it's always, it's a full-time job. And also all the communication that goes with that and all the bringing along, particularly in large companies, which are the ones that we tend to work with. Yeah. It's a, it's a lot of work. And so I think like if an organization is thinking that they, they do want this and they want to prioritize, you know, this discipline and some attention to this discipline, they do need to probably create like some space for somebody to inherit the role and the responsibilities. I don't know that you can do kind of product management plus something else. Now I will say a lot of companies do kind of like have the product managers do some of the project

management. This is like super common in my experience with smaller companies. It's a little less common, common with larger companies because, you know, there, there is investment in, you know, project management, program management as a function capacity. They have people doing the work of making sure that the trains, you know, keep running and they run on time. Whereas product managers are thinking about, are they the right trains? Are they just like, who's on the train? You know, what's the quality of the train? What is the composition of the exterior, blah, blah, blah. This is like a super common pairing though, of disciplines that I see. And it's like, I think it's problematic for a lot of people who are called product managers to have to, to manage the two, this sort of project management and the product management. Like it can be a lot of work to just keep focused and keep in sync with like the backlog, the backlog and the roadmap and keeping those tight and having the roadmap represent what is most valuable to stakeholders and to the business. That can be a lot of work. Yeah. It's, it seems like you're creating two artifacts almost. Yeah. It can be very, it can, it can be very easy to get consumed by let's just hit the next milestone. Let's just hit the next milestone. So let's just, and, and all the coordination and work and all the, but have you ever been in the role where you have to do project management? Yes. It's almost, it's actually almost always. It's even, um, at times when I am working alongside a project manager, all those, the, although, um, those have been some of my happiest days as a product manager. Like I, I can distinctly remember like a few companies ago when I had a project manager who I was kind of paired with and I could kind of like, you know, lean on them to make sure trains ran on time and all like this, you know, the reporting and like, you know, all that stuff,

all the communication on like the state of the trains running while I could focus on where are we going with this product? What's happening next and get ahead so we can start de-risking our development. That's like a super important, valuable thing. Yeah. Like, as you were saying, I mean, I, I haven't thought about it in this much detail, but it makes sense that if you have, if you're doing project and product management at the same time, it's almost easier to get people to like you doing project management. Yeah. Right. Because, because you, you, you're very frequently, you can report on meeting goals and dates and things that people are expecting. Whereas I, I assume when you're doing product management, probably pretty frequently, you're telling people that something new has come about and that you have to rethink doing something and things have to change from what they were expecting. Maybe. Yeah. You know, at least it comes up. Whereas I guess the worst case with project management is you're sort of like some other people haven't been delivering on time. Right? Right. Right. Yes. I guess there's a little bit of that. Yeah. You're, you're sort of, you're sort of reporting on, on like some other work that's been doing and you've gathered and reported that stuff because you don't necessarily like manage them. Right. And you don't also don't do the work. And so you kind of just like a messenger. Yeah, that's true. When you have like distinct functions, like project program, PMO folks, they have a stake in whether or not like things are running on time and like dependencies and things are connecting, but maybe less, I mean, tend to have less of a stake in like, what is actually being, you know, developed, but somebody else is focused on that. And that's cool. And that's good. And it's a nice division of labor. The more I've personally been able to get ahead and think about what's next and think about what risky assumptions we might be making about the product that we need to do something about before they actually hit us. And we're actually

kind of like incorporating and taking some action, the better off we are. So, you know, that I think that's been, those are the times when I, I can actually be most valuable with, with, you know, you've got pretty big panels of people on each of these. So how did you go about selecting the people who would be on these talks? I thought, you know, what I wanted to do is I wanted to assemble a collection of people who could sort of paint a very broad picture of like product management, what it is, what it isn't, and provide their stories, which would be not all the same. Like I wanted to be able to share with our attendees some stories that they may not expect of people who, you know, entered product management and how they got there and what, and what brought them there. And I thought this collection of people could do that. I'm not prepared to share my story in the talk, but I guess I can share it with you. Which is that I started as a children's book editor. That was my first career. And where I was pretty much doing product management, my products were books. My product at one point was the Nancy Drew series and the Hardy Boys series. Really? Yeah. I relaunched those for young readers. I didn't know, I didn't know what product management was at the time. I didn't know that I was doing this, but I sort of, you know, found my way into product management. And that's, that part is a little bit complicated. But once I was there, I was kind of like, I've been doing this stuff. You know, I had a few gaps to fill, but, and it was, it was software. So it was like, you know, the, the medium, the, everything changed except the discipline and, and the work that I did as a product manager, thinking about, you know, the packaging, the packaging, the positioning, the pricing competitively, the, the users, the read,

the customers, you know, in our cases, children's book editors, customers were parents, the, the users, the readers were kids. And thinking about, you know, how can I get a parent to, you know, get excited about this book and maybe purchase the book or be excited about the child saying, I want that book. You know, all, all sorts of sorts of things that I had to think about then. And I think about very similar things now. That's exactly how enterprise sales works, enterprise software sales. And I would work with design. I would work with sales. I would work with production. You know, how can we make this book? We think it needs to have an antique-y feel for reasons. How can we make that, that in a super like efficient way at this run, you know, run level? Like we only want to run, you know, 10,000 copies, whatever. Huh? That's fun. So, so does, does Nancy Drew and the Hardy boys, have they always been together as sort of like one in-store unit? So did not in store, but you know, like, like, as you said, you manage both of them and I guess they are kind of similar, but have they always sort of been a group together or did that happen sometime over the years? Oh man, here I need to tap back into like my memory store, but I think like they came from the same company and I'm blanking on the name of the original owner of the franchise, but it was bought by Simon and Schuster. I haven't gone to a children's bookstore in a while. I have two kids. I think I assembled a lot of children's books in my time as a children's book editor. And also now there's, you know, Amazon and all that, you know, stuff. Yeah. And also with COVID. So I don't know where the Hardy boys and Nancy Drew are placed anymore. Are they, are they in the same universe? Like, do they meet each other or are they separate in, in separate universes? In my time, I don't think they ever met each other. Oh, that's too bad. I know, but they totally could. Yeah. Yeah. I mean, I mean, they, they seem like there's, there's not any, any fundamental conflicts between their two worlds that,

I don't know. My, my, my parents loved watching that. So I would watch all of those, the murder. She wrote one, not so much the Magnum PI. I don't know why, but yeah, that's, you know, you, you, I think so far you've come up with a couple things to analogize product management too. They're interesting, right? Like managing, delivering a consultative services and product managing, delivering books, which, which it's interesting. And, you know, especially the, especially the way I think it's a good analogy, bringing together all those interests of the books that you have, right? Like as, as you were, you know, going off, you've got the various buyer and user, the stakeholder and the actual user involved, the parent and the kids. And then, and then, you know, you hit on something that I think is always interesting and in software, it can be all over the map, but it's sort of like, not only what's valuable, but like, what is actually possible for us to produce, right? Like, like, is it, it would be great if we had all of these gold inlaid books that were hand illustrated by people, but I mean, that's obviously that's absurd, but that's impossible to deliver. So, so we're not going to do it, which that's a really good example of like, um, you know, just running with that for a moment. Like, yeah, like company says, or editor or author says, it'll be great if this book has gilded edges and have a leather cover and all this. Why? Like, do we know that people are going to buy it? Do we know? And oh, and by the way, when we do that, we're going to have to hike up the price. This, this middle grade book for ages eight to 12 is now going to be $40. Nobody's going to buy it. So can we do a little bit of research

around this? So the same thing happens software, you're building tractors, whatever it is like this same conversation happens all the time. Are there phrases like that, that when you hear you sort of like, uh, so the phrase in this case being like, it'll be great, or it would be great. Like we're all of a sudden the, um, uh, I don't, you know, the, the, the product manager in your mind starts going like, all right, let's put the defenses in motion. Like I think, you know, sometimes people aren't, um, I think like one of the hardest things for me in my product management career has been getting stakeholders, certain stakeholders and leaders in the business comfortable with their assumptions and excited about doing something with them, right? Like, um, I think, you know, I've worked with leaders who are really super smart about the industry and they actually do, you know, we believe this thing needs to have gilded edges, whatever it is. Like we believe that this software needs to do this, this, and this, they might be right, but they might also be wrong. I can think of one experience, one situation where, um, I was working with a stakeholder who said, we need to have this app, um, be on an iPad for the people who are using it. It needs to be an iPad app. It's got to be mobile. This is the thing. And then we said, okay, cool. And went in and observed these people in their process. I'm trying not to get too descriptive and, um, you know, name and names, but like observed the actual users of this. There was a current application that we were replacing in their workflow and saw that there was no way given their current, like the, the thing that they were doing in their process that they could

actually hold an iPad. Right, right, right. So that was very quick and easy. And I think, you know, what we, our job was to figure out a super quick, easy, painless way to just eliminate that risk and, and sort of like get ourselves comfortable with that assumption. And, you know, our approach at that moment in time was not to call out the stakeholder and say, Hey, assumption, you know, what we say about assumptions. It was just to do, you know, what we were being paid for, which was to, um, pretty quickly be able to dig into that assumption and decide whether or not, like, you know, you know, is he right? Is he wrong? Like, is this actually going to work and, and, and help us actually achieve the goal that we have, which was not about like the ultimate outcome was not, we have an iPad app. The ultimate outcome was something else. The iPad was a means to an end. Right, right. It was a feature request. Yeah. It seems like an example of something you said early on, which is, you know, when, when you're worrying about providing value, like, like one of, one of the, uh, uh, I'm not good with my idioms today, but you know, one of the nice reusable patterns that you can follow is like, um, question assumptions, right? Like, like, I, you know, in lean, there's like the five whys, which might be, you know, two to three whys too many, but, but you can, you can always kind of at least ask one why and maybe two whys to kind of go back, just as you were saying, like, right. Like, why do they need an iPad? Which, which, which maybe even just asking, why do they need an iPad might be sometimes a little too aggressive? Cause it's sort of like, Oh, I don't know. But, but the other way of asking that might be, well, let's make sure that this would actually work. Right. Like, and, and you're reminding me, uh, you know, there's, there's a, there's a story similar that I like to tell all the time, uh, you know, that I just heard from someone else where someone wanted to convert, uh, one of our customers wanted to convert all of the recipes

in a commercial kitchen to be on iPads. And like, you know, the team went in instead and they were like, that sounds great. We're going to go to work on something like to, to phrase it nuancedly. And instead what they found out is that like, that's a ton of work. Yeah, yeah, exactly. And, and, and what, what they found out is that the kitchen staff, they just observed them as you were saying, and they found out that one of the main things the kitchen staff wasted a lot of time on was like measuring the temperature of mayonnaise, right? Like they had to manually go and like, you know, make sure that everything was a good temperature and they had to write it down on a clipboard. And then you got to report that thing. And like, it just consumed a huge amount of time. And so there, you know, I, I guess the, the product manager on that team woke up at night and was like, ah, an iPad's not very valuable. Like if we could like cut in half mayonnaise measuring time and make it more reliable, that would be extremely valuable. And so, you know, I, you know, similar to what you're saying, it's, it's, it's almost like it's, it's good for the, the, the team, the product manager to make sure that when they go into a kitchen, so to speak, or a context that they're solving problems, that one of the first things that they sort out is like, are we solving the right problems? Right? Like, like, are we pointing things in the right direction? Yeah. Yeah. Yeah. Are we solving the right problems? And I think like in, in the story that I shared, it was also, um, a really good, uh, collaboration between product management and design. We were fortunate to have, um, people wearing the hats of design and product management. My role in that situation was to get this business owner articulating, what are the ultimate outcomes? What are the ultimate outcomes we want from this, um, this product that we're developing? Designer's job was to go and, and, and then, and then he, you know, he walked back and said, and here's how we're going to get these outcomes. Okay, cool. Fine. You know, and, and, and take those notes. Designer was thinking, Hmm, that path to get those outcomes. I'm not sure we need to,

we need to dig into this. We need to do some observation. We need to see what's going on because there might be a, another way there. And we might be able to take a bigger step than this business owner is anticipating towards the end outcome. If we don't take the path that he's just spelled out. So, I mean, all this is to say, like when you do have the, you know, when you're in this situation where you have the privilege of working with people who are really like fully wearing these hats, it's really cool. Cause you can like, you know, product management can squarely focus on those outcomes and are we hitting them and, you know, and inspire and excite the team to figure out a faster way to get there, but maybe it doesn't have all the answers, right? Like that is where you need to lean on the superpowers of the other people on the team. Like, I don't know how to build, you know, build something in a more efficient way. I don't see like, well, if we just pick up these, you know, two, you know, wires and connect them, you know, like be almost there. You know, I found a thing, I found a way to achieve the outcome. Kind of like what you, like, you know, in observation, perhaps like design would have said, Oh, look, there's this really burning important problem to solve here. That is just checking the temperature of the mayonnaise. And somebody in engineering might say that it would be super simple to develop some tool to like, I don't know, maybe it's a thermometer. I don't know. Just like, let's just the engineer, maybe the engineer is just like, Hey, I have a thermometer problem solved. Right. Right. And that's, that's super fun. Yeah. And, and, and to, to, to one of the points you're saying, right? Like still, you know, uh, checking the mayonnaise helps you achieve your outcomes or running a more efficient kitchen, right? Like, like the, uh, you know, however, whoever you get to the goal of efficiency is fine. As long as you achieve the goal, you know, so I, you, you're making

me think of one last, maybe, maybe too painfully abstract because I can't nail it down question, but I was talking with someone recently about, man, what? I can't remember, but they, they brought up an interesting point that like one of the dangers that people have, you know, there's, there's the sunk cost fallacy bias thing. Right. And one of the problems that you have when you do a huge batch of work over time is you kind of like commit to this sunk fallacy idea of like, we've spent so much time doing this that we should just finish it, which in my personal life that comes up all the time. Right. Which, which, uh, I don't know, which is something, it's interesting to reflect on sunk college, sunk, sunk fallacy in personal life versus work life, because in your personal life, it's usually like you're sunking your money that's sunk versus in a corporate context. It's kind of like over there or somewhere else, but whatever. But, but it sounds like in kind of these, you know, the two switch around the priority situations, right? Like you have to be really good at getting over sunk fallacy. If only the sunk fallacy of like, I put a lot of thought into this and we should go do it. How do you, how do you with yourself and other people, how do you observe people kind of to put it in a negative way? How do you get them comfortable being like, oh yeah, let's throw out two weeks worth of work. So, so for, for example, let's say someone had done a bunch of analysis of, uh, we are going to have people use, um, iPads, right? Like, so, so we were going to bring this team in here and we're going to have them do an iPad version of the software. Right. So we have sunk some resources into that conclusion. Right. And then, uh, you know, as you, in both of our stories, like someone else comes in and they're like, no, no, no, no, no. I mean, there's something better that we could do rather than just doing your original idea. You spent some time thinking about that and building it up, but we're not going to do that. At least not yet. We're going to do this other thing. And that seems like some mind massaging that takes some technique to get people

comfortable with that. There's a lot of mind massaging. Also that product management, I think does like getting people comfortable with changes and, and yeah, like, so I think what, what you're saying is, you know, if, if, if you, if you were to have a revelation, maybe a couple of weeks in that you're going down a path, or maybe like I have joined a situation and I see things in a different way, you're going down a path. I think, um, you know, what I need to do, and I, I've certainly been in this situation before is, um, first of all, excite the team actually doing the work about it. Um, I think I might want to start there instead of like exciting this picture, but like, typically it's about, you know, you are setting aside a couple of weeks of work so that you can achieve the ultimate outcome. You're more likely to achieve the ultimate outcome so that you don't have like, so that you're not having to set aside 10 months of work and have a 10 month sunk cost later. And like pretty much everybody has had the experience of having that product chip that nobody used. Having it be a shelfware as it were. Yeah. Maybe it took four months, maybe it took four years. Ouch. But like a lot of people that I've encountered have some war story to tell. So I think, you know, it can be very powerful to like it, you know, when you start having folks tap into those war stories, it's, it's pretty easy to shift people to, you know, being excited about, yeah, let's pivot now. Let's pivot now because we're seeing some evidence to pivot. That seems to be always the, um, maybe easiest is, is the good word to use for it. But one of the easier ways to convince people to learn from some new observations and change direction to, to be agile as it were, that's something it'd be, it'd be, it'd be fun to, to think a lot more about that

because I feel like the idea of thinking out multiple different scenarios or to put it in a negative way, how could, what are the five ways this could go bad? Right. Like, yeah. Right. And then, and then the, the other side of that is like thinking about, you know, I, I feel, I feel like risk management and optionality are like siblings almost. Right. And they're almost like, like the, the Janice face thing of, of some similar thing where like, you know, the better you do risk, risk management, the more optionality you'll have. And you sort of like learn after a time that as long as you have like lots of optionality, things will probably be okay. And then even, I think I'm just kind of thinking out loud here, but it seems like if you kind of have like a, uh, what's the word where you've got a comfortable stasis, you're, you've got that sweet spot is the idiom that they use of, of optionality. You can always kind of like throw a couple of weeks of work away because that's just part of building up and verifying the options that you have. And then it's not even throwing. Yeah, that's exactly it. Like you probably learn something in those two weeks, those three weeks, there's two months, you learn something. Um, and that's good. Yeah. It's like perception change, you know, it's not throw away. Exactly. It's a, it's a step forward. It's a learning. We decided something. Yay. You feel more excited about the direction that we're moving in. Yay. Like, yeah. So it's a lot of attitude shift. That's interesting. There's always a lot of fun stuff to learn from product managers. And I, I have a feeling, you know, I've got a, uh, I've got a six year old and a nine year old, and, uh, there's a lot more product managing of their school life going on nowadays. And, and I, and I, and I feel like there's a, everything we've talked about could be applicable there. And, uh, you know, I, I spent, I spent a lot of time also talking with them about how, you know, cause they're, they're learning to do math and reading and, and they're always saying they're bad at it. And I still haven't figured out the convincing way to explain the, like, it's not that you're bad at it. It's that you're learning how to do it. And like, and like learning how to

learning the skill of something, just because you don't do it well for like two days or five years, it just means you're learning it, which is in that whole other confused abstract area that I'm like spilling out on the table here is like, it takes that perception shift of just like, no, no, we spent that two weeks to learn what we should be doing. It's fine. It wasn't a waste at all. I have an eight-year-old and I haven't figured it out either. Like, I don't know. Product management for parents is coming out next year. I have not, not figured that one out. Exactly. Well, I'll have to pre-order that. Well, great. Well, thanks for having our wide ranging expansive thing here. You know, uh, especially thinking about the, the, the composition of the people that, uh, will be on these two sessions, there'll be an equally fun, wide ranging discussion of, uh, of what goes on in the product management world. And I think, I think what's especially nice about them, uh, is that you have people who, uh, you know, have done this in large organizations, right. And have, uh, have transferred over there where, you know, we managed to drum up a couple of stories. I guess if you include the Nancy Drew and the Hardy boys, at least three stories. And I always find that's the most valuable things in these sessions is to hear the, uh, the stories, whether they're very small or big that people have gone through. So that's, uh, that's what I'll be looking forward to. Let's see the sessions are on, oh, they're both on the same day on Wednesday, September 2nd. So, uh, I'll, I'll, uh, anyways. So for those two sessions, I'll put a link to them in the, uh, the show notes, but it's pretty easy to go to spring one.io and, uh, you can look them up. There's what makes a great product manager and also lessons from veteran leaders and the importance of community. Uh, and we haven't really touched on the details of, of both of those and very much in depth, but they're there for you, dear listeners to go, uh, check out. All right. Well, thanks. Well, well, uh, thanks for being on. And as always, this has been Tanzu Talk. You can get the show notes for this episode by going to tanzu.vmware.com slash podcast. And you can look up all the past episodes. If you go to a

soundcloud.com slash Tanzu Talk as well, and we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.