Agile Marketing

Howdy, SEOmoz fans. I’m Jonathon Colman from REI, and today we’re going to be talking about agile marketing. This is a discipline that we are picking up from software developers, who have been practicing agile for decades, and we’re applying it to our discipline of marketing and we’re doing that for a couple of really good reasons.

First of all, agile helps us focus on our users and create more value for them more often, in ways that make sense, and it also helps us, as an organization, adapt to change. And you know better than anyone, how much change there is. Google’s releasing algorithm updates, 52 of them last May, 29 right after that. There’s Panda, there’s Penguin, all of the news and tips and tricks we see on Inbound.org.

We are constantly taking in new information to our organizations. But, oftentimes, our organizations aren’t able to respond to them. And why is that? Because they’re structured like this, because they’re structured in a big hierarchy that’s not centered around the user. So even when they take in new information, they can’t apply it directly to the people who matter most, their customers.

Secondly, we tend to work in models like this, which is a waterfall development model, where we take in requirements at the beginning, and then we do a chunk of work, and we do a chunk of work, and we do a chunk of work, and so on. But if change is coming down the road, if something happens here, like a Penguin, we can’t respond to that because that’s six months later. And, as you know, SEO, inbound marketing, social media, that’s changing hourly, not in six-month or one-year cycles. So we have to become better at changing, and that’s what agile helps us do.

So let’s talk about four principles of agile and a couple hacks that we can use to change our organizations.

First of all come customers. They’re the most important people. They’re our reason for existing as a business. So we like to say, “Users are number one.” “We’re number one!” So what we do is we structure our work and ourselves all around the user. And one great way of doing that, here’s a hack you can use, is to develop user stories. So as you’re doing research with your users, as you’re collaborating with them and sort of bringing them into the business to find out what they need to succeed in their goals, you’ll start building these out. And they have a really simple formula.

As a user or buyer or shopper or, in our case, maybe something like backpacker, I want whatever is that they have as a goal. Perhaps I want to be able to find the lightest weight backpacking products so that they can succeed. So this would be so that I can have a great time in an outdoor adventure, hiking the Adirondacks. And what this helps us do, what user stories are so good at is keeping us focused on that increment of work that we need to do so that our customers can succeed. So this is a great way of doing light and quick documentation to help us fulfill user goals.

The next principle we’re going to talk about is cross-functional teams, and that’s where we really blow away this hierarchy from the old-school business days. What we do is we take all those institutional silos and we just reduce them to rubble, and we form this sort of cross-functional team, where content design, code, inbound marketing, data or analytics, project management, we all sit together, all in the same place, work together on the same thing at the same time. No one is ever gone. You don’t have to walk to another building or send a long e-mail to explain something. We cut down on documentation, on all those pesky e-mails and IM’s, and we actually have person-to-person interactions. It’s a real strength of agile.

So I have a couple tools to help you with that. First is the stand-up meeting. This is one of the few meetings you have in agile marketing, and if it takes longer than 10 minutes, something has gone wrong. Imagine just having one meeting of just 10 minutes, 10 minutes, once a day, and then being able to focus on real work that creates value for users. It’s awesome.

So here’s how the stand-up meeting works. Everyone gathers around, you stand up, and that helps keep it short, and you talk about first what you did, then what you’re doing, and then anything that might be blocking your progress. We’ll talk about how to deal with problems like that in just a second. Some tools that can help you out with that, if you visit Trello.com. They’re an online collaboration tool. Distilled used them as part of their creation of DistilledU, which is an awesome tool. And then the Meeting Cost Calculator, which you can get at bit.ly/meetcost, and you can also click in these links below us here.

So next, we have the principle of having a bias toward action, and really this is very simple. Doing is always going to be greater than not doing. So when we deal with problems like analysis paralysis, when we have problems like a politician who has the power to say yes or no, and here’s my favorite, when someone comes up to you and says, “It sounds like a good idea, but we just don’t do it that way,” agile helps us break that down, because we always go back to our user story and we say, “Well, this is something the customer needs.”

So what we do is we negotiate to “Yes.” What we do is, we find that ground that allows us to proceed with our work. There’s actually a role in agile that does nothing besides remove impediments to your work. So doing is always greater than not doing. And another hack that you can use is to just say no, because once you have your set of user stories developed, if someone comes around and tries to give you extra work or tries to say, “Well, you need to do this, and this, and this,” which happens quite a lot, the old, “Yeah, I’m going to need you to have to come in on Saturday and, yeah, maybe on Sunday too,” that doesn’t create value for the customer right now. What we have to do is get this prioritize user story out the door as quickly as possible. So we want to maximize the amount of work that we do not do by just saying no.

And our last principle is to “Don’t Hate, Iterate.” I’m stealing this from a colleague at REI. It’s just a great phrase. When we don’t release on a six-month or a one-year cycle, when we’re releasing every two weeks or every four weeks, we fall into Eric Ries’ “Build, Measure, Learn” model here, where we develop our products or we do our marketing campaign, we get it out the door, we launch it, and then we see how it works for customers. We have this measurement phase. We see how it performs, and you know what, if it’s not up to snuff, that’s okay. It’s all right. We learn. And then, two weeks later, we release a fix. When we do an iteration, we do something better that customers are going to respond to. And if that doesn’t work either, that’s okay. We go through the cycle again until we get closer and closer to what the customer needs to succeed in their goals.

And that leads to our final principle, which is “You’re Not Perfect.” I’m not perfect. Rand Fishkin is not perfect. He’s pretty good, but he’s not perfect. And that’s okay. We don’t want to be perfect, because perfect, chasing perfection holds us up in our work to get something out the door to customers. We don’t want that. We want to always be delivering, always be shipping to customers as fast and as quickly as we can. So you shouldn’t chasing the A+. You should be chasing what’s going to be valuable for your users. Go back to your user story. That’s what you need to succeed at. And if you don’t get there, it’s okay because two weeks later, you’ll have another chance.

So, I talked about this at MozCon, and you can download my presentation at bit.ly/agilewins. There’s also a link below. Please comment on the story. I’ll come in and try to answer your questions and direct you to more resources.

So that’s it. Thank you everyone, and see you next Friday.