We've talked about the importance of lots of iterations paired with careful observation. And on the development side of things as a product manager, your interface with development, few things are as enabling for this as a continuous integration and continuous delivery and capability. With us today is Jim Rose, CEO of CircleCI, which provides commercial products that help enable this capability. Joe, thanks for joining us. Thanks for having me. How would you explain continuous integration and continuous deployment to a product manager who is new to the topic? So, continuous integration and continuous deployment are basically end to end automation of the development process between the time a developer makes a change to code until the time that that code is a running application in the datacenter. So, continuous integration talks to the first part of that and every time a developer makes a change to code, it merges that code into the main codebase and then test the codebase to make sure that everything is good and everything still works. Continuous delivery or continuous deployment is then being able to take that change in the codebase and then being able to push that actively and automatically into the datacenter. So that's kind of the Holy Grail. Once you get to continuous deployment, you have end to end automation from a change in code to an actual function application that instead of taking hours or weeks, can take just minutes. What do you think are the three, most important things that a product manager needs to know about this emerging super important area? The first is that is all about speed to learning. So, the idea of being able to make changes in their codes, see those changes to your code, ultimately in front of customers is all about trying to reduce the time it takes between coming up with an idea and then actually getting data from customers. So, it's all about getting things into small bite-sized pieces and being able to push those quickly and then iterate quickly on top of that. In order to be able to iterate, you have to be able to automate. So, as much as possible, you want to take out as many of the manual dates and as many of the manual processes between the time you make a change in code to that code being in front of a customer. And then, the last piece is because it's all about speed to learning and it's all about being able to see the impact of the changes that you're making to your code, you need to know what you're measuring. So, you need to in advance, be able to define what success looks like, how you would measure success. And then make sure in your system that you can actually see the results of the code as it goes live in front of a customer. Once you have all of those pieces together, you can really start to move quickly. Sometimes in practice, there's a tension between the product manager and their interface and development team where the product manager wants to get more features in there, and then the dev team wants to relieve some technical debt. For example, invest in improving this automation, this delivery capability. You thought a little bit about your [inaudible] perspective on technical debt. What is it and how PM should think about it? Yeah. So, technical debt is basically the remainder of your development equation. So, technical debt is a result of informed choices that you're making when you're trying to build new features and get them in front of your customers quickly. And also, potentially just shortcuts that you take ultimately to try and speed up. You should be incurring technical debt because you never want to be working on something until it's perfect and it's 100 percent done before you ship it out to your customer because chances are, you're 80 percent right on anything you ship. And the question is, which 80 percent? So, you want to get that feature in front of your customer as fast as possible so you can start getting data. And then ultimately, you just have decisions that are in your codebase that need to go back and be addressed. They just are shortcuts and they just have to be managed. What do you think is the best way to minimize and manage technical debt? So, we create time inside of our development process to always address technical debt and always have basically, a line item for maintenance inside our delivery system. So, the first step is, we divide product discovery. The idea of trying to find new and different features and new and different things to put in front of the customer away from delivery, the idea of being able to create production ready software. That's step number one. So it's called, dual track agile. It's the process that we use internally. The second part of that is in your delivery pipeline, you really want to break up each part of your delivery capacity into different buckets. The first is, you never want to allocate 100 percent of your time because things change. You get interrupted because production goes down. Something takes longer than you expected. So, what you want to do is leave at least 20 to 30 percent of your overall development capacity totally unallocated. It's basically slack in the system that as things come up, you actually have the ability to address it without necessarily pushing back the deliverables. The second part of it is, for the parts that you do allocate for your development team. The way that we do it internally is we take 40 percent of our time and we allocate it to the construction of new features or radically new versions of existing features. So, new things that are getting in front of customers, we usually take about 40 percent for that. We take 20 percent and allocate it towards the maintenance of existing features. Just fixes, enhancements and those different pieces. And we also leave 20 percent allocated for maintenance, bugs, technical debt, architectural debt. So your development team knows that they always have time to be able to address the pressing technical things that everybody wants to take care of and don't feel like they have to either do it off menu and not tell you about it, also don't end up in a situation where you end up with a pile of technical debt at the end of a development process. And then you have to start paying down. Some great advice on managing your delivery capability. Thank you so much, Jim. Sure. You're welcome.
