Product Management, with Jonathan Sirlin

Episode 98 · 47:29 · SRT · archive.org · all Tanzu Talk

Now, I know, actually, you probably don't need this. Every time I see you, you're sort of like the paragon of Pacific Northwest Health. But I've been doing this thing. I always want to be a little more healthy. Got a lot of death by heart attack in my family. And I was thinking, you know, I should probably lose some weight. And I've discovered an amazing new program I called Eating Less. And it works. Really? Yeah, it's crazy. It's like you got this little lose it app thing that I used to use a long time ago. And you track your food in it. And it's kind of like a double pleasure kind of thing. Where one, you're sort of, I guess it'll be terrible when I stop losing weight, you know. But anyways, you actually, it works. And then it kind of like services this, I don't know, gnomic cataloger part of my head that wants to like record every piece of data in my life. So you can just record all this stuff that you eat. And then you know how much like salt you add every day. Now, I haven't figured out what to do with that information. Maybe our guests can help us go through some sort of discovery process for what I need to do with all that extra information. But I feel like I'm building up a corpus about my corpus. So that's how it works. Yeah, I'd like to see some charts. Oh, yeah. Yeah. I mean, what's your meat consumption and are you doing vegetables properly? Yes. Yeah. You know, we have in the house that I'm renting here in Amsterdam, we have a, I don't know if you have one of these. We have this thing that's like a steam oven. I mean, and you put, it's like heats up and you put in this big thing of water and it creates steam. It's really weird. I'm not really sure. And the problem is like you steam it. And then as you can imagine, the inside is like a normal oven and then it's just covered in water, which it's really hard to clean. So I don't know if you're just supposed to let that dry out. It seems like one of those things, like if you had a, if you had like a, a deep fryer, like built in to, to your countertop that you couldn't remove, you would use it the first time.

And then you would be like, oh, this was a terrible idea. I don't, I don't know how I clean this, but so that's helping me cook. Before we did this episode, yeah, in like six months, we're going to have an episode. So I've got this giant mold problem. I don't know where it came from. That's right. No, no, I've, I've only, I've only used it once. And then I spent like way too long trying to clean it. Cause you know, you rent the house. And so you're like, I'm, I don't want to destroy anything. Cause I've already got two kids and a dog and who knows what's going to happen. But, uh, then, then I clean it out and I'm like, all right, well now this is like, uh, I don't know, however many centimeters of cubic centimeters of wasted space for the next two years. I'm not going to use this thing. I got to keep it. And it's, it's like, it's like that couch in the formal dining room that's covered in, uh, don't sit on me. That my grandparents used to have, they didn't have the plastic wrap, but it was, uh, they had like velour or something. I don't know. I don't know. I'm just saying, don't get one of those. It's weird. Noted. Yeah. Yeah. So why don't you introduce yourself, uh, guest? You got any advice on vegetables or a steamer ovens? Sorry, I was on mute. Uh, I was just talking for the last six seconds and nobody heard me. Uh, I have a lot of advice on steaming vegetables and a lot of advice on eating less, which I'm happy to delve into if that's what we want the focus of the podcast to be. Uh, but I will choose myself first. My name is Jonathan Serlin. I am a product manager at Pivotal Labs. Uh, I have tracked food in the past. I did the whole 30 in April of this past year, which is like a 30 day eating thing where you like basically only eat things that aren't super fun. Like, and you track, uh, that's what I've heard. Yeah. Right. It's just like, oh, this is, this is a way to eat less and hate food. So you just like, you, you make sure you're not eating any extra added sugar. You don't need any grains. You just eat like protein vegetables and like, that's it. And it's totally uncompromising. Like if you mess up, you have to start again on day one, you like get to day 29 and have a piece of chocolate by accident.

They say you, you have, you're back to square one. You have to do the whole thing again. So I think the rigidity actually really helped me see it through. And my goal wasn't to lose weight, but I ended up losing like 12 pounds and I felt great and everything was awesome. And then the first time I ate sugar after it, I was like repulsed. It was like, like, I can't believe I used to eat this ever, but with enough time, I'm now back to like, you know, normal eating habits. Sugar always wins. Yeah. I'm proud of both of you. I'm in the middle of a 30 day, eat a cookie every day plan. So I'm feeling pretty good to be honest with you. Yeah. Pretty great. That's right. Sirota for life. That's good. A lot of cookies. So, so then, so then before we get to the news, like, uh, you know, you, we, you're in a, you're in the new pivotal labs office in Seattle, right? I mean, maybe not right now, but you've been in it. How, how is it? Give, give us a little, uh, little preview. Uh, I did very nice. I put some pictures on Twitter and LinkedIn and other spots just to kind of show it off. Yeah. It's a great spot, you know, a little more space, lots of natural light. Yeah. In the tallest building in Seattle. So if you do come down, you can stop by. There's a lot of restaurants in there, which is great. A parking lot, which it feels like a bond movie because it's super tight corners. And I'm really scared when I pull out of there, but, uh, yeah, it's a great, it's a great building. Good facility. We keep growing up in Seattle. So it's nice to have that with new space. Do you get, you get that thing in the parking garage where like every time you turn the wheels, it squeaks, I love, I love, I love a brand new parking garage and squeakiness. I guess it may be a parking garage. No, it is squeaky. And I haven't seen a human down there yet when I've been in my car. So I, you know, I'm always looking over my shoulder now because it feels like I could get murdered there, but it's convenient parking. So that seems like a trade off. Convenient parking, high risk of murder. Yeah. You know, that's the trade off we make as adults. So embrace it. We need a chart for that. Well, uh, I, I think, I think, uh, you know, since, I don't know, maybe around since last time we recorded the, uh, the, I guess now annual state of DevOps report

came out run by the, uh, the door of people. And Pivotal was a sponsor along with several other people who were sponsors, uh, sponsors. And, uh, you know, as always, it was, it was fun to read through. There's always, uh, I forget the number except that it's a lot. Uh, and, uh, they do a survey of people and ask them, uh, practices they do and how they're doing. And so you get, I think it's been around five years or so now. So you get a good, like year over year, uh, idea of, uh, how things are going. And they have, uh, as I've perhaps incessantly joked about, they've now matched the, uh, the Marriott, uh, hotel levels. They have an elite platinum high performer. And then also just the power performers, the gold and the silver or something like that. Uh, you know, silver is not so bad, but, uh, anyways, they've got those new things out there. And, and I'll, I'll just say one more thing before, before you tell me, uh, what your impressions were, Richard. But, uh, you know, me being someone who works too much on, on, uh, PowerPoint, uh, the first thing I noticed is that they have it in landscape mode, which is kind of odd. Uh, because it's actually a document, uh, it's not a PowerPoint, but, uh, that's, that's, that's an interesting, uh, my theory, my theory is that everyone is on a big, like 16, nine ratio laptop screen nowadays. So someone actually just had this interesting idea of like, they're going to be reading it on a screen. We should make it fit in the screen. And, uh, I don't know. I kind of like it. I'll have to think about that for, uh, the next document. I, e-document I get involved in, but what'd you think about it? Yeah, it was good. You know, it's funny. You went to the Marriott hotel points when you thought of elite. For some reason, my head went to like, this is like the extreme Doritos. Like now we've moved to like an extreme level where you can't do anything less than that. Like, oh, these are regular Doritos? What am I, a monster? So like now you want to be elite as well in your, in your DevOps, but the numbers were good, right? How much customer kind of support effort time were you spending and how much time are you spending on effects on this elite performance level, which maps like real people.

I thought that was interesting to see that. And also look, there was the number to adopt cloud characteristics, 23 times more likely to be elite. So when you do cloud like stuff, you're more elite in terms of your performance and less downtime and all that. Data, I just finished Nicole Forsgren's book, the Accelerate book, and she's behind a lot of this research. So it's been good. They've had four years of data. They can really look at these trends and put some, I think some confidence behind the fact that this actually does lead to better business performance. Yeah, it's fun. Yeah. I think there's two new sections that stand out for me. And that is one, there's, there's a little section on outsourcing. And that's one of those things where you can just, you know, the butler did it. You just, you just know what the outcome's going to be. Yep. They don't like outsourcing. Generally not cool. There's, there's a whole little like explanation of when it's, it's some sort of outsourcing methods work well. But in general, if you're sort of like sharding yourself out and your functionality doesn't really fit into their, their mold of things. And then I thought the best new part was there was, I don't know, three or four pages, but a sufficient amount amongst the 78 or odd pages of, of talk about like, so what does it actually mean? If you're like a manager and you're trying to create a culture? Cause we all know, uh, we all know in DevOps land, we're supposed to have a good culture, but heretofore, if that's a phrase, there hasn't been a lot of details, uh, about that. And so I think there were some good suggestions in there of things, uh, I don't know what to call it, a culture you would want look like, and therefore things that, uh, that managers or leaders or whatever you want to call yourself, the dungeon masters of digital transformation, like what it, what it is they're up to and what they do. And I think a lot of it revolves around, uh, essentially I try to summarize it, but there's like have flexibility around the rules, which is to say, don't worry about your governance if it's harming the sort of like outcome you want to achieve.

And, uh, don't, don't be, don't be straight laced into that and then give your, your teams and therefore your people, uh, a pretty, uh, pretty large amount of autonomy and how they go about doing their thing, their things. And then there was actually, I always, I always, you know, doing retrospectives and, uh, post mortem fun things always seems like intuitively good, but I've never really thought about how it connects to a, uh, a better culture that much. And they kind of go over how doing retrospectives and learnings, like they don't actually explain it this way, but it kind of adds to a community of, uh, of a nice culture in there. So, so that part was good. And then it's sort of like, as, as you were saying, I mean, you, you, uh, since you just finished reading accelerate, you must've come across one of the last chapters. I think ironically they outsource to some other team, uh, that's basically what is, uh, what is good leadership like? And, um, I don't, there's, there's, I'll have to go back and read, read that and see if there's some interesting stuff in there, but that's the only other place I've really seen a discussion of this topic that's actionable as they say. No, that's right. It was a good focus on learning culture and retrospectives, as you said, so that was definitely useful. So I'll plug, I think in October, early October, Nicole and I will be doing a webinar, uh, on pivotal property, talking about the results of this thing and kind of, you know, looking a little into the DevOps report and actually turning this into action. So mark the calendars. Wait, Hey, Hey, Hey, Hey, Hey guest. What's, what's, what's your take on how like the system is, you know, second order effect of doing retrospectives, like helps out your, your culture and therefore, you know, makes you do software better. Yeah. Um, I think the retrospectives are really good for a lot of reasons. Uh, and I think having a good culture is going to be good no matter how you look at it. Right. Um, I think that the primary reason that you don't have good software development culture is at least in my experience, both in working with clients at pivotal and in previous jobs is that, uh, uh, contributors are, are treated like line cooks. Rather than like actually thinking problem solving human beings. And the fastest way to dispel that is to ask them how they're feeling and listen to them.

And I think that the retrospective not only provides a forum where people can talk about the things that are bothering them or the things that they're liking and like actually convince them that they are an autonomous being within like the cog of the, or within the machine of the, uh, uh, uh, uh, uh, division that they're in, but it also forces leaders to like put something on their calendar that forces them to be empathetic. Uh, and I think that by like actually putting some structure around that, you're starting to put good behaviors and people that can probably do a really good job of that, but just don't have a lot of training or experience in doing it. Like a lot of, a lot of business leaders like get where they are because they they're convinced that they've been right their entire career. And it's like, I make good guesses and good bets. And so now I get promoted. Uh, but like in doing that, a lot of times, a lot of leadership training isn't like, how are you cultivating a team? How are you making people feel? And so like giving them a task to actually say, like, we are going to spend an hour every week where we are just going to listen and like, we're not going to work on actually coding anything. We're not going to work on doing anything deliverable. That's going to, you know, drive more revenue or whatever it is that you're trying to do, but we're just going to listen to these folks. And so like, that is going to be like undeniably good. That's going to make for a better software developing culture. It's going to make for better developers, product managers, and designers that actually want to do their work, but it's also going to increase the trust they have in their leadership that like they have their back. And so they're going to want to do it together. Yeah. That's, that's, that's a good way of, uh, of putting it. You know, it makes me think, I don't, I don't think about it with, is this much, this much muddled clarity usually, but like, uh, so somewhere in our, like how to do software better, like, uh, mythos world of study. We need to like connect to this idea that like, not connect, but we should connect in this idea that like, if you treat people like, uh, humans, things turn out better, like, because a lot of, a lot of these little, these like practices, you know, uh, kind of come down to like, as you say, like listening to people is one of the most humane things you can do to someone as people are always telling me.

And so it's just sort of like, you should just treat people like they're good in work and, and good things will happen, but it's, it's hard to, uh, I don't know if there's a, if there's a donut chart that you can use to illustrate that somehow. I think, I think the DevOps people are always trying that with their Westeria thing or whatever, which, which is fine, but I always find that a little bit more, uh, descriptive of things rather than, uh, prescriptive, if you will. But anyway, so, so, uh, before I chew up our time talking about donuts, you want to, uh, take us through the other interesting news that came out, Richard? Yeah, sure. A couple of quick things. Uh, what was it last week? That sounds right. Was world. And so some, a lot of announcements came out of that. Most of you might've kept an eye on that. There was some interesting partnership news with Amazon specifically kind of more of this hybrid push into supporting their relational database service on via infrastructure, things like that. So I found that interesting as we continue to embrace, I guess, the real multi-cloud world. And then I think it was Friday. That team always seems to ship Friday at five. I think they're, they're messing with us on purpose, but Riff, the next version got released, included some nice bits for installing the latest of Knative. If you're in the serverless world, also had some good integration with the eventing system. So if you want to emit events and consume events from your functions, that was kind of included. So I liked that. And then there was a nice stream update. That's, that's grown into a really popular library for spring. As people want to talk to Kafka and RabbitMQ and now added Kinesis, which is Amazon streaming processing tool, as well as some Spring Cloud Function support. So if you want to have functions spin up as a result of something hitting a message bus, Hey, there you go. There's a whole programming model there. So the neat things around, you know, the Amazon integration with VMware, I like where Riff and Spring Cloud Stream keep going. Constant announcements. Hopefully you all are attending Spawn where you'll see even more about that. Yeah. You know, I've, I've noticed, uh, I used to play, pay really close attention to spring when I was a Java developer, but, uh, since I started paying very close attention to it again, kind

of being around here. And when I was an analyst covering Pivotal, the, uh, the spring people are pretty good at like, uh, predicting which buzzwords they should build a framework around. Now I'm sure, I'm sure if I were to look at it, there would be some buzzword frameworks that never like buzzed or whatever, but there's pretty good, uh, success rate and, and getting things that work out like, like the, you know, the, the, the Riff stuff and then, uh, streams and all sorts of stuff has, it's sort of comes to fruition a little bit of ahead of it. It's, it's always like ready. Yeah. Most people want to use that stuff in, in the pseudo mainstream, which, which is nice. So good job. Yeah, no, it's a good point. They definitely seem, they seem well-tuned in some of that, which is always nice. That's right. Well, well then finally, just, uh, as a self-serving reference. So, uh, I think, I think this week, I think it was this week, like I had, I had a few more little draft excerpt chapters from the, the, the book I'm, I'm always working on that I posted over in medium and I ended my, in medium, they have this thing called a series or as I like to think of it, a Snapchat ripoff, uh, where like it's some card that you click on and it's very confusing. And so I was using that to like a list all the things I have, but I just made a regular post. It's much easier to use than some weird little card thing. Of course. But, uh, I'll put a link to that in the show notes. If you're interested, I think I posted, uh, I posted something about how, like, I guess kind of, uh, apropos to, uh, our discussion here, if we ever get to it. But, uh, like, like whenever you want to start off a big transformation, it's good to start with a small series of projects, uh, it seems like with the people that we work with. And then also there's a, there's sort of a roundup of like, how do you pick this initial team of people? Not only so that you like, uh, succeed at the first project, but more importantly, so that when you're working on project number 30 in a series of 2000, uh, you primed yourself well to, uh, succeed at that rather than, I don't know, not succeed. I guess that's the other option you could middle around if you will, but that said, so guest, what do you do around here? Uh, yeah, so I am a product manager with pivotal labs.

Uh, I worked out of the New York office for around a year and change, and I recently moved to the Santa Monica office. I say recently, but that was like six, seven months ago. Um, uh, and so what I do is I work with clients and I pair with a client's, uh, identified product manager to, uh, help their teams figure out a better way to make software. Uh, and we, uh, work together to identify their goals, uh, identify the product that we think is going to be the best fit for, uh, the outcomes that they're looking for. And then we build it together. Uh, and personally, my main focus is on enablement. Like, uh, the thing about the pivotal labs model that excites me so much is that we're not just building them something that's going to work and then saying, here's your software. And like, it's done now, go home. But, uh, it's really much more of a, like, I'm going to teach this team to fish, right? So that, uh, at the end of this process, the entire team should be enabled to be able to, uh, head home and continue this software project, uh, into perpetuity, right? We don't think their products are ever done. And so what I'm trying to do is I'm trying to help cultivate and build a team that can not only bring the product into success in the future, but also help evangelize and spread some of those better habits back at their company so that the entire team can then, uh, prepare to transform. Mm. You just started sort of making the, the, the factory for making factories as it were. Yeah. We're trying to put ourselves at a business. Yeah. And, and so, so like, I think, I think, well, at least, at least probably, uh, for people who have worked at software vendors, the idea of like a product manager is, is pretty normal. No, no big deal. But like inside of a, uh, a company who does not sell software, let's say whatever it is, they're a retailer or they like sell pizza or insurance or something like to people, to product managers exist as such. You're like, what do you, how do you pull that role out of the, uh, out of the clay as it were and, and get someone to pair with? So I, I, I, and labs, uh, at large believes that there is no successful company that is not a software company anymore. Like, even if you just sold pizza, uh, people are probably not just going to call you to

get a pizza delivered to you, right? There's gotta be something, uh, in either an iPhone app or some sort of web framework that's going to help people get a pizza to them faster. Um, and, uh, you know, there are actually some real world examples of like how we could like address that need. Um, but yeah, so if it's a, if it's a company that has no software development practices and they don't really have any product managers, what we try and do is either identify somebody that has a lot of context and can, uh, act as like a subject matter expert and can at least get us started. And then we can, at the end consider like, okay, is it now time to hire for this role? Or does this person want to transition into this role? Or we just find somebody that has worked with the company for a long time that is interested in exploring that sort of role and just bring them on. Right. We're not prescriptive. It's like, oh, that person doesn't have any product management experience on their resume. We can't take them. Like we will not let them into the building. That's like not how it works at all. Uh, I, you know, we, uh, we identify. Anybody that seems to have any, any level of interest, uh, insight or knowledge that we think that would fit the role well, and I'll just do what I can to enable them. You know, I've, I've worked with people that have been scrum masters for 25 plus years. I've worked with people that have never worked in technology before. The principles are exactly the same. All I'm trying to talk about is like, how does pivotal thing product management, uh, uh, effectively adds to a healthy software development team. And anybody can learn that stuff. You know, it's like anybody can follow a recipe and learn how to cook something. Right. But it's a matter of like, now that we've cooked this thing 12 times together, how would you improvise and cook it on your own next time? So I don't think, I don't think there's anybody that can't do it. Hmm. So what are the, what are the personality traits you look for though? Cause I mean, to some extent, somebody may, anybody background might be able to jump into it, but I'm assuming there are certain types of people that you, you see that they're either kind of naturally inclined to be a good product manager, or do you really feel like, geez, I can grab any sort of person and mold them into it. Yeah. I think the most important personality trait is a willingness to learn and to change, right? Like, uh, if you look at a traditional, uh, project management or scrum master role, uh,

that person is very much like I have my 12 tasks and I'm going to get these things done and I need to get them done by a certain time. And if that happens, I've been successful. Um, and while those things are super important, it's also really important for us to say like, all right, let's question those 10 things that, uh, we are been told that we're supposed to do. How do we validate that those things are true? And how do we then communicate back to stakeholders that like, uh, here's the things that we think are the strongest, uh, strongest way for this product to move forward. And here's what we'd like to do. So anybody that's able to like either break out of their mold of project management and say, like, let's embrace some new techniques here and say how it works. Uh, but if it's somebody that has none of that experience at all, to answer your question, uh, the personality traits, I mean, you, you, we want people that are kind, that can communicate really well, uh, that are, uh, open to listening. You know what I mean? Like a lot of product management, at least in my experience is a lot like being a camp counselor, right? Like, uh, that is the job that I had before this one that prepared me for this as much as anything else. I was in, I was a product manager for like four or five years before I came to labs and I, in some pretty bad environments, right. In some areas that were as like, it was a lot of, I'm checking boxes on Jira tickets and making sure that people get to work on time instead of like actually working with the product. And when, now that I consider myself to be in a really healthy product management environment, I look back at my experience. It's like, it was my ability to like corral 12 children and make sure they didn't drown that day that is actually helping us like helping me be a successful product manager at labs. So somebody that's going to be proactive, uh, somebody that's going to communicate really clearly, somebody that's going to communicate simple things that everybody thinks they understand in the spirit of clarity, somebody that's, you know, good writing skills are a plus, you know, being able to communicate, uh, uh, back to stakeholders about our status. Um, things like that are usually good indicators that, uh, they can then take on the heavy stuff. Yeah, that's good. So what roles then do we typically have make up a labs team or a balanced team, whatever we would like to call it when we work with a partner or a customer, your, you know, products

part of that, but what makes up the team? What are the roles? Yeah. Uh, so the traditional balanced team at Pivotal Labs has been like three pillars, right? There's the product manager who is primarily responsible for, uh, making sure that we're, uh, make building something that's going to help take, uh, take off like the business goals, right? Like, are we doing what the business needs, uh, right now? Uh, and are we validating those things? Uh, and then there's the design role. Uh, the design is not a step in the process. The design is a part of the process, right? The person doesn't just make things look pretty and work well, but the designer's really main focus is to, uh, advocate on behalf of the user, right? Like the designer is there to give me a gut check to make sure that the thing we're building users are going to actually want and use. And then there are, uh, the developers, right? The development team, which is headed up by the anchor is what we call them. And the, the anchor is the person that has like the most, uh, not context, but I guess responsibility for the code base. But what the developers are doing is they're building a really healthy, sustainable code stack that we could either add to or delete from easily, right? Like I trust my developer to make sound technical decisions to help us execute on what we think is best for the business and the designers. And so those three pillars together, like in the Venn diagram, you draw those three circles. And in the middle of those three is like, this is a really healthy product team. Um, I have also worked on labs teams that have a data science component. Uh, data science is like really fascinating and contributes to all three of those disciplines in a very radically different way. Uh, but I think that, uh, we're going to see more and more data science folks, uh, be integrated into that balanced team and become like a fourth important part of what we do. So, so can you, can you give us like a, uh, like an example of like what, like a product you would product manage and like, you know, interesting, like, you know, one, what, one interesting thing that comes up that kind of represents, uh, this is what a product manager brings to the table other than, other than the preventing drowning, which is good. Yeah. You don't want that. Yeah. But like, yeah, yeah.

But, but, but on, on, I guess maybe on an external facing thing, like when you're thinking about, uh, we're building this piece of software or product or whatever that is supposed to serve some purpose. I mean, unless we're just burning through someone's money for fun, but like, uh, it, it, it's gonna, whoever's using the software is trying to like accomplish something, whatever it may be. And so like, what are like the skills that a product manager uses to make sure that happens well? Sure. Um, the skills that we use are, um, manifested in a lot of different facilitation and prioritization techniques. And I'll try and, I'll try and include those as I talk about, like the example that I'm going to choose to talk about, like what we did. So I worked with a very, very large food distribution company. Uh, this is a company that, uh, has, uh, many thousands of employees and many, many different kitchens and many, many different environments all over the country, all over the world, I think, but I think it's mostly focused in the U S uh, they serve food in, uh, college campuses. They serve food in business like parks. They serve food in office buildings. They serve food in prisons. Uh, and for each of those kitchens, they have a standardized way of how they want to make their food, right? A turkey sandwich here should be the same as a turkey sandwich there with some like gradation and like different tiers of like, like we want all the college campuses to be the same. We want all the, uh, like office buildings to be the same. But the point is like, there was a lot of democratization that could happen in the food that they were making and in the process by which they were going through to make that food. And their solution that they came to us was where they said, we had this iPad app, which is going to do all sorts of really cool stuff. And we want you guys to build this. And, uh, it was a really great opportunity and there was a lot of exploratory work to be done. And so our approach was basically like, thank you for bringing us all this research that you want to do. Thank you for bringing us, uh, all these awesome prototypes that you had. Please let us as a team familiarize ourselves with your domain by validating this and by learning as much as we can. Uh, in the app, they had like video training modules for like how to better make chicken

salad. Uh, and they had like diagrams that would show you like where you're putting your food in your bin. And again, the challenge was like all the food bins across these different sites were just totally different, right? So you couldn't be like, here's a picture. Here's where you put all the food. Uh, just do it exactly like this because being in site a would be like L shaped and been in site B would be, I don't know, like a very, very long rectangle or something. Uh, so they had to like come up with a way to actually make it easy to follow without being too prescriptive. And they, so they had all these ideas, right? Like all these things they wanted to do to help, uh, uh, their kitchen workers. And they did some interviews and they had a really good, uh, a pretty good idea. I should say of like what people actually wanted, uh, much better than a lot of clients that come to us. Uh, but what we said was we're going to learn as much as we can. So we identified some sites, uh, that we could go to and actually like show up at 5am and be in the kitchen and watch people work and learn from them and talk to them. So we had a lot of very early mornings where like the software development team was putting on hairnets and like an aprons and we were showing up and we were watching people like who's day in and day out is like show up, clean the kitchen, prep everything, serve food, go home at two. Um, and what we observed was that there are a lot of tasks that they were doing. They were highly reliant on paper, uh, lots of paper binders everywhere. You know, like you had instructions in this binder over here on how to make salads and you had instructions in this other binder over here for how to clean the stove. And like, here's how you effectively, uh, sterilize your steam oven to make sure that you don't like get mold everywhere. And then you, um, but another thing that they had was they had to record the temperature of their food bins, uh, uh, every 20 minutes or so. And this is like a strict health regulation thing was like, do they need to make food that the cold food stayed really cold and then the hot food stayed hot. Uh, and the way that they do that is they walk around the temperature, they took the temperature, uh, and then they would write it, uh, in one of their paper binders. And what we were finding in all of the sites that we were going to was that because of the, uh, pain as it was to like, go find the binder, take your gloves off, uh, and take all those

temperatures. That was something that was falling to the wayside a lot. Uh, they were taking temps and checking it, but they weren't necessarily recording it. And so, uh, I was taking in all sorts of different data points of like, what are the things that we could help improve through software here? And so, uh, the team, uh, me and along with my designer and as few of the developers that would come with us as well, we'd write all sorts of notes as we went out there and then we'd identify different pains and post-it notes. And then I don't know if you guys have been to a lab's office, but there's typically, uh, many, many whiteboards that are just like filled with post-its. Like it looks like a beautiful mind, but like about like much more boring stuff. Uh, and it seems like there's a lot less red string and last. Yes. Yeah. Yeah. And in such insane boards. Yeah. Right. Less string than like a detective's office, but more post-its and like blue painter's tape for like prioritization. And I'll talk to that in a second. And so basically what we did was we identified a lot of different pain points. And like one of those pain points was like, like people don't know, uh, always had to make the sandwich correctly, you know, correctly as per the business. But then there was also like, people are not recording the temperature of their food. And when you do is you weigh out like, okay, so here are these different problems. Like what is the impact of the, uh, the severity of like, I wasn't able to record the temperature of the food versus like, I wasn't able to make, uh, the exact right turkey sandwich. If you're not making the exact right turkey sandwich, that's not good for the business because they could be losing money per turkey slice or like people are going to be dissatisfied if the sandwich is like, uh, not the same from one side to the other. But if you're not recording your food temperatures and there's like ever a health problem and the health department comes and says like, let me see your records. Like you get fined and like you could get closed. And so what the business really wanted was we need more turkey sandwiches and eventually we'll make it easier for them to take temperatures. And so what we did was we went to them and we said, this sounds great. And we're going to give you guys the videos, but we want to start with temperatures because we don't want your sites to close if something goes wrong. Um, and so like as a PM, it was my job along with the rest of the team to sort of synthesize all the different things we were learning and identify like, what's the most important

thing that we should do first. And in my mind, anytime I talk about it, uh, or like if I'm talking to friends about it, they say like, yeah, but that just seems really obvious. Like, why didn't you just like, why is that a whole role? And why did that take so long to get to? And my answer is always like, it's like the more obvious it seems after the fact, the better job we did. Like it is not obvious when you're sitting in it and it is not always the immediately, uh, apparent thing that this is like the first thing that we should do, especially when you're not, uh, only juggling the priorities of the user in front of you, but also what the business needs, like we knew that the business also needed a platform to release videos because their HR team wanted to be able to give training videos to everybody in the field. Right? Like that's a business need that I was weighing against the user need of like, it's not easy or easy for me to record my temperatures. And there's also a business need that I identified there, which is like, you're going to lose a lot of money if you get fined. So the first thing we built that we prioritized our first MVP, our first release was like, let's make it really, really like stupidly easy for people to record their temperatures. And what you do is you do all sorts of ideation around like, what are the many different ways we could do it? And we're like, how about Bluetooth thermometers? Like you don't have to actually write anything down. You just like stick a thermometer and it'll wait two seconds and then go to the next one. Uh, and it turned out that like nobody really was super psyched on like pairing a Bluetooth thermometer every eight minutes. And like that the actual, the chore of getting those two things together was harder than actually just writing it down. And so what we did was we just said like, all right, let's still use the regular temperature thermometer, but instead of writing it on a piece of paper that they're going to lose, let's just make a very, very ultra usable way for them to input that temperature into their iPad. And that was the first thing we built and we put it out to a bunch of test sites. And within a week they had recorded like 600% more temperatures than they did before. And the following week in one of those sites, they had an incident where somebody got sick and the health department came and looked at their temperatures from the prior week and they had it on the iPad right there. And like, that was something that they would have been ill prepared for if that hadn't been done. So like the client comes to us, says, we need a better way to make sandwiches. And we say, we can help deliver on that. But first here's your most pressing need and let's build that software together.

And in doing so, we helped instill some really, really healthy software development practices so that when they were next moving on from Pivotal to go back home and build the thing where they could distribute videos and make these diagrams for how to place your food, they were going about it in a very different way than they would have done before. And I'm still in touch with this client and I've seen the app that they built and it's awesome. And their users felt listened to and they're gathering feedback all the time and they're building this thing that is actively making their kitchens better. So like what I said before is like, we don't really feel like there's any company that's not a software company. You know, this company is not like, they don't make like iPhone apps or games before like this process, right? What they do is they make salad. But now they're understanding that like software is an essential way to make sure that they're making better salads. And so I don't know if that answers your question. That was a very long winded approach. Yeah. No. And I mean, that's, that's, that's, that's, that's a, that's a prototypically in a good way, like great story, right? Especially the part where it's like, uh, I mean, you know, as people like to disclaim, you don't want to say you're lucky this happened, but then you're lucky that your temperature thing was actually very much so needed. Like, oh my God. So that, that, that, and that, that creates a kind of a snowball of like, oh, this is a good idea. Like, like this approach of doing things. And, and, you know, I, I, I, uh, uh, I often, and, and I hear stories like this cause they're, they're, they're good, right? Everyone likes a twist at the end. Right. Uh, which is fun. Um, but, uh, you know, like, like anyways, I hear a lot of stories like this and I wonder like how, so, so before I ask the question, like, it seems like one of the primary things that the team as a whole does, but that, uh, I think probably the product manager with the help of kind of like the designers and other people, if they want to pitch in, but with the primary job that kind of the PM does is sort of like, uh, unmasking the real problem to solve. And, and the way to, to kind of, I think, summarize a little bit of what you're saying is you observe

like the problem space, like, like the things happening and what's going on. And then also, of course, uh, you bring into account, like, what is the point of all of this? And like, what are we trying to accomplish? And all of that kind of stuff. But then I think, I think, I think the angle that, that, um, that, uh, I guess, I guess people would assume sort of like you're saying this happens all the time, but I think it mostly never happens in, unless you're mindfully doing it is, is you find out like the first three problems you thought you needed to solve actually don't need to be solved right now. And it's, it's like something else that you just kind of like stumble on, right? Like, like the temperature. Um, and so, so I wonder, like, as I was kind of rambling at the beginning, I think I hear those kinds of stories all the time cause they're cool. But I wonder if in reality, like, does that happen every single time? Or sometimes are you just like, yeah, you know, a pipe's a pipe, right? Like they need better pipes. There's no mystery or anything that we need to uncover. So that's definitely, it's, it doesn't happen every time. Right. But what does usually happen is like the thing that you thought you needed to solve, you do need to solve, but the method by which you were solving it is actually pretty myopic. Yeah. And like, let's take a step back from this problem. That is a huge need for you and see if there's other ways that we can solve it. Uh, that will also help you solve other problems. Right. Or will more effectively address the root cause, like instead of like putting a patch on the pipe, why don't we replace the entire pipeline or like instead of, or the vice versa, like instead of replacing the entire pipeline, let's just put a patch here and like, we'll solve all your problems. Right. So it's not always that like people come to us thinking one thing and like, we do this anthropological study of everybody that's involved and realize like, actually you guys were wrong. You know, it's not about them being wrong. And it's more about us saying like, how do we more effectively address these problems in a leaner, in a leaner way, or it's in a way that's going to help you solve like other problems as well. Yeah. And I imagine there's a bit of, uh, especially if you use something like, I don't know, a value stream map or a little bit, something more soft and cuddly.

Uh, it's kind of like what you were talking about earlier, where you need to have a forcing function that makes you sort of like do your homework, like sort of, like sort of pay attention to the whole process and not just go in with your, uh, your assumptions about, about what totally solved. And that's really hard. Like, like, like it's really difficult to have clients come to us and for us to say like, it's our job to challenge your assumptions right now. We're putting it on the calendar. Let's do it. Because a lot of them are used to hearing like, yes, ma'am, like you got it. Let's go and build this thing that you want. Right. And that's a huge part of the job too, is convincing clients that like what we're doing is in their best interest and that we are only challenging their assumptions so that we can make sure we're doing the right thing. Um, you know, ideally, uh, the client is already prepped before even getting to my desk that like, that's going to be part of the process. But even when that's the case, there's tons of stakeholders and people within the company who are like, wait a minute, why aren't you just building the thing that we want to build? And like, my response is like, we can do that, but all I'm asking is for some times to make sure that that's the right thing. And then they'll say, I already did that. I'll say, I know that. And I'm like, I hear you and I'm sure that you're right, but I don't know enough about it yet. So let me learn about it and validate it at the same time. That's really hard because, you know, these engagements are not cheap and like people want to make sure that they're not wasting their time. And so like part of the education at the beginning is, is showing that it's not a waste, that even if you come out with the same outcome, it was for a good reason. Uh, but that's tough. So, I mean, that is a great story. And as I think about that, I was going to ask you kind of follow up of how you do the convincing. I think you explained that pretty well, but how do you keep showing that ongoing value during, I think you kind of described during these processes, like product doesn't disappear. Like you're, you don't disappear once you incept the plan and move on. So what are you doing over the lifespan of that? Are you continually doing different experiments or trying to figure out what the priorities are for the next sprint of work? Like what do you do over the life cycle of one of these more extensive projects? Yeah. Um, so upfront is this big discovery and framing process where we're learning a ton.

Uh, like that is three weeks of going to kitchens and learning that temperatures are the most pressing issue. After that, I've written stories in my, in my backlog that can start to address that. But my next thing is like, all right, when the developers are done with those stories, what the hell are we going to do next? And so I'm now going back out into the field or doing more interviews or doing whatever it is I need to do to discover what's coming next. And that's not just me like plucking ideas out of thin air. That's me constantly evaluating and reevaluating the software that exists or the questions I didn't get to ask last time. Um, when you have live software, you can also take analytics and data from you, from the way people are actually using it to, uh, inform those decisions and course correct anything that you've built. And then the question becomes, how do I prioritize those things? Because I'm not, you know, I'm not waiting until everything's done to release it. Like in an ideal world, I'm releasing things to production constantly. So my decisions matter because the thing that we're doing next is actually going to lie that people are going to use it. So are we, are we spending our time and money most effectively, uh, to make sure that the next thing that's going out is very, very valuable. Um, so it's just another, it's, it's another more miniature, miniaturized cycle of, uh, of learning and discovering and prioritizing and then making decisions. Um, and the way I convince stakeholders that that is valuable is just by presenting as much evidence as I can. Sometimes the evidence to provide is just that our developers are happier than they were before they started working with Pivotal that like, that they like pairing and that TDD is like making for a better code base and that the team is happier because we're doing weekly retros. And if I can say like, we're still learning a lot, but your employees are happier and the enablement is going well, then that can be enough for them to like say, all right, like keep going. Uh, but ideally I'm showing evidence of like, these are the 10 interviews we did this week. Here's what we learned. You know, it's remarkably difficult to actually listen to customers and Pivotal designers do such an amazingly good job of it that nine times out of 10, the business, no matter how good they have been doing a job of actually talking to users, like we're connecting with their users on a different level.

And so what we're showing is hard evidence to show them things that they didn't know was actually happening before. And so that's enough to usually get us enough clout to keep going. Yeah. I mean, it sounds like obviously the listening aspect's huge. So where does it ever go wrong? And maybe not for us because we do it quickly each time, but where, uh, where in general does the product management process sometimes veer sideways? Like when does a PM, where do you have to course correct because something didn't go right? Yeah. Um, usually I have a bias as a PM to listen to the user more than to the business. And that's a problem that I'm always working on. Like if there's a business priority for good reason, that carries a lot of weight, but it took a long time for me to, to actually realize that and acknowledge that like a lot of times business leaders want to do things just because they said they were going to do it eight months ago. And if I'm sitting there and I'm saying like, the user doesn't actually want this. And if I convince them great, but if I don't like, it's still a business need to build that thing. And I need to take that seriously. So PMing for me can go off the rails when I, uh, am trying to convince the business that what the users want is more important than what they want, rather than striking the balance between those two things and saying like what the users needs is super important, but also I understand that you have deadlines and budgets to fill and projects that you promised you'd deliver. And so like, we can also help with those things as well. Yeah. That's that we, we should have you back on to, to talk. You may make our job easy. You just explain. Yeah, sure. But, uh, you know, I, I think, I think you're hitting on like, uh, just to, just to sort of get to closing out, like something I'm always fascinated with, which you alluded to there, which is the, uh, the, uh, sometimes to do the right thing in a business, you have to do the dumb thing. Right. Which, which, which, and I think oftentimes it's just a straight up dumb thing that does harm. But sometimes it's a wise decision to just like, as you say, we said, we were going to do this eight months ago. And if we don't do it, people aren't going to trust that we can't do anything next week. Right. Exactly. Yeah. Deliver this thing. And maybe it's nice too, but yeah, I was thinking, you know, uh, I've been waiting for

my kids to have a cameo as we record this, but I think so far everything's going well. We should get you to go a product manage, like the parental controls in the iOS world, because I feel like maybe none of the people at Apple have kids. They don't quite like, uh, understand what's going on there, but it'd be great. We can find the real problem. Uh, yeah, I don't, I, uh, I will choose not to comment on the state of iTunes and Apple product management over the last like five years, but just to go back to something you were saying earlier, uh, about like, sometimes it's not the dumb thing to do with the business themes. Like I just want to reiterate that like, there's a lot, like there's a lot to be said there. And like, I don't want to carry hubris into every conversation with the business and say like, you guys don't know what you're talking about. Cause there have been plenty of times when a business has said, I want to do this thing and it's not apparent why. And then a year later, you know, their experience in the field has made it very clear. It's like, oh, okay. I see now why that was a smart thing to do. It's like balancing those two things. And, and I mean, I mean, your, your temperature example is a good example of that, right? Like it seems like it's, it's, it's a, it's a classic, like a pea and the princess thing, right? Where it's just like, who, who knew that would be such a big deal, but now we didn't shut down the operation. Right. Exactly. Yeah. The kitchen's still open. That's right. Well, great. Well, well, well, uh, this is, this is great. Thanks for being on. Like I said, we'll have to, uh, we'll have, we'll have to have you come talk to us more about product management stuff. And I think, uh, I, I think, I think what's most valuable is, uh, just hearing the, uh, the stories of what's happened or not, because it all, uh, it all sounds so simple when, when, uh, you read some fancy book on it, but, uh, I guess, I guess if you're having to stick a hairnet on, that's, that's where interesting things happen. That was not something I had expected to ever be doing in this job, but I was very grateful for the opportunity. That's right. That's right. Well, uh, well, thanks again for being on. If, if people want to, uh, I don't know, follow up with you or like pull on threads of this more, what, what would you point them to? Uh, they can, I have a Twitter account that I never look at or use, uh, J S I R L I N.

They can hit me up there or they could just, uh, email me, uh, at the same handle at pivotal.io. I'm always happy to chat. Sounds like you're using Twitter, right? Yeah, right. Yeah, right. Right. Just a thing to have and not use. That's right. That's right. Well, uh, as always, this has been Pivotal Conversations. If you want to find the show notes for this episode, we post them about every Thursday or so depending on how well my memory is working. And those are posted over at pivotal.io slash podcast. And we got the, uh, the back catalog. I think Richard and I have been doing this for about 23 years now. Does that, does that sound about right, Richard? At least in cloud years. Oh, yes, that's right. That's right. In cloud years. We're, we're on the hockey stick years. Uh, but anyways, if you want to find the, uh, the back catalog, uh, you can go to soundcloud.com slash Pivotal Conversations. And with that, we'll see everyone next time. Bye-bye. There, see, now you can hear him.

Tanzu Talk · 🍕 Get more pizza.