Ep. #1, The Story Behind Progressive Delivery

Kim Harrison: Welcome to the Third Loop podcast. It's a pleasure to have you here. We'd love to hear about this thing you call Progressive Delivery and learn more about where it came from.

But first tell us about who you are and your experience and probably go back to at least the moment in time when Progressive Delivery first came up for you so that we can lay the groundwork. Give us a picture.

James Governor: Well, I guess I should jump in, given it was my rage, my pure unfettered fury at the terrible marketing of a technology called service mesh that inspired me to start contextualizing Progressive Delivery.

So I'm James Governor. I am an industry analyst. I'm one of the co-founders of a company called RedMonk. So we look at the world primarily through the lens of engineering teams and developers. So there are other research firms out there that help people understand technology through the lens of purchasing. That has been the traditional model.

We really thought there was another world out there that was much more based on adoption and in particular adoption by developers. Nothing has happened since we founded the company to prove that thesis wrong. The availability of open source, the continuing social revolution, the fact that now AI and developer experience are more important than ever, and the cloud has just been absolutely foundational in giving developers the opportunity to try things.

They like trying things and then they're going to choose things. So just the patterns about how engineering teams have chosen technology, it's certainly not a top down behavior solely anymore. So that's who RedMonk is. That's who I am, James. And you know, I've spent most of my career trying to contextualize and understand changes in infrastructure and the changes in the processes that have enabled them and have always been associated with them.

I've generally not been in the business of inventing terms. We figure that the industry is better at that. There are analyst firms that like to invent terms. We are not one of them. That doesn't really make sense. It turns out that engineers come up with things too. They come up with names for things and those end up being used.

DevOps did not begin with Gartner Group. It began with a conversation between Patrick Dubois and Andrew Clay Shafer. You know, the rise of methodologies like Agile. This stuff didn't come from search firms. And we felt that the better thing for us would be to use existing terminology.

But on that fateful day, and this is dim in the distant olden days, I think it was 2018, it was in Copenhagen, it was lovely. And the Kubernetes community was all there. And it was the year when they started talking about service mesh and Istio. And talk after talk was about how awesome Istio was. And it was like, istio is amazing. And you'd be like, well, why? Well, because it's istio. We need a service mesh.

It's like, well, why do we need a service mesh? Well, because you have this technology and you need some standardization of things like how you monitor systems and what it looks like. Indeed, if you're monitoring to have a sidecar, what that means, you've got all of the sophisticated traffic routing and you're going to need that if you are going to be running Kubernetes at any scale.

And yet still, it didn't really explain. I was still looking for a use case and I spent the conference kind of wondering, is anyone ever going to tell me what this thing is for? Because it just seems like really complicated. And it's not entirely clear that we need more complexity because Kubernetes is already pretty complex. And I just came away kind of thinking, well, Istio, I don't know what's going to happen. But the cheerleading in search for use case, I don't know why it annoyed me so much, but I just wanted to tell me what the hell it was for already.

And then I guess it was just a few weeks later and I was in San Francisco and I was in conversation with a guy from Microsoft and he was talking about stuff that wasn't anything new. He was just talking about the fact that Microsoft, we were talking about how m Microsoft developed software and had got better at it and various testing methodologies.

He mentioned this notion of progressive experimentation and it became very clear to me right at that moment that there were a lot of things as an industry that we were not doing that we could do and that indeed surface mesh could be used for. But in fact, the patterns of experimentation alongside testing were ones that the industry at large was not using. And there was a big gap.

And so, yeah, everyone said, "pipeline's amazing. Everyone's talking about pipelines. We're going to do CI/CD. This is great." But we weren't really thinking through what happens when you pull all of this together and you do feature flags? And if you've got feature flags, then you can LaunchDarkly. If you can LaunchDarkly, you can observe the system. You begin to think about testing in production, you begin to think about all of these good things, the kind of things that amazing people like Charity Majors talk about.

And it just became clear to me that there was this gap, as I say, between where we were, DevOps evangelizing, DevOps being advocates for that, and where we needed to be in terms of going a bit further. That continuous delivery didn't take us the whole way there. I looked around and I saw companies that were doing A/B testing. We'd seen companies that had emerged specifically to do this.

A great example, Obama's first campaign's website. They A/B tested the hell out of everything. And the idea that you could do experimentation was, to me, it was like, yes, this is something as a pattern that makes sense. It could have been a use case for service mesh. And indeed, folks like Datadog, it turned out, were using Kubernetes in that kind of way. A guy called Jason Yee, really smart guy, wrote this brilliant post. In fact, it was a conference talk I came across.

And what Datadog was doing, and this was super interesting, was like, well, maybe we could launch something somewhere when everyone's asleep, because we don't want a bad experience for people when they're awake. If they're asleep, it doesn't matter. So they would do things like they would test things in production in the Japanese market when Japan was asleep. And so you could test something, look at it without worrying, "oh, no, we're going to have our awake customers pissed off at us."

So anyway, all of this stuff sort of came together and it was like, I immediately had to have some vermouth with Adam Zimman. That was very, very important. So I'm in San Francisco and the vermouth shop was in the old post office somewhere down near the Embarcadero.

Adam Zimman: Yeah, yeah, I figured if we needed vermouth, we needed to go to a special bottle shop and pick up something good for sharing with my good friend James Governor. I guess I should introduce myself.

I'm Adam Zimman. I am a advisor for startup companies as well as VC firms. I like to think that the main focus of my career has been looking at how we can actually use technology to enable individuals to be more successful. And so I've done that as a developer, I've done that as a product manager, I've run marketing organizations, I've run technical sales teams.

I've done a little bit of everything. So jack of all trades, master of none, but ultimately trying to figure out how do we actually think about technology and software. Although I've done some hardware, but mostly software and think about how do we actually make it so that it makes people's lives better. And for me just to kind of catch up to where James was at leading up to this search for vermouth, I had had varying experiences with regards to the packaging and delivery of software.

Going back to kind of an early career that was started at EMC where it was all about everything was packaged with hardware and occasionally software updates were done, but they were a very handheld white glove service that required specialized experts to be able to do moving on. Spent over a decade at VMware where it was still very much like I remember the days of package software pressing that golden master CD image that would be tested and released and saw how VMware also struggled with regards to the pace of change and the rate of change that was expected or needed from some users and was actually kind of pushed back against by other organizations and users because the change rate was too fast.

When I left VMware though, I had a really interesting opportunity where I started thinking about what would eventually become Progressive Delivery. And this was in 2014. I went to this little company called GitHub and was blown away by the fact that I had come from an organization that was shipping software to hundreds of thousands of people and in a good year they would actually successfully have maybe one to two medium sized releases. And a major release on average took about a year and a half to two years to be able to build and put out.

And then I went to GitHub and I joined to help launch the enterprise edition of GitHub and was there in the capacity of building out partnerships and relationships with the vendors that were going to help make that successful from a distribution perspective and head up that effort and working closely with the product team which at the time was literally one person, and the engineering organization, which was two people, to be able to put out this enterprise edition of GitHub.

And the thing that was impressed upon me was that I would be responsible in my first week of getting up to speed on using GitHub's systems and actually shipping something. So the expectation was that everybody in the first week would actually ship to production. So this was, like I said, 2014 and this was something that like everybody was expected to do this. "We're going to show you how to create a pull request, we're going to show you how to follow the kind of review of that and make sure that you're answering questions, make sure that you're communicating with your peers and you're going to get it pushed out to production."

And this was something that was like foreign concept to me but I was so unbelievably on board with and intrigued by like how do you actually move fast enough to make a difference but also have some kind of checks and balances to make sure that things were being done that didn't end in disaster. And one of the things that I found was that, for little things it was, it was one of the things where you would just go through the PR process and you know, they would be able to push that out after review and everything was merged.

But for any type of like code changes they were aggressively using feature flagging. You know, at the time it was Flipper was the open source project that they had heavily based on Ruby. And it was something where the standard practice was you'd create a branch and the first thing that you'd put in that new branch was a feature flag and it would be empty. It'd just basically be an if statement that like, "if this is on show it. If this is off, don't show it."

And you'd set the flag and it would be set to off so you wouldn't see it and you'd ship it. It was one of those things where like that was a way to be able to make it so that you could successfully test in production and be able to ship things to production without any risk of adverse impact. And this was something that was really impressive to me, something that I'd seen feature flag used in the form of config files and things like that.

We used them in VMware all the time, where it was like, these twiddle bits that you could change the behavior of your working products. And it was whether it was for you wanted to increase the verbosity of your output error messages, or if you wanted to turn on some special feature functionality that was explicitly designed for this one environment, for this one customer.

VMware was doing that and had been for years. But this was different because this was something that literally was running in production, and then you could change whether or not that was seen without having to make any additional code changes or deployments. And that was something that was remarkable to me. It was something that was really amazing.

And so I got to experience that being done at scale with millions of customers. And also at the same time was having some conversations with some of the product team that was doing what James was seeing and talking about kind of later. These were the early days of GitHub, where they were already doing pretty sophisticated A/B testing.

And they were doing it on everything from looking at feature functionality and whether or not things would be useful. They were also doing it for pricing, they would do it for content pages, they would do it for-- Obviously there's the stories between, like GitHub, I think, was doing this the same time as Facebook, where it was like, they would make slight tweaks to the dom, where it was like, I want to change this color, I want to maybe change this font in this one particular line where we make it slightly larger, slightly smaller.

And they would kind of test that on these massive audiences and see whether or not it had an impact, positive or negative, on user behavior. So this was something that was really remarkable to me. I'd say the other thing that was extraordinarily insightful and useful was the idea of staff ship. So this was something that GitHub was doing since even before, way before I got there, where they would have--

Kim: Wait, wait, wait, what years was this?

Adam: This was 2014. I was there 2014 to 2015. And this was something where they would basically have the ability to set these feature flags so that the only people who could see this behavior were people that worked at GitHub. So you had to be an employee, and they had an employee basically flag or group cohort that they would mark.

And the crazy part about that was that there were entire products that sat on top of GitHub but the only people who saw them were members of staff.

It was crazy. Unbelievable. You know, one of, one of the frustrations of course was the fact that you know, and I think that this was something that when Matt came on as CEO years later, he took advantage of because one of the things that was frustrating to internal folks that were thinking about this from like a go to market or like a opportunity perspective, so many of those staff ships could easily be just flipped and turned on as products that would be of remarkable value to a large portion of the customer base.

And in some ways in 2014, 2015 there was still this kind of hesitation about doing those types of releases. And that was something that you saw like this massive acceleration of what GitHub was delivering in the timeline that James is talking about, like 2018, 2019, which was when things really started to take off after post Microsoft acquisition in terms of the pace of feature delivery that was coming out from that group and community.

But so fast forward. I was really amazed by this method of being able to progressively expose folks to the things that were being built. And so after I left GitHub, I started doing some advisory work and started working with a bunch of different startups that were more aligned to this continuous integration, continuous delivery way of building software and did a number of different things there, ultimately leading me to you know, start working with a very small team at LaunchDarkly.

And so I joined there and was compelled to join there because of the power that I'd seen of how this approach to software development delivery could have such a positive impact on users, but also on the development community. Right?

The people that were actually building at GitHub were so empowered by this ability to, what I would often say is build at the pace of their innovation, right? They could build as fast as they wanted, they could ship things, they could put them into production, they could actually see how they would interact in a "test in prod" type environment.

And they were able to really move at an amazing pace, to constantly iterate and adjust and get closer and closer to an expectation and desire of the end user because they could see what the users were doing. Now this was something at GitHub scale at the time millions of users, you could see pretty quick the kind of user base converge on what were the things that were working, what were the things that were not. And that's because they had the volume and the scale to do that, to be able to do that experimentation and testing.

And so when I joined LaunchDarkly, I saw this as an amazing opportunity to be able to expose that methodology to more builders and teams that were looking to provide, to the point that I made earlier, software that's useful, right? Software that actually helps their users be successful.

And as I was working at LaunchDarkly one of the things that I was responsible for was keeping in touch with the analyst community?

James: Was drinking vermouth?

Adam: Which occasionally did require some drinking of vermouth, and no complaints.

James: The way I see it, this next step, it's sort of a meme that I love. And it's funny because it just popped up again on the internet the other day. And it's this guy who's on a hill at a concert, outdoor concert festival, and he's dancing. He's really going for it, and just on his own. And people are walking past. You know, they'll look up, walk past, and it goes on for a while.

And then one or two other people come and they see him, and they walk over to him, and they start dancing in the same sort of way, in the same animated way. And then as soon as that next person comes, social contagion happens. And all of these people come running in, hordes of people come running in to dance.

And so, I was there dancing on the hill, and Adam very quickly was like, "hey, other people can come dance here as well." And, yeah, so Adam basically told me that I wasn't completely losing my mind.

Adam: I think that a big part of it, James, was that when we started talking and after we picked up our bottles of vermouth and went back to my backyard, and we started talking about this, and James was just like, I want to run something by you.

And he's like, "I've been having a lot of conversations, and I want to tell you what I'm seeing, what I'm hearing, and I think that there needs to be a name for it." And I was like, okay, tell me about what you're seeing, what you're hearing.

And he started describing a lot of these things that I was seeing as well. Obviously, I was having a lot of conversations with customers. I was having a lot of conversations with prospects as well as other tangential technologies to LaunchDarkly. At the time we were really close with the folks at Honeycomb. Charity Majors was a friend and I loved hearing her talk. Loved hearing keeping up with the kind of concepts of observability and thinking about how that had changed from simple monitoring.

During my time when I was doing kind of advisory stuff, I'd worked with SignalFX, doing, you know streaming for monitoring and observability. I'd worked at Lightstep, who was doing distributed tracing. You know, like, had worked at a lot of different organizations that were kind of coming at this same challenge of: The world has changed. We're in the cloud now, and we have an opportunity to make things better, faster.

What does that look like? And who's it going to be better for? And so James started saying all these things, and I was just like, yes, I completely agree. And then he just drops this bomb. He's like, I was talking with Sam at Microsoft, who I knew, and h e talks about this idea of progressive experimentation.

James: By the way, we should mention full names. You said, Nat. That should have been Nat Friedman. I said Sam. Let's give him his due: Sam Guckenheimer.

Adam: Sam Guckenheimer.

James: He was running Azure DevOps at the time.

Adam: Yeah. And James said, I love the idea of progressive experimentation, but I don't think that that's it. And I was just like, I agree. I think that there's--

The challenge that I saw with the progressive experimentation term was that as soon as you said the word experimentation, it wasn't right. Too many people went immediately to this notion of statistical significance.

And oh, well, we need to. Everything's going to be predetermined by the math. And I think that that was something that was. It was too far right. It wasn't approachable to enough people. And I think that there was something we needed that was broader than just the progressive experimentation. And that's when James kind of came forward.

James: Progressive Delivery. And Adam was like, yes, that is good. We can work with that.

Adam: And then we started talking and everything kind of fell into place because we started thinking about it in the context of obviously the term du jour the day before had been "continuous delivery." And that was the kind of thing that so much of the industry was pushing for. But I think that one of the things that came out of that was the conversation that James and I were having.

We pointed out that, like, a lot of the enterprise customers we were talking to, there was a split. There was a group of enterprise customers who were like, oh, we want to get to continuous delivery, but can't. Like, we're stuck. And then there was the other group that was a lot of FinServe and regulated industry, who was just like, continuous delivery sounds like a horrible thing for our business.

James: Yeah, yeah. What a bad idea.

Adam: Like, that would be terrible. We don't ever want that. Right? And a big part of it was this idea of they recognized that there was a rate of change challenge for so many of their users. And frankly, in some ways, there was a rate of change challenge for what they were legally, from a regulation perspective, allowed to do. And so that was in direct conflict.

And so this was part of where we wanted to really think about how would we approach Progressive Delivery in a way that actually bridge that gap from what people were doing with Agile, which we, we realized was not necessarily meeting the needs of everyone, and this challenge that folks had of wrapping their heads around continuous delivery.

Kim: One question before we jump into the future. When you dropped this idea, James, you already hinted at the fact that you don't like to come up with new marketing terms. I t's kind of what y' all did.

James: Yeah, a hundred percent. I think the problem was that Adam liked it and I talked about it, and then it just very quickly became apparent that other people liked, understood. It just clicked with people. And so there wasn't any feeling of, like, pushing a rock uphill. People immediately responded positively.

Kim: Why do you think that is? Like, why? What was it about it that clicked?

James: Well, I think people just understood that it was true, that there were some other things that needed to be described, codified, pushed forward in the way that they were doing things that I think we're always in a state of sort of "give it a name." And in this case, yeah, people knew that they had to talk about five or six different things in order to describe what they were doing.

And it just made sense. Why not package them into one thing that talked about the set of different disciplines that they were working on in order to achieve production excellence? And it's somewhat catchy. It builds on where we were with continuous delivery. But people felt like, okay, let's reassess and think about some of the other things that we could do.

So, yeah, I mean, I think it describe a problem or it described an opportunity. I think people were like, yeah, this just makes sense. And also, look, I mean, it is somewhat and it's interesting given that the length of time that things take in order to, well, I mean, writing a book, for example.

But yeah, the industry is all about giving things names. As I say at my firm, it wasn't something we usually did, but here it just resonated. I think people were like, yep, that makes sense. And I had a lot of people that I greatly respected immediately groked it and began using the term. I had my clients using it, picking it up. So a ton of vendors certainly in and around CI/CD, the aforementioned LaunchDarkly, and just a ton of companies.

I mean, in fact, I think this year I'm going to be doing some work with Dynatrace, the observability vendor. They acknowledged it early on. And also then just enterprises, when people come up to you and they're talking to you and they're like, "oh, you're calling it Progressive Delivery." Y ou're not selling the idea when someone is using it. You're like, okay, well, this is clearly a thing.

And I had that. I had people from banks in London saying, "oh, yeah, Progressive Delivery. Yeah, we're doing that." And I'm like, tell me more about this Progressive Delivery that you're doing. So, yeah, it escaped confinement.

Heidi Waterhouse: I actually have a marketing opinion on why it worked.

James: Great. So why don't you say who you are, how you've kept us on guardrails, how you are also, in your way, definitely one of the people that is on the hill doing the funky dancing, and what your marketing thought is.

Heidi: Alright, I'm Heidi Waterhouse. I'm a marketer and developer relations person. And also I do what I think of as business relations, where we need to explain to business why technical changes are useful to them.

The thing that I think made Progressive Delivery take off the way it did is that we had a context for progressive as not in a political sense, but like a progressive reveal, progressive iteration. We had this idea of progressive as a way to safely make progress. And saying Progressive Delivery makes it sound incredibly less intimidating than saying continuous delivery, which is a demand.

Like, "you must continuously deliver or integrate." Instead, what we're saying is like, we're going to open it up so that you can make progress, so that you can make movement, so that it's going to be okay. And I think a lot of people are really worried about breaking the things that work.

And if we give them a way to reconcile that fear with the awareness that they have that they need to keep moving, it works out really well for them. And so from a marketing sense, I think what you do by saying Progressive Delivery is lower the barrier to entry and say, like Adam was talking about, like these big companies that were stuck and couldn't get to "continuous" were like, okay, but maybe I can try for progressive, maybe incremental progress is going to work out better for me.

And as I went around talking about Progressive Delivery, I found that people had a lot of fear about sort of the radical, we used to call them the cool kids, like the born native web companies who stood up on AWS and had never had a data center and didn't have this huge legacy and backlog of software.

Like, if you're a cool kid, doing continuous integration wasn't hard because you had always been doing it. If you were a bank, an insurance company, a car parts company, a furniture seller-- I talked to some people who ran fabric cutting in France. I'm like, you have some legacy issues that are not trivial, that are real. And you need somebody who understands that you can't do everything all at once easily.

Adam: Yeah. And I think this was exactly it. Is it like, I'd say that another way of putting this, James, was that you didn't set out to create a term. What you did, and I think this was where it resonated with me, was that you were looking at things and you saw a pattern and you wanted a way to shorthand communicate that pattern and the grouping of patterns that you were seeing with a larger audience.

And I think that's why it really resonated with me as well is because I was seeing the same patterns. Those patterns that you and I talked about, they were things that we were seeing across industry you know, across customer segmentation. And also we were seeing it consistent. Like, I think that something else to point out was that this was really around the same time, this was 2017, 2018 time when the DORA organization was also really taking off and really starting to get traction with regards to their data and how they were publishing it and sharing it.

So there was a lot of conversation around this idea of what good looks like. And one of the things that I think we were noticing was that a lot of the criteria or a lot of the recommendations that were coming out of the DORA reports were consistent with what we were seeing: These organizations that were starting to do a more progressive delivery model. And I think that was a way of us being able to kind of group those behaviors a little bit and be able to bring those forward in a way that was more consumable to people.

James: So we've got another human that also joined our merry band, Kimberly. Again, in order to be a functioning human, I find I have to have amazing people around me. And Kimberly Harrison is one of those amazing people.

I think the other thing that's interesting about y'all is you all--I mean, we haven't done the full reveal of what you all share in terms of your background that really makes you so uniquely placed to have been writing this. So yeah. Kimberly, how did you--

Adam: Well, I would say Kim, maybe the way that you should also include in this is I believe the reason that we have the book was there was a lunch that you, James and I were at where this book was actually your idea and, frankly, not even idea, but your insistence that it needed to exist.

Kim: I might be the team instigator. Although to be fair, I don't think you all need much encouragement. Just like a gentle nudge because you're already ready.

Adam: But you should introduce yourself.

Kim: Okay. I am Kimberly Harrison. My background is in marketing. I studied sociology in school. Actually, to be fair, I studied biochemistry and sociology and did not know where I was going to end up. But I had a strong appreciation for evidence based existing, shall we say, and ending up in marketing where I am very curious about human behavior and what inspires people and why they do the things they do and how you can convince them to try something new or a little bit different.

But having a background in the sciences where I really appreciate cold hard data, I think finding myself in the world of developer tooling, this was a natural fit. I really enjoy hanging out in this space. It is a fast moving space as everybody here has been sharing.

Things have really changed a lot in a very short amount of time and it's fascinating. I find it very interesting to watch as people adopt new technologies and methodologies because it's not just the tech, it is the process around how they see it and how they want to fit it into their workflows and their everyday, what they're willing to try versus what they resist and why they might be resisting something.

And so I'm fascinated by all of this. And I sit in marketing, so of course, I am the person who's very, very interested in hearing when people like James come and start sharing new language that does very accurately talk about a problem that people have been experiencing. I was in the marketing department of LaunchDarkly when James and Adam had that day, that afternoon, and Adam came in the next day, very excited sharing this.

I felt like, "well, that explains a lot of things we've been trying to build new messaging around. Please do write the articles, publish, get this out there. Because this would be a great way to talk about these concepts, these ideas, everything we've been trying to push around feature flagging."

Because at the time, LaunchDarkly was still quite small. We didn't even know if people called it a Flipper or a Toggle. Today, I guess everybody's agreed to call it feature flagging, but this language really stuck.

Heidi: You're welcome.

Kim: Yeah. Very well done, Heidi. And so, yeah, I do remember going to lunch and saying, if you all want to really push this conversation, just write the book, define it, say what you mean, dig in.

James: Yeah.

Adam: And then we told you that well, if we were going to write it, you had to write it with us.

Kim: Yeah.

Adam: And realized pretty quickly that if we were actually going to ever ship this book, then we needed a Heidi to be able to actually help make that happen.

Kim: Oh, my gosh. Yes.

James: So we've written the book. The book is out. It's great. You should read it. We'd love any feedback about it. This is our podcast about it. We are going to be featuring all sorts of interesting voices people that have been working on Progressive Delivery and related issues, technologies, processes, and so on.

So it's going to be great. What else does one say in the introduction of a new podcast?

Adam: Well, I think that, James, a big part of the podcast is helping folks understand that writing the book was, in many ways, just the introduction. Right? It was the way of being able to take these ideas that we've been talking about for years. We put them into a package so that everybody can have a shared context. And now we want to start to make sure that we're continuing this conversation.

And that's what the podcast is going to help motivate, where we want to get people thinking about everything from the rate of change, of how fast things are moving and how that's impacting users to the ways in which we as builders can actually make that rate of change better for people.

How can we reduce that technological jerk that people feel when things move faster than they're ready for?

James: Like AI. There is going to be a lot of AI talking of things moving faster than they're ready for. Oh, my goodness. And as we were finishing, or as we were in the process of the book, AI just absolutely came across the industry.

And I think one of the things that's most interesting for us, you will be hearing about in future shows, is that the interesting thing is so many of the disciplines, if we look at just observability of AI systems now, how we're going to safely roll out these systems, the sorts of approaches that OpenAI is taking and needs to take, the ability to roll models back, all of this sort of stuff it turns out, thank heavens, Progressive Delivery is super relevant. So I think that's probably the future statement.

Adam: Yeah. It's almost like it's no surprise that OpenAI acquired Statsig, a feature management company, because of the realization that, oh, wait a second, you can't do AI without Progressive Delivery.