So funny story about the title of this talk. I first gave this talk, and Dev Ops says Charlotte earlier this year. And at the time, the web page I used where I listed all my talks, this talk title was so long that it jacked up the alignment of all the other talks. But I feel better having seen some of the other talk titles at this event that I actually have probably maybe the shortest talk title. So that's all right. So yeah, we're going to talk a little bit about how we can apply product management practices to things we do in IT that are not traditionally products. How many people saw Pete Cheslach's talk yesterday? Just out of curiosity. So Pete talked a little bit about going from ops to product, and mostly I think, according to Pete, the only thing that matters when you're a product owner is you don't have to have pager duty on your phone anymore. But there's a little bit more to product management and product ownership than that, and we're going to talk about that a little bit. So a little bit, you kind of already heard most of this. So blah, blah, blah. So yeah, the thing about this though is, yeah, I still do have a license plate that says DevOps. I no longer have a car, but I still do have the license plate. And one of my proudest moments was when Patrick Dubois, who founded the first DevOps days in Ghent, included a picture of my license plate in one of his presentations. So I'm kind of a nerd. So yeah, everything else you already heard. That's great. So before kind of getting into this nitty gritty, I want to tell you a little bit of a story about how I got here, and here not necessarily here speaking to you today, but got to these ideas that I'm talking about. So I'm originally from Chicago, as you said. And in Chicago, we've built some amazing things. I say we. I had very little to do with any of these. But you kind of know how that goes. It's sort of like a sports fan. We say, hey, we won the World Series. I had nothing to do with that. By the way, we did win the World Series in 2016. However, we always used to say that after the Cubs won the World Series, it would probably be the end of the world. And yeah, politics. So the thing is, some of the things that we built in Chicago seem a little weird from the outside, like maybe the way that we do pizza. Or as John Stewart said, casserole. The problem is that we also tend to get rigid and dogmatic about those things. We feel very strongly about our sports teams, like the Bears and the Bulls. And when we become rigid and dogmatic about these things, we run into some challenges, right? And so we talk about this. I've worked in a lot of traditional IT shops. There's a lot of insurance and finance in Chicago. And if you've worked for a long time in tech, especially in ops, in the Chicagoland area, you've probably worked for big financial companies and big insurance companies. That's what we do. It's Chicago. It's the Midwest. We're the salt of the earth, et cetera, et cetera, et cetera. You know how it goes. So one great thing happened, though. I went to work for a company in Chicago called Apartments.com, which was one of the most at the time well-known e-commerce companies. It was kind of the big startup story of Chicago years ago. And I got this opportunity while I was there to meet someone named Marty Kagan. So when I was working at Apartments, they brought Marty in to talk to our product folks and to our developers about how we could approach product management. So Marty, if you're not familiar with him, he's very well-known. Many people remember a little company called Living Social. Used to be a thing, kind of like Groupine. Yeah, they're dead now. But they were cool once. Marty did some consulting with them. He's written a lot of really great books about product management. And so they brought Marty in to talk to our software engineers and talk to our product folks about how we could manage our products better. I'm not quite sure how I got invited to this two-day session, because I was running tech ops at the time. But it was super-duper eye-opening. It was the first opportunity I really had to think about how product management worked, how product ownership worked. He talked about multi-track, how they do things at Google. Again, from a product perspective, I knew a lot about how, from a technology perspective, other organizations did things. But I didn't really understand how products worked. So the idea that I'm giving you here is that your IT services can be products. In fact, not only can they be products, they are products. We tend to think about our services as processes or ways of doing work. Well, everything is a way of doing work. Everything is work. So we could think about this. Think about something like Lyft. So we would say Lyft is a product. But it's not a CPG or consumer-packaged goods. It's not something Procter and Gamble sells. It's a customer experience. Yes, there's software that plays a key role in the product that is Lyft, but there are tools and there are humans. Those are all the things that make up the product. Sounds a lot like services that we provide within technology, within our organization. So you have customers, right? If you don't know who your customers are, go figure it out. Well, wait. So recently, a very good timing of this, we wrote there was a post on the PagerDuty blog by Marguerite de Troie Masson. I'm really proud I got that right. We have a lot of Canadians working at PagerDuty. And so she is the product owner for SRE. And so there was a blog post about what she does. And I was like, this is fantastic timing because I can totally steal stuff from what Marguerite talked about. And what she'd said was that, again, rather than focusing on a product that we ship externally to people who give us money for PagerDuty, she focuses on internal development, things for our internal development teams. And so what she does is the product owner for that, she sets a direction of where the SRE team is going and what initiatives they'll be taking on to improve the lives of PagerDuty's developers. So the exact same practices that we follow at PagerDuty for the product that people give us money for to wake them up in the middle of the night is the exact same process that Marguerite uses to manage what the SRE team is going to do. It's key. She is not the manager of the SRE team. She is the product owner of what the SRE team does. So let me talk about some examples of some things that you can productize. I'm not sure that I spelled productize right. I'm also not really sure that it's a real word. But go with me here. We invent new words.  So service requests. Just the things people ask you to do. Hey, guess what? I need my password reset. I know that doesn't sound like a product. But the thing that has to happen is deployment of things. I know we're all in the cloud and stuff like that. But there's still a lot of requests that come in. Software delivery process, the way that you actually deploy your software itself can be a product. It has consumers and customers and features. And then also maybe your infrastructure is code. Your actual, the things that make up your infra, those processes and the components of them are products. So I need to explain something before I move on. So I gave this talk initially at DevOps Day Charlotte back in February. And one of an initial fellow developer evangelist named Emily Freeman was speaking at the same event. And a few days before the event, she had posted on Twitter about how supportive her mother was of her on Twitter, that every time she would tweet about something cool she was doing or a cool event, her mom would always, that was basically the only reason her mom had Twitter, was to go and be like, hey, Emily, that's basically to like all of her stuff. So of course, everybody else in DevRel who knew Emily was like, oh, well, now we're following Emily's mom and blah, blah, blah. And so I decided to say, well, of course, this means I'm going to feature Emily's mom in my talk in the next week or so. And this is the tweet when I pointed that out. I ran into a little bit of a problem a couple weeks ago. I said, OK, I'm going to go to this talk in Boston. Emily's not speaking there. There's going to be no context for who Emily Freeman is. I need to remove the references to Emily's mom. As you're about to see, the references to Emily's mom are actually very integral to the flow of this entire talk. So just bear with me that this is there. So now you know the backstory of it. So we can all pretend that that exists. And if you really take a look at that, if you want to take a picture of that and you want to follow Emily's mom, she's I think Patricia G Freeman or something like that. And I'm sure she would love a whole bunch of more DevOps people to follow her on Twitter. So do me a favor. For the rest of this talk, even though I'm sure you can think of 100 reasons why what I'm about to suggest would never work in your organization. Just humor me. Let's pretend that it will, just for like what? I don't know, like another 20 minutes or so? I mean, you can do that. It's not asking for very much. I mean, I've done that in my backstory, my background to give the example when I was first learning about this whole crazy DevOps thing. The way I learned was by listening to podcasts. And one of the first podcast episodes I listened to was from a show called DevOps Cafe. And they had a gentleman named Jess Humble. And he was talking about the ideas of continuous delivery. Bear in mind, I'm working at an e-commerce internet company called Apartments.com at the time. I'm listening to it, listening to the concepts of continuous delivery. And saying to myself, that would never work here. And then as I'm literally saying this out loud, driving in my car on the Eisenhower Expressway, yelling at Jess in my radio, he explains that they do this for HP LaserJet firmware. And I sit there and say, oh. So like I'm saying, bear with me just for a few minutes. We don't have too much longer. Pretend that it will work. Emily's mom is watching to make sure that you do. You see how I couldn't get rid of this slide? So the thing is, yeah, as I said, she's not really watching. She doesn't even know this talk is happening. But as you know, I did threaten to include it. And if we start lying on Twitter, what good will that platform be? Bear in mind that at least half of our ideas are going to fail, for example. And because of this, this is why roadmaps are bad. And if you have one, you should feel bad. I'm going to explain this a little bit more. The product owners at PagerDuty did not like this slide when they saw that I put it up there. So there's a little more nuance to it than this. The problem with a roadmap is it presumes that you can see the future. How many people here can predict the future?  All right? Now it's OK to make plans, but our roadmaps are not things that sit there and say, this is exactly what we're going to do.  So we're used to working in projects in IT, right? We're going to have the service desk revamp project or something like that. The problem is projects are output based. They're like, look, I made a thing. Yay, right? Look at how many things that we made. But those things don't matter. What matter are business outcomes. I can't stress this enough. If you remember nothing else from this talk, remember those two words, business outcomes. And we need to think about how we're going to do discovery. Discovery is hard. You know why? Because our customers don't know what's possible. This is the obligatory Henry Ford. If I asked my customers what they wanted, they'd ask for a faster horse, right? So discovery is a very challenging thing. It's probably one of the hardest things to do as a product owner. Let me put it this way. It's one of the hardest things to do well. It's very easy to do. The way you do it easy is say, hey, what do you want? Oh, OK, cool. Or do you want this? Oh, yeah, you do. Right, right? So the things about discovery are it's always happening. Discovery is not a phase. It's not a stage. You are constantly doing discovery about your products. That's sort of that fast feedback idea. But you're always looking at what matters. It's not just for your boss or fancy pants, architect, title people. Everybody involved is doing discovery. We talk a lot about not having silos in DevOps, right? The idea is there's no special sauce about because of your title, you can do discovery better. In fact, the more connected you are with the product and developing it and implementing it, probably the better you are at discovery because you know some of the questions to ask. And it's not just saying, yo, what are your requirements? That's how we used to do things. That's requirement-based development. There's nothing to do with discovery there. That's sort of just doing things that someone asked for. And that's providing very little value. So when you're creating a product, you need to establish compelling value. And this is tough. But without doing this, guess what? You're screwed. If there isn't a compelling value to your customer, be it software engineers on other teams, your help desk, et cetera, nobody will use your product even if they're told to use it, right?  If the only way you're gonna get people to use your product is because their boss told them they had to, they will be compliant if they have to do it, but they will do everything they can to not do it. You have to provide compelling value to your customer. This one's hard. Use your experience over engineering. We like to solve problems, don't we? We like to solution here.  Okay. But user experience matters so much. And user experience is not user interface, right? It's not CSS and clicky buttons and radio buttons and everything, right? This is, what is it like for the people who will be using your solution? A lot of these people are gonna be spending hours and hours of every week perhaps with this. Think about what can you do to make it more delightful for them? Remember, most of your ideas won't work out. That is totally okay, right? You gotta know, as Mark Andreessen says, he's like, you gotta know what you don't, not even what you don't know, what you can't know. We can't know everything. In fact, we can't know most things. I like this one too. You're gonna test our feasibility during discovery. And what does this mean? It means build or implement as little as possible during your discovery part of your, while you're thinking things through. For processes, oftentimes just role-playing workshops with your customers, right? Experiment, walk through stuff on paper. Good example, like if we just sort of think about the traditional Agile adoption, right? The last thing you do, or actually the wrong way to implement Agile in your organization when you're getting started is go by rally. Nothing against rally. Start with post-its, right? Start with role-playing. Start with the smallest amount because you're just testing feasibility. This one's very important. What looks interesting up here? People have heard of MVPs before, right? And most people think it stands for minimum viable product. Marty Kagan will tell you it stands for minimum viable prototype. They are unfortunately named when we call them a minimum viable product. And MVP is never something that should be considered anywhere close to production ready. It's just something to get there to try out to get a feel. It's the minimum amount you need to see if something is potentially gonna work. The reason in regular products that you sell this is important is because it keeps your sales folks from selling something that is never gonna happen. Here's a bad example of an MVP for an internal IT service or internal IT process. We're gonna create an MVP of our Chef implementation. We'll do this by installing the Chef client on 1000 nodes and then we'll write an MVP cookbook that checks to see if a file's there that we're used to seeing. This takes us a long time to get to a point to even see if we learned anything because installing Chef on 10,000 nodes is not gonna be instant. I mean, Chef is awesome. I used to work there by the way. But it's gonna take some time. This is not the smallest amount that we can get. Not only part of the reason I give this example, this is a real world example. I had a customer and I said, what is your goal of this implementation? And they said this and I said, your goal is not to install Chef on 10,000 nodes. That's my goal is to get you to install Chef on 10,000 nodes. But what's the value? So think about your MVP as a smallest prototype required to answer the question we need to know now. And again, know the business, right? As always, anything you do needs to service your business.  You could be a nonprofit, you could be whatever. But the company, the organization, we have to service that. How does this product you're creating service a business outcome?  Know your customer. Why do they do what they do? And what exactly do they do, right? Like these can be hard questions because we think we know, we make assumptions about what certain roles do. And you wanna know how you can find this stuff out? You gotta talk to some humans, right? Just do it a little more pleasantly than the Bobs did, right, maybe. The suspenders might work for you, I don't know. Always be gathering feedback. Maybe not in this way, but make sure you're getting some kind of feedback. You always wanna know we're continually improving. Again, we're always doing discovery. In any given sprint, assuming that's how you're doing work, you should have just as many discovery related stories or work or whatever you call them, as well as delivery ones.  And then every time you find yourself saying, what if this happened? Or what if we hit this corner case? I want you to imagine Samuel L. Jackson telling you that he doesn't wanna hear about any Monday to Friday ifs. You can fill that one in the way that you want to. I've had that experience quite a bit with customers of mine were like, what about this? What about this? What about this? And you'll never get anything done. And remember, you know why? Cause you're never gonna be done. And that is okay.  She is rooting for you. And I am rooting for you too. So I think we might have time for a couple of questions if anyone has any questions. Yes, what I will recommend, so the easiest way for this. I'm sorry, thank you. You think I've never done this before. So the question was other than what I just learned in the last half an hour, I don't know anything about making a product. What are some good resources to get started with? What I'm going to direct you to because it's the easiest way to do this right now. So Marty Kagan has some great books. I have these slides and some resources around them will be available if you go to mattstratton.com slash speaking. They'll be up in, I don't know, an hour or so. And you'll be able to see the slides. And then if you look at the preso, there will be links and I'll have links to some of Marty's books as well as some other items. That's easier than me kind of repeating and everybody mad scrambling to write it down. So I have a question. When you think about the additions to efficiency and velocity and quality that can come from implementing a lot of the delivery infrastructure around DevOps and CICD, a lot of that stuff seems to be kind of inherently understood to be valuable and potentially giving back a lot of time to the people that are going to be executing a lot of those efforts and activities. So how do you fight against organizations just kind of like mandating that? Because they all understand that it's going to be beneficial, but that might absolutely skip over that process of discovery with the actual people that'll be benefiting from this product. Right, when you run into this scenario of when things come from a mandate, right? For example, where it's saying, this is just someone in the organization up here has decided this will work. So we're not really doing discovery, we've just sort of decided. Right, and I think most people will agree that in a lot of cases what you're trying to achieve with DevOps can be very beneficial to your software delivery application delivery organization. So they might just skip over the whole discovery process with the folks that are actually going to be. So those are the people that should have heard this. I mean, when you're in this scenario where you're not being brought in on it, that's challenging, and that's a whole different conversation on managing up, which we don't have a whole lot of time to talk about. But what ends up happening, though the outcome of that, and this is the bummer, is a difference between people being committed versus being compliant, right? So when you have the scenario of that, that the folks who are the customers are not involved in the discovery and in the implementation, not the implementation, but are not part of it, they will be compliant. The compliant person does what they're told, but they are not committed. And a big part of whether or not, even if you aren't able to involve them in discovery, but being able to be transparent about how, because again, you can't necessarily involve everyone, but that's a whole different talk that I have that's about that, but it's a challenge. So as a, if we're gonna be delivering products, is a product owner requirement for this? Because internally we've had a debate on our team, do we need a product owner? We're at DevOps, mostly focused on DevOps releasing application support type team. So do we need a product owner for our team or not? Has it been a constant debate? My advice, I would go to the well-known and respected philosopher Ron Swanson and say, never half-ass two jobs, whole-ass one job. So my advice is as much as possible, a dedicated product owner, because it's very hard to do more than one thing well at the same time. Now, what you can do in a scenario where maybe, again, not everyone has a luxury of the staffing to say like, yes, of course, we have a product owner and that's all they do. I have seen this work as a role rather than a job, which would say maybe you have someone on the team, it's a passing along thing, which is, okay, for this month, Joe is the product owner, next month, Sally is the product owner. And maybe because again, you don't have the luxury of having someone work as an FTE doing nothing but being a product owner, someone has to wear that hat though. It can't be all by consensus because product owners have to make decisions. So if you're going to do it where it's not someone where it's their, I need to say title, but it's their FTE job, I would do it as a role and I would rotate it around within the team. I've seen that work pretty effectively. And if people aren't good at it and they don't wanna do it on the team, you're like, you don't force people to do it because it is a skill, right? So you may say, hey, we've got four SREs on the team and Joe just has no interest in doing this and he probably wouldn't be very good at it. We're not gonna make him do a rotation of it. And I would experiment and see how that goes, but it's challenging when you have someone where they have to do more than one focus, for sure. I'm not a product owner or a product manager. So some of the terminology I'm guessing at one of them is discovery. So I'm trying to understand what discovery is at what layer. I'm the person who's sitting there coming up with the ideas, writing the proposals or the code or whatnot. So discovery for me is constantly, oh, there's this idea, is it worth pursuing? Is it worth looking at? Versus what do you mean by discovery at a product level, at an organizational level? I think, I don't see how discovery can possibly happen because you've got committees. Well, that's part of the problem, right? Is part of the discovery is, and again, I'm gonna oversimplify and say you'll find some references to this and some of the links I talk about, but you talk about the 10 cues in product, which are 10 questions, because you're asking, that's discovery about is this a product? Is this a feature? Is this something we should do? So again, it's thinking about the things that your product owners who are building your features, what are the things that they do when they do discovery to decide whether or not we should do a feature, whether or not this is something that is gonna be competitive and helpful for us in the market and our GTM. So I would do the same, the discovery within an IT service is a very similar thing and a lot of it has to do with continually going back to your customers and finding out how things are going. That was sort of a little part of discovery is the feedback, where I kind of my joke about the NPS score of the Jenkins thing, like you won't necessarily do it that way, but you should be always collecting feedback from your stake, whether you call them stakeholders, your customers and say like, what's changing with what they're doing? And part of that discovery is not just asking, are you happy or what do you want? It's spending time understanding what they're doing. Like you said, to be making those ideas about do we need to do this thing. The thing is if you're coming up with those ideas to use a DevOps cliche in a silo, you're not finding out what your customers actually want. So it's a kind of, if you look at it, it's a different layer. So discovery kind of happens over here and then it kind of comes down into this like the dual track product ownership and product management that Google kind of invented, or at least what they do. And so you're kind of doing discovery and that's filtering down into delivery and then you're taking that back up to discovery. So they're happening in parallel. It's not a phase of a project. Thank you. Okay.