Head of Product, ThoughtWorks Products
Five Ways Continuous Delivery Can Be a PM's Superpower
Suzie Prince: Okay. Great. Uh, so, um, I'm going to talk about uh, continuous delivery and product management. Before I do that, I'm going to introduce myself a case you can't see me here. I thought I'd put a picture up here as well. Uh, my name is Suzie Prince. I work for a company called ThoughtWorks. We are primarily a software consultancy. We build our software for other businesses, but we also have a product division and that is where I spend my time. We build products for other software development teams, engineering teams, Dev ops teams. I've spent most of my career either in the consulting part of our business or in our product business, building B2B solutions for other companies. And for the last four or five years I've spent the most of my time building continuous delivery tools. We build an on premise open source product, which has a commercial aspect to it, which I spend a bunch of my time on.
Suzie Prince: And we also had a fast product as well. So I've spent a lot of time with teams who are on their continuous delivery journey. Uh, either they are just thinking about what is this time continuous delivery, what does this mean or their teams that are deploying software to production to the hands of their users multiple times, um, a day. And so I want to talk about my experiences with those teams and how you with product managers, founders, maybe even investors should really care about continuous delivery and why it's not just a practice for your tech teams. So I'm going to start off with a definition of continuous delivery. Um, before I do that, I'd like to know how many people have even heard of this term in the through. Okay. So I'm going to say maybe more than half. I will do a quick introduction to it and I'll highlight the things that I think are particularly important for people who are not technical people.
Suzie Prince: So this is my favorite definition of continuous delivery. I'm going to read out to you. Continuous delivery is the ability to get all changes or changes of all types, including new features, configuration changes, bug fixes and experiments into production or the hands of your users safely, quickly and in a sustainable way. Is kind of a mouthful. So I like to shorten it to these highlighted pieces. Basically all changes into the hands of users safely, quickly and sustainably. And the three things I want to call out and you'll hear me hear me repeat in this talk or the safely, quickly and sustainably why those things are important and why they're particularly important. If you're a product manager, what it looks like in practice. Continuous delivery is basically a bunch of feedback loops. The first feedback loop is don't show if this part works is this part here.
Suzie Prince: Um, we call that continuous integration. That's basically where code from your developers machines is integrated with the rest of your existing code base and it's tested to make sure it still works. Um, and then following on from that, we have a bunch of other feedback cycles which are part of this thing that we call a deployment pipeline. And basically every time your code progresses down this pipeline, different stages of the pipeline, you get more confidence about whether that code is going to perform correctly. And as you expect in production, and this is particularly important if you are a product manager, you want to know that what you're about to give to your users is going to work successfully and so the deployment pipeline and the part of continuous delivery that I really like is this a reassurance of the quality as you move through that pipeline.
Suzie Prince: One thing that is particularly important and I think is key for some product managers and and perhaps their distaste for things like continuous delivery is the distinction between continuous delivery and continuous deployment and that really is this, this bottom part here, the difference between a manual deployment to production and an automatic deployment to production in continuous delivery. It is a manual deployment to production and what that means is that somebody, and I hope it's a product manager, that's what I add the Kate and I empower you all to ask for that. If it's not the case in your organization decides this software's ready for our users, it's ready for production, I'm going to press the button to do that. In the automated world, that means you're automatically confident that once you've passed through all of these stages, you're going to put your software into production and either can work depending on your organization.
Suzie Prince: Um, either way it's a business decision. Um, I believe that continuous delivery is about empowering businesses. And so whether you decide to advocate for a manual deployment and then you get to decide when it goes or automatic, you should be deciding whether that's happening or not. And there's two other things that I really want to call out about continuous delivery, um, that are, that really are important about this definition of it. And the first I mentioned or rarely already is that once you've passed through this deployment pipeline, you should feel very confident that your code is going to be safe in production. That has a, has a high quality. So if you have a robust, successful delivery pipeline, you should feel very confident about deployment production. And the second thing is you don't have to do continuous deployment. You don't have to do an automatic delivery to your production environment.
Suzie Prince: If that's not what works for you. And you get all the benefits of continuous delivery, even if you don't do continuous deployment. So enough of all the boring texts staff who cares about deployment pipelines, test cases, staging environments, performance environments, surely this is basically not something that you product manager people should care about. You've got CTOs, you've got tech leads, you've got Q&A, maybe delivery managers, engineering monitors, all these people like they're going to handle it, right? You have way too many other things to care about. Um, this is where I tell you that basically I think you do have to care about this. And the reason is it's your job to put successful software and value into the hands of your users. And the way that that happens is your software development process. And part of that is continuous delivery. So if you have the most amazing idea, you have a hundred Dillion, a bill of bazillion hypotheses that you want to test.
Suzie Prince: You have this thing that you've been working on for ages. You can't get it to your users and get some feedback on it. If you can't ab test it, if you can't ask them for their opinion, it's clean. And if they can't use it and you know, build on on it and build their businesses, it's kind of useless. So that is why I think you should care and there are five reasons why you should care about product management. I'm going to call them super powers. Um, and that's what we're going to talk about today. So the first superpower, um, is that continuous delivery can transform your organization and we have evidence to show that continuous delivery actually provides a competitive advantage to the organizations that use continuous delivery. I'm going to draw a lot of the statistics that you see. There'll be a bunch of quotes that I show.
Suzie Prince: Most of them are drawn from this book which is called Accelerate. Um, the primary author is a lady called Nicole Forsgren. Um, she also wrote it with a former colleague of mine, Jez Humble and it basically has a whole bunch of um, statistical, um, peer reviewed evidence around software delivery processes and why they're important. I highly encourage you to read it. If not, you can just stay for the next 10 or 15 minutes and I'll show you the most important pieces that I think are relevant to us. So, um, in Nicole, in, in, in the book, um, let me go back, sorry. In this book, um, one of the most important things that Nicole does is that she defines what a high performance, uh, software delivery team is. And that's a, a team that has these characteristics. Um, so a high performing software, uh, delivery team is able to make multiple deployments a day on demand when required the lead time for those changes.
Suzie Prince: So when the change was first started, when actually gets to production is less than an hour, the time that when it goes to production, the percentage chance that will fail or cause a problem for you with less than 15%, maybe it's actually not that great when you think about it, but you know, it's better than the low performers. Um, and the meantime to recover if there is a failure is also less than an hour. So this is what we're striving for. If we want to be a high performance delivery team. And one she has defined this high performance delivery team. She shows us what it means to businesses that have those kinds of characteristics. And she shows us that high-performing delivery teams practice continuous delivery and by practicing continuous delivery, they all highly performance. And that actually leads to all the organizational performance. So whenever you see an Arrow like this on some of my diagrams and also in the book, it basically means that this drives their stripes there.
Suzie Prince: So continuous delivery drives your software delivery performance, which drives your organizational performance. And that's a little hard to understand. So I'm a good way to think about that is that she says that high performing organizations are twice as likely to succeed and exceed their performance goals for profitability, productivity, market share, and the number of customers. So what we're basically saying is if you practice continuous delivery, you have a higher performing software development team and you're twice as likely to have a twice as many profits and twice as many users. She also showed that those high performers, the ones practicing continuous delivery have a 50% higher cop, higher market capitalization and growth. And that's also a little hard to understand. So I have taken the liberty to show you something, um, about roughly what that means. Um, and there are liberties here. This is not from the Burke, but this is a chart of the, um, growth of Amazon, Google and Netflix over the period of time, which Nicole studied.
Suzie Prince: And I think we're all familiar that these organizations practice continuous delivery and you can see their growth versus the, uh, s and p 500. And you can see that they obviously have significant growth. Now there's a bunch of different things happening in those organizations, but essentially what Nicole is saying is that there is a relationship between software delivery, performance and organizational goals. Continuous delivery is part of that. And this is something that you can achieve if you want to. So I think, you know, if you want to be a superhero, I'm basically saying continuous delivery has to be part of that toolkit. But it's not just all about technical practices. I want to talk about how continuous delivery actually lets you be a better product manager and it will actually help you slay this thing called the feature factory and help you move towards being a lean product manager.
Suzie Prince: I'm sure you're all informed about the most current thinking in product management. You know about lean startup, customer development, the idea of outcomes over outputs and the notion that we don't want to be working in a feature factory. And you know, these things are very common in our vocabulary as product managers on all of these things are focused on the idea that you can't simply just put feature through of through feature, through your software delivery process and end up with value. They're based on the idea that you have experimentation frequently delivered value in small batches and that you seek customer feedback. And I am speaking to product managers. You will know this except for, and I think um, Patrick said this earlier in his talk as well. Um, people aren't actually doing these practices and we'll talk about that more. So we know for sure that lean product development actually drives better outcomes for your organization.
Suzie Prince: And again, this is statistically proven in the Cole's book. Uh, we also know though that a significant number of organizations and product management professionals are not actually seeking feedback from the market in A, this is a survey that was on mine, the product 62% of B to B product managers said admitted that they were prioritizing features without any feedback from the market. And I think not fairly shocking. It's quite sobering fact that two thirds of us might just be winging it every day. Even though we've all been at these conferences and we've all heard do experimentation, talk to your customers, get feedback, follow the loops and none of us are doing it. And that's kind of shocking to me and I sort of was thinking, well why is this? And I think frankly a lot of the time product managers want to do these things, but they are stuck in organizations that cannot allow them to do it.
Suzie Prince: Often we working with a delivery capability that accepts features in at a certain cadence of time. We have a two week sprint, we sit in our two weeks sprint, we wait till the end of the sprint, we deliver our stuff, it goes to the release train, we wait for the release train to go out. And so we really can't, we're sort of stuck in this organization that just can't let us get to the lean product management that we want. It wasted our time. I'm waiting for feedback and it actually often wastes work. You know, you have to fill the sprint. So why not just do an extra few things instead of, you know, getting feedback on the first thing that was completed. And again, it's not just me that thinks that, um, Dr [inaudible] work has actually shown that if you take an experimental approach to product development, um, it's actually highly correlated with your ability to have those technical practices that are contribute to continuous delivery. And I basically take that as proof that to get that kind of real rubber hits the road feedback, you need to be working in an organization that can allow you to do that.
Suzie Prince: So what's next? Why is continuous delivery, um, you know, another of our superpowers, the next thing that I think is particularly important about continuous delivery is that it allows us to, um, have a software delivery process that is safe and predictable. And in a world where your customer needs are changing, the market influences a dynamic who knows what your bosses and your, you know, your business is going to ask for. Knowing that your continuous delivery software delivery process is going to be fairly, uh, predictable is actually quite a nice feeling that you're not scrambling to doing, do things. And one of the benefits, the upsides of that is when you have some predictability, you can actually use that to predict your future performance. So if you know that you regularly deploy to production in under an hour, which is what our high-performance did, you can actually know that if you want to get a bug fixed to production, you can tell your customer it's going to be there in an hour.
Suzie Prince: And that's quite an amazing feeling as a product manager to actually be able to say that. Be really ready to answer those questions. But it's more than just the peace of mind. It's that you can actually genuinely be responsive. So it's not just that I can say it's going to be there, it's an hour in an hour. It's that it's actually going to be that in an hour. Um, and that you can believe what you're saying. If you think back to your last customer conversation, um, particularly if it wasn't driven by yourself, if it was driven by you, I'm sure it would be all about feedback and understanding. But if it was driven by the customer or perhaps your sales team, maybe even your support team, it almost certainly evolved around them wanting something from you that wasn't available. Um, capability, a feature, a bug fix. And it almost certainly evolved around them.
Suzie Prince: Thing revolved around them saying, so when can I have it though? Like when are we going to get this? And in a pre continuous delivery world, often you would have to have that response where I'm not sure, maybe tomorrow we could rush it for you, but it might break some other things. It's this horrible, weird conversation. But in the world where you have continuous delivery, you have predictability, you can be responsive or you might even be able to say, actually, we've just pushed that to production. Shall we take a look at it together? Those are the kinds of things that their software delivery excellence really brings you.
Suzie Prince: Um, so those things, those three super powers that you talked about, you know, transforming your organization and um, being more responsive and being safer, your software delivery process, those are all sort of really technical things. But I want to talk about now about actually what continuous delivery can do for your culture. And it's actually been shown that those organizations that practice continuous delivery actually have better organizational cultures. Um, and I think that's because when you get these practices right, when you get continuous delivery right, you actually have to work together. You actually have to collaborate. You actually have to break down silos. You have to share goals, you have common goals, and you genuinely act as a team. And when you're having a conversation about shall we deploy today and you were the product manager or involved in that conversation, you're more likely to be talking about the quality of your software as a team.
Suzie Prince: Together, you are more likely to be talking about what is value for your customers because you are saying, actually, I don't want to put this out there because it's not complete yet or it's not ready yet, or it's not what I envisioned. I don't want to do that. And your team actually understands those decisions. So the more your team centers around these fundamental qualities of your software, the better that your software is likely to be. And when your team members are not siloed, when they understand each other, they understand each other's work and you actually have these, um, benefits of actually working in this way. And that's all warm and it's all fuzzy and it's all my opinion. But Luckily, um, they actually proved, again in this book, I urge you to read it and understand the science behind what they did. They actually found that those teams who practice continuous delivery actually had a more generative, I'm not sort of an idea based culture and they were much more performance orientated.
Suzie Prince: And that's actually a big thing to say. I think most of us would think it was the other way round. You get some great people, they do some good work and we have a great culture and our product is great, but actually if you take the work to put time in, you do the work to build a continuous delivery practice, it actually affects how your whole organization works. And I think that's actually something that's really important for us to understand. Um, and so the final thing is that actually continuous delivery means that you don't really need to be heroic all the time. Um, it can be super powerful for you. Um, but, uh, you don't actually need to be, um, this, this, uh, amazing super, super powered product manager and I'll, I'll explain that to you by going back to our definition of continuous delivery.
Suzie Prince: I've talked to you about the safely part. Um, and the quickly part is basically a diff, uh, you know, in the definition continuously delivering. So it is about being responsive and quick. But I haven't yet talked about the sustainable part and honestly I'm continuous delivery actually makes software releases pretty boring. Um, there's no rush to get something out. Um, there's no all nighter before something goes out to production. Um, you may just be toggling on a little button in an interface that it goes myself where into production you may just be pressing something somewhere and saying, let it go out to the world. We've had it go out to these 10 people. Now we're going to have it go out, you know, to these thousands of people. And it really is kind of a, a killer for some people. They love the adrenaline of a software release.
Suzie Prince: Um, the little anecdote that I have is that one of my teams actually complained to me that we just don't have these celebrations anymore. When we do releases. It's like we haven't been to the pub together. You know, we haven't like nearly died on a Sunday night, but made it to the office on a Monday morning and you'd go, you know, donuts for everyone because we're just, you know, we're releasing every day. We used to boringly walk over to a Whiteboard, talk about what was ready for production and make a decision. And it can seem very mundane and, but actually means for you is the, all those superhero, you know, exciting things you get to do. You actually get to do with your customers, your business, your founders. What is it that you're trying to achieve? Why does your customer hate the thing that went out last week?
Suzie Prince: You actually get to spend your super power. You know, I don't know how to say that, but, um, you know, you get to spend that energy on product management rather than software delivery releases. And I think that that is actually very powerful for us so that we have it five superpowers. But what's next? Um, I spent most of the time talking about theory. I told you to read this kind of full on book about why all these things work out and basically the answer is do CD. Um, but what can you really do tomorrow if you wanted to get started with this process, I have five bonus quick things that I suggest. The first is if you don't already understand how your ideas, your amazing ideas, go through this process and get to the hands of your users. Do that. Go Talk to the people that do your continuous delivery process.
Suzie Prince: If you do it now, talks to your Dev ops teams, talk to your software engineers. You need to know what is happening between this point and this point. And if you're not already doing this, don't send them a massive pdf of all your requirements. Even if you are walking over to somebody's desk, think about the smallest possible thing that you can that will make that process a lot easier for you. Then the third thing is that once you understand this process and you're putting little things into the process, measure how long it takes to get from one end to the other. I guarantee you it won't be less than an hour, which is what our high-performance we're doing. And if it is a cute off, I'm sure you don't have a 15% failure rate. You know, most people are not in this high performing range. And to get the most benefits, um, you need to be so measure it and see what you're doing.
Suzie Prince: And then the fourth thing, you know, it's the soft fuzzy thing, but really think about how that process is changing your organization and, and build trust among teams. And then the last one is, um, I think a lot of product managers take it upon themselves and I've just told you to take on another thing. Uh, think about continuous delivery as well as all the other things, but really think about when you get through this process, um, it's actually less work for you. Um, and it's going to be a much more sane, safe environment. I actually really enjoy, um, the teams that I work on that the same people that I used to work with before we evolved to this. And it actually, um, yeah, it's a much more enjoyable environment. We don't spend as much time, you know, like I said at the weekend, um, together, but, um, it actually becomes more joyful and you don't need to be this sort of Superhero, um, that I talked about.
Suzie Prince: Thank you. There was a thanks. Oh, I have some reading, uh, the book and then I'll, thanks.
Suzie Prince: Can I answer some questions if anybody has?
Speaker 1: Yeah. [inaudible]
Suzie Prince: Yes. So I think it depends what you're trying to achieve by putting it out there. So that's probably the main thing to think about. Like what is my goal with putting this out into production now? Often it's a fully baked feature. You know, it might have been something you've been working on for awhile. Maybe you put some thin slices out before and you know, it's ready to go. Um, so in those cases you might not want to put it out on a random Tuesday. You might actually want to do it with, you know, like a PR event or something like that. Um, or it might just be a micro little fix that you have or, um, a hypothesis that you're testing. So it's really about like, wha like what am I trying to achieve by putting it there? And if it's, um, something that doesn't require ceremony, then maybe it can just go out. Um, and maybe you hold it for other reasons. So that would be my advice is like what are you trying to achieve by putting that thing there?
Speaker 1: [inaudible] Do you see?
Suzie Prince: Ah, I think it varies quite a lot. Um, in the organizations I've worked with, um, I often see that product managers make that decision. Um, in the one, the actual team that I work with now, we actually have three people help make that decision. A product marketer will definitely make that decision, um, with the product manager. And we also have our support team actually quite often involved in that discussion because if it is something that we're fixing, let's say that's broken, they have the most context around. Um, you know, the, the implication of putting that fix out at a certain time. Um, in terms of the severity I have, I am assuming people do that, but I've not come across it in terms of feature development, um, in the way that I'm describing. The other thing that people often ask me is, well, does this mean I can only like work on one thing at a time?
Suzie Prince: Like if everything that I do go straight through this pipeline into production, does it mean that I can't have multiple things, you know, multiple features on the go at a certain point in time. Um, and not something that I would say that's not the case. It's not just about one thing takes all, you can actually achieve, um, multiple different streams of work by either using something like a feature flag, um, feature toggles, brunching those kinds of things. Um, and not just have, you know, one stream of work. It doesn't mean you just, everyone has to do the same thing. You can actually turn things on and off and Edith can talk to you about that. I think, um, all your tech teams will know about feature flags or they'll have their, the way they prefer to do it. I think somebody else had their hand up. Yeah.
Speaker 1: [inaudible]
Suzie Prince: yes. So, uh, uh, my picture's not going to help. Um, cause it doesn't tell you the answer to that. But basically without getting into too much of the nitty gritty, um, a lot of the continuous delivery practices on the technical side around having automation. So a lot of the things that wait month once would have been done manually by a QA, uh, have to be automated. And that is all built around, um, automated tests suites. So in all of the organizations that I have worked with, we would recommend having multiple different levels of test automation starting with unit testing. Um, and then you would have more like feature, feature level testing. So, um, it's about test suites and then it's about automating those test suites. And often we are running many, many different tests in parallel at the same time. Um, so many, in fact, many thousands and thousands of tests all running in parallel so that you get those quick, short delivery times. Cause if you think about someone like Google putting something out in under an hour, um, they would have, you know, maybe, maybe millions of test suites. Um, so that's what I would say to shorten those cycles. Uh, automate your process. And the biggest way of doing that is having automated testing suite.
Speaker 1: Did that answer your question? Yeah. Any other questions? I think you're up. Thank you.
Keep me posted on Empower 2019.