 Hello everybody. Thank you for coming out to see this session. I'm going to be talking about web ops. If you are not familiar with the term web ops, hopefully, after the next 25 minutes, you will be. And my goal is to also help you understand how web ops can help you with your web team drive agile transformation within the marketing organization. Before I get into the content, let me just share a little bit about my background. So I was introduced to agile pretty early on in my career. I spent most of the early part of my career working at startups, working very closely with product management and software engineering teams. They were by default using agile practices at that time. And that way of working really impressed me. I had an opportunity to apply that in the marketing function. I had a lot of good results. And I wanted to share that experience with other marketers. So I ended up writing a book about the topic called The Agile Marketer. And I interviewed a lot of marketers for that book. I also co-host a podcast called The Marketing Agility Podcast, where I've talked with hundreds of marketers in many different contexts, whether it's B2B or B2C, big companies, small companies, and also folks in other ecosystem, players like tool vendors and agencies and consultancies. So a lot of what I'm going to share with you today is based on that research and based on those conversations. So let's start just by talking about why is it that marketers are so obsessed with agile marketing or with agile? A lot of it comes down to the fact that, well, so one thing, the average tenure of a CMO is 18 months in dropping, right? So we need to find ways of putting points on the board really quickly. Agile is a mechanism to do that. At the same time, we're increasingly in a position where we don't necessarily know what's going to work in advance. No amount of advance analysis is going to tell us what's going to work. So we need to address that somehow. And then the last thing is that we're all just managing more software than ever before. Agile is the best practice for managing software. So just for that reason alone, we should be adopting Agile. So I decided to go ahead and say, how many people in this room, raise your hand if you're familiar with what do I mean by Agile? Do you all know? Okay, so maybe half. I'm going to spend a little bit of time talking about what it is trying to make it more tangible. So the alternative to Agile is waterfall, right? It's the classic measure twice cut once approach. If you've got historical data, you look at that data, you analyze it, you figure out what's going to work in three months from now, you do your serial project management, and then three months later or six months later, you deliver this thing and you hope that it works. Agile is a very different process. The team isn't working in serial mode. It's working in parallel. So you've got your designer, your developer, your tester, and so on working together on a teeny version or a minimum viable product of what you're trying to build, a site, a landing page, what have you. And they put that little thing in the market. They get feedback, they figure out what works, get feedback on what works or what doesn't, and they pivot and they iterate towards the thing that actually solves the problem or gets results for you. That's the Agile process in a nutshell, and it really is the shortest path to what works. So let me break down or help give you a little bit of structure. We share the way that I think about Agile and what I've found resonates with marketers is that I describe Agile as being a philosopher or an approach. And it's one that's optimized for this world in which we don't know what's going to work in six months from now. We can't confidently say, if I do this, I'm going to get the outcome that I want. And it deals with that by taking an iterative approach to validated learning. So do something small, see if we get positive feedback. If it works, do more of it. If it doesn't, pivot and try something else. That philosophy is then made actionable through some rigorous, well-defined methods. I've probably heard of the two most popular ones, Kanban and Scrum. And those methods are really just a bundle of underlying practices that your team would do on a day-to-day basis. And there's a portfolio of probably like a hundred Agile practices that you could embrace. I'm going to share just a couple of them to give you a sense of what these are. So the first is just maintaining a backlog, a list of the things you want to do. Stabilized, scoped, what we call groomed. Working in iterations, meaning that you release changes at a regular cadence. That could be every two weeks, it could be every week, it could be once a month. And building releases and working in blocks, time box blocks. Having things like Scrum meetings, daily stand-ups, synchronization meetings, quick 15-minute meetings to keep everybody on the same page. You could do this every day or maybe a couple of times a week. Things like a demo meeting. At the demo, you're showing off the work that you produced at the end of each iteration. So every two weeks you're sending or you're sharing with your broader team, here's the stuff that we launched. Here's the stuff we worked on so they're aware of it. And then there's the retrospective, which is this is the quintessential, the most important Agile practice. This doesn't look back at what you just produced. That's what the demo meeting does. It looks at how are the practices we're using, how is the method we're using serving our team or company culture project? So that's just a handful of practices. So what does this look like in the context of a web team? So you've got an initiative. It could be something like, you know, improving the conversion of a landing page. And you build out a backlog of things that you think that you could do that would impact that. You take the first item out of the backlog, you have that cross-functional team do an MVP or a mini version of that thing and you deploy it. You see if it makes a difference. If it does, maybe you do more, do another iteration. If it optimizes your process or the experience on the page enough, you can take the next item from the backlog and move on. So that's fundamentally what it looks like. Agile is not new. Agile comes from a long tradition. We've been working on this for over 40 years. Some very smart developers who were working in the early days of the internet, which was an environment in which things were changing very, very quickly, really started developing the methods like Scrum. And ultimately in the early 2000s, they got together, a set of developers got together and wrote something called the Agile Manifesto. This basically bundled up or put a wrapper, a bow, around some values and principles that these developers had been figuring out over the previous 17 years. And by putting a name on it, by calling it Agile, writing the Agile Manifesto, they gave the community a thing to talk about and a thing to build community around. And so there was practice sharing and that really drove the adoption of these practices. Fast forward to another 11 years. Marketer's World was taken over by software. We're facing a lot of similar challenges. Some smart marketers got together and interpreted that document and wrote the Agile Marketing Manifesto. Fast forward to just last year and the first certification for Agile Marketing was launched by IC Agile and there's a bunch of providers out there that can certify you. There's really an ecosystem that has developed around to help us as marketers make our way through this Agile transformation. So the biggest consultancies in the world have built out digital transformation practices that include Agile transformation practices. They're writing a lot about this topic. They've done more than a billion dollars of acquisitions of agencies so they can not only consult and do the executive buy-in and mindset changes, but they can actually help you execute and deliver Agile transformation. There's a lot of training in the market that used to be only training for software engineers or product managers. Those companies are now pivoting and building training for business users, like us, marketers, and I mentioned that there's a certification that was recently brought into market for marketers. And then there's a whole giant ecosystem of tools that are there to help us structure the way that we do Agile. I would break that down into two categories of tools. There's general purpose tools, like the Jira's or the Asana's, Trello's, LeanKits of the world, which are general project management tools. And then there's specific purpose-built tools for specific kinds of teams that are doing specific kinds of jobs. That's kind of where Pantheon fits in. We are a tool just for web teams, but there's other tools if you're in digital advertising that will help you do this kind of work, or another tool, for example, like Optimizely is a tool that is obviously specifically for web teams that are trying to operate in a more Agile fashion. There's lots of Agile content coming to conferences. I'm here speaking to you at this one, but if you go to other conferences, you'll find tracks and sessions, and lots of content is being authored. I wrote a book, one of your speakers in this event earlier today, Scott Brinker wrote a book that was a lot about applying Agile practices in the marketing world called Hacking Marketing. This has been a trend in marketing for quite a while. I'm showing some Google Trends data here that looks at the search term, volume search term of Agile marketing, and I'm also showing lean marketing because the lean tradition, the agile tradition, if you had the Venn diagram of those two things, there's about 80% overlap. So when we look at the way that marketers are adopting this, we need to actually look at those in composite together because there's basically a shared set of values and principles underneath it. The way that Agile has made its way into the marketing function, it's been marching through different functions. Really, it started with digital advertising. We didn't call it Agile back then, but essentially, you know, purpose-built tools that helped us optimize ad spend, right? Do multivariant testing, those kinds of things are very much within the Agile mindset or an Agile framework. We then extended to content marketing. That's the stuff that we were promoting. Let's iterate on existing content rather than always creating new content, build an SEO engine that serves our business. Social marketing put Agile to use in helping us be much more reactive and responsive in a really timely manner. It put a lot of pressure on that. And now it's really coming to the digital experience world. It's coming to the sites that we deploy. So if you look at the enterprise, the last thing that I want to mention, though, there is that even though it's marched across marketing, it's quite siloed. And you can see that as we look at the way that it's playing itself out in the enterprise. So 80% of companies fall into a situation where mid-level managers have seen the value of Agile and they do it within their function and they're trying to, you know, drive broader Agile transformation, but they don't succeed very often, less than a quarter of the time. So if you look into the extreme, you've got a situation where you've got a forward-thinking CMO who's bought into Agile, maybe they were one of those mid-level managers previously, and they're willing to invest in the consulting and the training to transform their organization, and you get better results, but not that much better than a cointoss. Best results come from a situation where you've got both. You've got mid-level managers driving it up and you've got an executive who's bought in and can make it happen, okay? The thing is it's hard to get through and it's a different thing. That's why things are quite siloed. So there are two weapons that we have to combat this. The first, I think, is pretty well-known, which is the executive education bit. If you don't have executive buy-in, you're going to have a really hard time. It's the single biggest impediment, in my view, to driving broader Agile transformation, and this is why the big four consulting companies are out there building practices to help change this, do executive education. But there's also a secret weapon, and that's what I want to talk about with the rest of my time today. So that's the web team. Your web teams can be really helpful when it comes to driving broader adoption. The reason is pretty simple. It's that everything we do as marketers plays itself out through the website. Whether you're doing, you know, you could do retail. You're still driving people back to traditional retail drives, people back to the web. You know, if whatever you're doing in app, drive people back to the web. Email, driving people back to the web. You know, chat. Direct mail. It's all coming back to your site. So any function within the broader marketing group needs to interact with this team to get things done. So this team can expose them to an Agile process and get them to work within that process and have a kind of transformative effect across the broader group. This is where I'm going to get into defining web ops and the role that web ops has to play. So web ops is really a combination of words. It's the web team and the operations team or the marketers, us and our developers who deliver a website. Web ops is all about streamlining the process of delivering changes to our site, allowing us to move more quickly. And, you know, we know that when teams embrace web ops, it's an enabler for agility and we know that agility increases the likelihood of success of the projects that we're running because it de-risks them. The term web ops may sound a little bit familiar to you if you haven't heard it before because it sounds a lot like dev ops, right? Dev ops is something I'm guessing most of you are familiar with. Actually, let me just ask quickly. How many of you had heard the term web ops? Do you know what that in advance, do you know what this means? Okay, so like maybe 30% of the room. That's great. So dev ops is developer operations, a combination of those two things, but basically it's a combination of tools and processes that help software development teams move more quickly. And dev ops, your dev ops implementation, if you're building an enterprise application, it's a set of tools and a set of processes. If you're building a mobile app, it's a slightly different set of tools and processes. So what web ops is, it's an optimized version of tools and processes that are just for web teams. So that's, it's very related to dev ops, but it's specifically built for web teams. So if you think about what is a web, what's the structure of web ops? I think of it as being a three tiered structure. At the bottom layer, there's basically the platform that just powers your site. In our case, the Pantheon's case, that's a serverless CMS. The next layer up is an automation layer, where we just automate a lot of the things that your developers would otherwise have to do and spend time on. That could be upgrading your CMS. When a new version comes out and spinning up a development environment so you can see it, it could be taking your production data and pushing it back into your test and stage environments. It could be, you know, upgrading plugins. It could be innumerable things. You can automate a bunch of testing. And then at the top layer, there's agile workflows, which just is another way of saying, let's structure the way that work is done. Make sure that handoffs are consistent. Prevent things from being dropped in your process. Prevent things from releasing that shouldn't be releasing, etc. So that's basically what web ops is in a nutshell. Higher Ed is an interesting, that's a case study that I want to share with you from Cornell University. They are an interesting use case. In fact, any higher Ed organization is an interesting use case because they tend to be very, very complex. So this is a Drupal environment where they've got hundreds of sites. They've got many different stakeholders. Everything from recruiting to the main site for the university to sites for professors. You name it. So governance is a really challenging issue here. When Cornell brought in web ops and they brought in this platform, they were able to operate in a more agile fashion, but there was an unexpected benefit that they saw, which is that because all these different teams from across the company had to interact with that central team in a consistent way, it actually caused them to align on a number of other things that had not really directly anything to do with the web technology. They started getting on the same page when it came to the way they represented themselves, the way that they spoke about themselves. There was an unintended consequence, you could say, of having this way of working be consistent across the organization. This gives us a hint or a cue as to why deploying web ops can actually help drive agility across the broader marketing function. So let's go back again. What does this mean for your web team? What does it look like? So one of the things that it means is that you're going to transition from a world in which you're doing a small number of very big releases in a quarter, let's say, to a world in which you're doing a very, very large number of really small releases. That's good because big releases are high risk. If they go wrong, that is not good. No marketer wants to be in that world. When we have lots of small releases, it's not just that we de-risk, but we actually put points on the board faster because we're starting to deliver value earlier in the process. So how does this actually look if you're working on a particular project? Let's go back to that web page example where I'm trying to get it to convert better. There's two metrics that are helpful to understand or to frame up the way that an agile web team would work. So there's this concept of the North Star. That could be, like, what is my overall site conversion? Then you can have a gear level. A gear level or something is really, really focused on a metric that you can actually see move. So if you make, for example, a change on a very specific and important landing page and you do a great job and you change the conversion of that page, it's probably not going to, like, massively move your North Star metric. So you won't be able to see statistical significance in that context. So what this approach allows you to do is to focus on these gear levers, the place where you can make small changes that are measurable and where you can see statistical significance but where you also know you're moving that big gear. It's like looking at a clock. You're not going to be able to see that hour hand move. You need to look at the second hand to be able to see the impact that these many, many small changes are making for you. Baked into this is this idea that if you're going to work in this new way and you're going to embrace Agile, you have to be able to make a lot of small changes. So if the cost of making any one change is high, you effectively can't embrace this approach. You need your platform. You need the cost of deploying changes to be very, very well. This is why WebOps is important, because it brings process and automation that drives down the cost of making any individual change on your site. So it's really an enabler of agility in that way. Okay? So if we think about the value that WebOps has to offer your team, there's really two parts of the value. The first part is pretty linear. That's the blue line. So if you have WebOps and you have automation for something like deploying a change to your site, where your developer might have had to spend, you know, four hours to get something from your staging environment to your live environment, just because there were a bunch of manual processes that he had to do, automation can bring that down to maybe four minutes. So every time you make a release, you get that benefit. That's a linear benefit, and it's very straightforward. The agile benefit is not linear, though, because what we've seen with our customers is that when Web teams get in the cadence of operating, like deploying changes very, very quickly, really small changes, what occasionally happens is that they make a change. They wouldn't have known this in advance, but that small change actually leads to a really big change in conversion, and that drives an inflection point in the value that these changes are making and deriving for your company. So this is really kind of where the aspirational value of embracing agility comes from. It's a recognition of this fact that we don't know what's going to work, and we're going to do lots and lots of small changes that are going to, you know, consistently derive value for us, but once in a while we're going to stumble on one of these changes, which is going to have really something that's transformative in the way that it impacts our business. So I'm going to stop there. Hopefully that gives you a kind of a really good sense of what WebOps is and how it can help your team operate in a more agile fashion. I think we may have, like, one or two extra minutes here, so I'm happy to take questions if you have them. Shoot. Thanks. So I am my team. Yes. I'm a one-person marketing design and development department. Departments. And right now, so I've just been, like, given this marketing hat and I'm getting way off into CRO, a version rate optimization. Yeah. I'm about to run a bunch of user tests and stuff. So would I take away from this that I am far better served, so first thing I'm tackling is our homepage, because it gets the most traffic by far, landing page. By just changing one little thing at a time, A-B testing it, see how it goes, as opposed to let's redesign the homepage, put it out there. Yeah. So I think the process really starts with what is your business initiative. Then let's build that backlog. Here's all the ideas that we have that we think are going to serve as an intervention. Then grooming the backlog. Let's scope those things and prioritize them. And then yes, do the smallest possible thing you can do to validate if you're heading in the right direction. So that's basically the process. You know, there are some cases where there needs to be, like, a wholesale redesign of the thing. And in those cases, what you might do is actually start working on an MVP that you're only going to surface to a fraction of your overall traffic. Right? And it's going to be very basic. But you're working in parallel while your primary site is, your primary homepage is, like, kind of static. You're ignoring it for a while while you develop this other thing and show it to some customers and you evolve that. And it becomes more robust. And there's a point in which you just shut off the old thing. Right. Okay. Cool. Thank you. Other questions? Yes. I did write a book on this topic. It's called The Agile Marketer How to Turn Customer Experience Into Your Competitive Advantage. And the podcast that I co-host is called The Marketing Agility Podcast. We are always looking for folks to share their experiences with Agile, good, bad, or ugly. So if you try Agile and put it to use, I'd love to hear from you. Feel free to reach out. Thanks for the talk. Yes. So without realizing it, we already do web ops. We just call it dev ops. Sure. But if you can give a practical example, let's say we're working with a company and they're looking to do lots of campaigns, rapid fire. So how would our Agile marketing web ops kind of play out in that kind of scenario? And why would it be faster than maybe what we did before? Yes. So the first thing I would say is like, web ops is something you can absolutely build on your own. And lots of teams do do this. The reason to work with a platform like Pantheon or any managed service that provides web ops or dev ops is that there's a bunch of time that you are spending on setting up the integration of dev ops tools, those integrations, and somebody has to manage that. So tools like Pantheon or platforms like Pantheon just, they make that a managed service so that you're, whether it's you or somebody else on your team, isn't spending time on managing the web ops implementation and thereby gets to spend more time developing code and innovating and delivering hopefully higher level value than what we can provide with the platform. So that's one thing. Just have your resources focused on actually delivering the campaigns and not on maintaining a web ops implementation. I think fundamentally this, your question goes back to the two primary values that I mentioned at the end, which is that we're just going to allow you to move faster by automating a lot of the work that you have to do. So you spend less time on that and spend more time on the things that you really care about. I think that there's other tools within, I'll just speak about the Pantheon portfolio for a minute, there's other tools that we have to make it easy to apply templates or components at a massive scale. So you can take shared components or atomized bits and deploy them into lots of environments very, very quickly. Our architectural approach to doing this is better than the approach that is just built into the CMS, whether it's Drupal or WordPress. So the tooling that we provide there is really, really valuable when it comes to scaling the components or the atomized bits of code that you've developed. Yeah, are we out of time? Yes, okay, thank you very much. Okay, so we have two sessions coming up. All right, we'll be in here presenting content creation secrets for rock stars, and then Rick is Rick here. He hasn't touched base yet, so do you want to head up? Dory's going to head up and make sure he's here. Last call for Rick. Rick here, okay. We will let you know if he comes...