The issues dogging marketers in the digital age don’t really have a single set of dependable solutions. Just because something works today, you can’t assume it’ll work tomorrow. The rapid pace of social and technological change, the proliferation of potential channels for reaching your audience, and the glut of online content vying for consumers’ attention—these and other challenges call for strategies that are much more agile than your more traditional campaign plans.
The agile revolution originally began in the realm of software development, where it continues to this day, as pioneering companies like Netflix and Spotify keep pushing the boundaries. Meanwhile, people with experience in both software development and digital marketing, perhaps foremost among them MarTech editor Scott Brinker, point to a growing overlap between the two fields.
In his book Hacking Marketing: Agile Practices to Make Marketing Smarter, Faster, and More Innovative, Brinker writes:
“Like software, the cadence of marketing has accelerated dramatically. Detailed and rigid long-term plans are largely a fantasy. This is partly because our business environment can change so quickly, as disruptions ripple across the Internet from an ever-expanding set of adjacent competitors and influencers. But it’s also because the speed and adaptability of digital life has raised expectations: People inside and outside our organizations expect that marketing will respond to feedback in a timely fashion.” (43)
Is it time for us marketers to start being more deliberate in our application of agile principles to our work? Should we try to map our daily and weekly tasks onto an agile framework like scrum, as Brinker, along with the writers of The Agile Marketing blog and companies like Workfront enjoin?
Or is agile just the latest industry buzzword, something we pay lip service to without ever seriously trying to implement?
Marketers in the old days would launch a campaign and sit around waiting for months to see if sales picked up. Now, in the digital age, we have access to copious data from myriad streams—in fact, the sheer volume of data can present a challenge in its own right. Nevertheless, in principle at least, we should be able to measure the effectiveness, not just of campaign strategies in general, but of the individual tactics we use to support them.
Launch-and-wait has been replaced by publish-and-track.
Many marketers believe they’re being agile whenever they closely track their performance metrics, pushing the gas on whatever they see moving the needle in the right direction and pulling back on whatever fails to deliver. This type of responsiveness is, however, only part of what members of the development community would call agile.
Specific agile frameworks like scrum first arose in the early 2000s as an effort to tame the complexity of large-scale application development. Scrum involves breaking big, complicated projects down into much smaller, more manageable iterations, each of which culminates in a chance to get user feedback and make any necessary course corrections. This feedback comes from a representative of the business users and project stakeholders, referred to as the Product Owner.
Unfortunately, most marketers attempting to adopt scrum don’t have access to user feedback anywhere near as direct as what they’d get from an appointed representative of the client. The user in the case of most campaign material is the prospective customer. Not many companies can afford to host focus groups or conduct surveys at multiple points during a campaign rollout. (Getting user feedback is of course also a challenge for developers of consumer-facing software.)
The first question then is, does all the new tracking data available to marketers serve as a viable stand-in for feature demos and user acceptance tests?
But there’s yet another important question you’ll need to answer before you can get up and running with scrum: How do you fit your tasks into the short project iterations—known as sprints—which make up a central part of the framework?
Each sprint is devoted to pulling what’s called a user story from the Product Backlog and developing the feature that will support it. The Backlog is the list of all the user stories—descriptions of individual business functions—the software will encompass, all of them arranged in order of priority.
Sprints in the software realm last for some set period, typically between one and three weeks. At the end of each sprint, the dev team demos the feature they’ve built to make sure it meets the user acceptance criteria and is consistent with the stakeholders’ vision for the overall application. Obviously, the developers can’t show the feature to every last person on the client side; that’s why they appoint the single Product Owner as a representative.
Who should take on the Product Owner role in a marketing context? A marketing consultant could potentially serve in this capacity, and you also have the option of continually referring to your buyer personas—fictional stand-ins for your ideal customers—but both of these workarounds have their obvious drawbacks: the potential distortions of indirectness and abstraction prominent among them.
Can marketing performance metrics and internally appointed Product Owners compensate for the lack of periodic user feedback that’s such a crucial part of scrum? Even if the answer is yes, the lengthy amount of time it takes to identify trends in that data could very well still undermine the idea of short sprints followed by feedback-guided course corrections.
As a digital marketing and technology firm that’s been doing scrum software development projects for years, our teams at Aptera have been working closely together to explore opportunities for cross-pollination of ideas between departments. We’ve had some successes in our attempts to go agile with our marketing, but we’ve had quite a few frustrations too.
Below are three of the major sticking points that we’ve run into that will probably present difficulties for you should you attempt to apply scrum to your digital marketing practices, even if you do so with the help of marketing automation and analytics tools:
Software developers work in sprints of about two weeks. Marketers could of course divide their tasks and tackle them in one- or two-week intervals, but few of the agile marketing advocates bother asking what value sprints have when they don’t end in a chance to get user feedback.
To be fair, Brinker describes some ways marketers can work in sprints, and he even discusses some of the benefits that may accrue from doing so, foremost among them the degree of focused attention on top-priority tasks they encourage. What he doesn’t discuss, though, is whether these side benefits make up for the absence of user feedback that makes working in sprints so effective in development contexts.
Here’s the crux of the problem: the effectiveness of an inbound lead generation strategy can usually be measured on a timescale of six months—and that’s best-case. In other words, it can take as long to get feedback on the deliverables from any sprint in marketing as it takes to develop an entire application.
At the end of any two-week sprint, while you may be able to answer questions about process efficiency, you have nothing on which to base any evaluation of tactical effectiveness. You’re going to go through at least a dozen further sprints before you start getting any meaningful feedback on the sprint you just completed.
So what’s the point?
With software, you’re presenting the Product Owner with a tool designed to serve some function for the user. You get a thumbs-up or a thumbs-down with further instruction. This directness is possible because you and the Product Owner are on the same team.
The audience for your marketing material, on the other hand, has no stake in the project whatsoever. They don’t care. Really, your job is to make them care. So how will you know if it’s working?
Most of the advice you’ll find about agile marketing sticks to generalities, and that’s largely because many diverse practices fall under the rubric of marketing: web design and development, blogging and other forms of content marketing, social media and channel marketing, influencer outreach, guest contributions, account-based marketing, and so on.
Now, software gets developed for diverse purposes and interfaces as well, but the Product Backlogs of marketing campaigns can get ridiculously complicated ridiculously fast. Scrum applied to a social media strategy will probably look very different from scrum applied to blogging and e-book offers—even though these aspects are involved in nearly every campaign.
In most marketing departments, workers have a number of different specialties. There should also be some specialization within dev teams—coding, Quality Assurance, operations—but these roles probably overlap significantly more than those of a web developer, content writer, graphic designer, SEO, and social media expert.
It would be great to form cross-functional teams with experts in all these areas, but the reality is each worker’s time will almost invariably be spread across multiple projects, making it all but impossible to avoid a more waterfall or assembly-line approach: you do your part first, I’ll do mine second, and so on.
So, as your company makes the move to agile, you’re going to have to decide which narrowly defined areas to focus on first, and you should probably start by asking which areas stand to benefit most from agile practices.
The success of scrum can be ascribed in large part to the way it defines a unit of work. A lot of discussion goes into each user story that comprises the Product Backlog, but the goal is to reduce it to something manageable, something that can be accomplished in the span of a sprint. In development, this usually means a software feature that helps the user perform some work task.
So what constitutes a good user story in marketing?
The first challenge you run into is the diversity of tasks and roles discussed above: a blog post, a Facebook update, a layout for a homepage—what part of digital marketing is being broken down into manageable units? Talk about Kanban chaos.
The factors that really should determine your definition of a unit of work are what type of feedback you’re getting and when that feedback would be the most useful. Features are the units in software because they’re the smallest parts that can be tested. The demos happen as one sprint ends and another begins because that’s when feedback is most vital.
What usually ends up happening in marketing, though, is that sprint duration is established arbitrarily—“The dev people do two weeks, so…”—and the user stories get defined as whatever the worker can reasonably be expected to accomplish in that time.
You won’t get any meaningful feedback until long after the sprint anyway, so really the only point of the user stories in the first place is to clarify your goals and focus your concentration.
But do you need scrum for that?
The agile revolution in software development took its inspiration from the lean revolution in auto manufacturing, led by Toyota. But nowhere in The Toyota Way, Jeffrey Liker’s book about the renowned Toyota Production System, will you find any mention of Product Owners or sprints.
There was never any one-to-one mapping of the fourteen management principles identified by Liker onto the practice of developing software to arrive at the twelve principles laid out in The Agile Manifesto of 2001. (Liker’s book wasn’t published until 2004.)
Lean manufacturing, in other words, doesn’t provide an algorithm for managing software development projects; it provides a metaphor.
An algorithm is a logical process, like those in mathematics, that produces the same outcome regardless of the physical substrate: if you add 5 plus 5 in your head, your brain will give you the same answer as when you type it into a calculator (I hope). A metaphor, on the other hand, is a comparison between two things meant to highlight certain abstract features they share in common—or to encourage the application of insights from the one domain to the other domain.
Just as the pioneers behind The Agile Manifesto had to make adjustments to the principles of lean manufacturing before they could be applied—or not applied—to software development, we may need to make similar adjustments to agile frameworks like scrum if we hope for them to have any relevance at all for marketing.
Instead of trying to map software development practices directly onto marketing tasks, we should try to distill agile and lean philosophies down to their most vital principles. From these first principles, we can work our way back up to a more general framework for agile marketing. Here are what I take to be the three most basic elements of lean and agile approaches.
At Toyota, any worker can pull the famous Andon cord and halt the production line. The idea is that the people who perform the manufacturing tasks every day can form a first layer of quality control. If problems are fixed early in the process, you can avoid having to disassemble the vehicles later on to find them. You end up saving your team a great deal of work.
At the same time, you can avoid future problems by identifying issues with your tools or processes. Whenever the Andon cord is pulled, the production team goes through the 5 Whys to get to the root cause: “Why did you pull the cord?”, “Why did that problem arise?”, “Why did the cause of the problem occur?” and so on.
We’ve already covered the role of the Product Owner in providing feedback within the scrum framework. Indeed, the close collaboration of a client representative is probably one of the most important adjustments in the move from manufacturing to software.
Leaving aside design issues, the primary function of an automobile is a given; not so with business software. That’s why it’s important to have someone assess each feature as it comes online to ensure it serves the intended function. And that’s why agile software development works in the shortest possible iterations—long enough to develop a working piece of software to deliver to the Product Owner.
But dev teams keep trying to push this principle even farther. With the rise of Test-Driven Development and Automated Integration Testing, developers can see if their code is sound and bug-free as soon as they’re finished writing it. Some even describe pair coding, in which one developer observes the code of another working at the same station, as a way to get more immediate feedback, thus improving quality.
The foundational principle here is that you can avoid building in, or building over, mistakes if you have better and quicker ways to check your work. That saves you from having to undo or redo the same work over and over again. Frequent testing and feedback can also save you from wasting time and effort chasing after the wrong goals—which brings us to the next pillar.
Trimming wasted time, effort, and materials is what makes a production line lean. In manufacturing, you create a map of your value stream and ruthlessly cut away waste (muda), defined as any part of the process that doesn’t contribute to the goal of giving customers what they want.
With software, this principle is translated into the practice of taking on features one at a time, the most valuable first. At a point during each sprint, the Product Owner “grooms” the Backlog, perhaps adding or deleting user stories as the overall vision evolves, but often simply rearranging them to reflect adjusted priorities.
So you’re encouraged to do one thing at a time, starting with the most important, and make sure it’s right before you move on to the next item on the list. Scrum even has a practice that’s analogous to Toyota’s 5 Whys called the sprint retrospective. This is a meeting of everyone on the dev team to discuss what went right with the latest sprint and what went wrong, with the purpose of improving processes over the course of future sprints.
The Toyota Production System relied on what would become known as Kanban, a method for visualizing and managing the flow of production. All the manufacturing tasks are written on cards and moved across a board as they pass through their sequential stages. The idea is to make progress visible to everyone, thus allowing the teams to make decisions by consensus.
Likewise in scrum, the idea is to take on decisions and tasks as a group. That’s actually where the name scrum comes from, as developers are encouraged to get away from the relay-race or assembly-line approach to projects and instead apply a rugby approach, moving the ball down the field as a unified team.
Scrum does leave some room for specialized roles, as even Quality Assurance experts are brought in at various stages of each sprint. But you’re no longer handing over the work to the next person at the next station.
In both domains, this team approach is designed to facilitate the sharing of insights, and to make it easier to incorporate those insights into the overall strategy as early in the project as possible, resulting in more innovative improvements to the process.
Assuming we can agree that the scrum framework doesn’t map perfectly onto digital marketing, we’re left wondering whether the lean and agile philosophies may still provide some guidance as we tackle the challenges highlighted by agile advocates like Brinker.
What can we learn from a more metaphoric, as opposed to a strictly algorithmic, application of scrum to marketing?
1. While there are clear limitations on how tight you can make your feedback loops, it’s still important to set goals in terms of the needles you want to move. You can then work backward to lay out the steps you’ll take to move them. This way, you can determine what your team should be focusing on at any given moment by figuring out what’s most likely to have the biggest impact.
For example, if you’re devoting exorbitant amounts of time and resources to creating plans and roadmaps that you end up never even implementing, you don’t need performance metrics to tell you you’re being wasteful. You should instead be keeping track of how efficient your planning is and avoid putting more effort into highly detailed long-term plans than they’re worth, especially if you’re routinely making course alterations midway.
2. Scrum’s imperative to take on one task at a time, highest-priority first, is likewise helpful in avoiding wasted effort. Useless over-planning is a good example of this principle as well. Additionally, some companies may be able to afford letting their marketers experiment—or play around—with posts on a new social channel, but most of us will want to target the channels where we’re most likely to reach our buyer personas.
This isn’t to say you shouldn’t experiment, but experiment deliberately, testing a clear hypothesis. Why do you suspect posting to this channel may be effective? How will you know if it’s effective, and how long will it be before you know? What will success look like, and will it be sufficient to outweigh the costs?
This sort of hypothesis-testing is central to our most successful application of scrum methods to digital marketing, an agile approach to web development called Results-Driven Design. (We developed this approach around the same time as HubSpot was developing their own Growth-Driven Design process, and our methods borrow significantly from theirs.)
3. We’ve discussed some of the issues that arise when you try to create cross-functional teams within marketing, but there are obvious advantages to keeping everyone involved in a project on the same page. Visualization and management tools like Kanban boards can be immensely useful, if you can manage to keep them relatively simple—a big if.
The most helpful insight here may not be that your marketers should be moving projects forward like a rugby team. It may rather be that your marketing team needs to work closely with their clients, whether internal or external. That is to say, the most fruitful exchanges may not be between different types of marketing expert but between marketers and workers in other verticals.
The marketers at Aptera could theoretically create an entire campaign to promote our software development vertical, for instance, without ever talking to any of our developers to find out what makes their approach unique. Or we could appoint an internal Product Owner from the software team and treat the campaign as a collaborative enterprise spanning both departments. We could likewise appoint Product Owners representing each of our external marketing clients.
Since you’re supposed to be going to the users or the consumers of your products for feedback, using clients as Product Owners only partially addresses the issue. But having insight into the products and services you’re marketing can help you narrow your message and better target your audience. It can also help you create more valuable content to fuel your campaigns.
Finally, while the users whose opinions and impressions you’re ultimately trying to influence may remain out of reach on any timescale relevant to your current sprint, it doesn’t hurt to make your clients happy in the meantime. Giving clients a chance to tailor the message you’ll be broadcasting about them, and assuring them that you’ll be conveying what’s truly remarkable about them, will go a long way toward achieving that goal.
Of course, at some point you’ll still have to deliver results. And that still means influencing those prospects you have to wait so long to hear from.
Is scrum your best bet for succeeding in this? We’d like to hear what you think?
Other posts on agile: