Enter a search term such as “mobile analytics” or browse our content using the filters above.
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
I have written a lot about the opportunities of adopting an agile marketing approach.
However, it is quite hard to find many examples of this being practiced yet, particularly at any kind of scale, and even more particularly by organisations that are not start-ups. IBM is one such example and it is great to see B2B marketing leading the way here.
Ben Edwards is VP, Global Communications & Digital Marketing at IBM. He leads the company's global communications function, global advertising & media, brand strategy & design, digital strategy and IBM Marketing Labs.
Following is a transcript of an interview I did with him to understand IBM's thinking around agile marketing and how this is playing out in practice.
What do you understand by agile marketing and can you describe how your marketing operations run in an agile way?
There’s a broad answer and a narrow answer to that question.
The broad answer is it’s a way of collapsing planning and execution cycles into something much more continuous and available to be adjusted.
So, in software development you have a so-called waterfall approach where you do a lot of planning up front and then you execute or build based on a set of fixed requirements that are difficult to change (or involve a large change management process).
There’s an equivalent in marketing as well.
Traditional marketing has involved complex, heavy, expensive things like advertising and direct mail via print inserts. That sort of thing has used long upfront planning cycles and fixed execution.
As we move to digital marketing, just as we moved to digital products and digital product development, the cost of change and failure drops dramatically and there’s a great opportunity to collapse those upfront planning cycles into something much smaller and then iterate rapidly based on what you learn through short periods of execution, measured for outcomes.
So that’s the broad answer - collapsed upfront planning, iterative cycles of planning and execution based on continuous improvement.
The narrower answer is that marketing itself is becoming a technology-intensive business and the stuff we build in marketing, increasingly, is in software. So, we’re simply adopting best practice in software development.
What is it that we make in marketing? We make websites, web services, web applications, mobile applications. Those are the materials we use, so if we’re making that stuff we really ought to be following best practices in software development. And those best practices are agile.
Agile seems well-suited to production and delivery but are you able to apply to marketing strategy, planning and creative, too?
Agile can be done in many different ways. My view is one wants strategy itself to be a just-in-time type of exercise - pragmatic, adjustable and consumable by the teams that are building.
So, it’s not that you must put strategy into an agile process but it needs to accommodate an agile process.
It’s the same with design. It may or may not be in the agile process but it needs to accommodate an agile process. I need to be able to do just-in-time design that I can feed into a build team and help them with their next iteration of whatever they are building.
Ideally though, you want to put all of those things together. Think about what a marketer needs to do. A marketer needs to bring creativity to the challenge of engagement. Engagement is an increasingly complex and difficult proposition given the fierce competition for your attention.
The way we’re going to engage is through technology and analytics, increasingly though websites and mobile apps. What we need to do is bring the creativity of marketing together with the technology that we’re building in, in order to try to design and develop creative solutions.
Where I see the marketing industry going wrong, and where it continues to go wrong again and again, is it holds these processes separately. To think, somehow, that strategy and design is upfront from building is wrong. Technology and the materials you use have to be considered as a constraint to the design process.
What are you designing in? Are you going to design in paper then ask a technologist to build it? Well, the web isn’t made out of paper. The web’s made of data and applications.
So it’s really dysfunctional to hold planning and design separately from build and implementation.
How do you get agencies and staff working together in an agile way?
Agile is about collapsing cycle times between strategy and execution and collapsing handoff points.
The key principles of agile: you build an integrated, dedicated cross functional team and you give them everything they need and you empower them to go and solve that problem.
So, the traditional agency model of a client briefing an account manager, who then goes and briefs an internal team, who then goes and briefs the creatives, who then go and do work for four months and then come back – that’s not agile. That doesn’t suit the model, it breaks the model.
As part of our exploration of agile marketing we’re pioneering how we work differently with our agency partners.
The model we have is to forget about, for the moment, organisational boundaries and functional boundaries.
Forget about whether you sit in the technology organisation in a client or the marketing organisation in a client, or in product or R&D, or the creative organisation in the agency or in account planning and strategy – forget all that, park it for now and accept a simple set of rules:
- We need a dedicated team to be on the work full time.
- The team needs everything they need to do their work.
- The team has to be cross functional (we need designers, developers, content strategists, marketing strategists, UX etc).
Who do we staff that team with? Quite quickly if you start looking through that lens, the problem doesn’t become ‘how do we work with our agency’, the problem becomes ‘how do we get great talent?’
How do we cast great talent into a dedicated team? All you need is a physical space and a table and access to great talent. So, when I look at our agencies, I see companies that can attract, retain, motivate and engage great talent.
If we hold them as strategic partners and we retain them, versus treating them as labour to be squeezed, then they become a key source of that talent for staffing these agile teams.
So let’s look at agencies. Where in particular are they strong? That depends, agency to agency. Some of them are really good at information architecture and user experience, some of them are really good at visual design, some of them are really good at content strategy and marketing strategy and we need all of those things for this model to work.
So, it’s a very disruptive model for agencies as well as for us. But the proposition is ‘be our strategic partner, bring your best and brightest, we’ll engage them in really cutting edge work, we’ll help them grow their skills and we’ll bring you into our most important and most strategic work and you’ll learn with us.’
Given agile reprioritises all the time, how do you budget for agile marketing? How do you remunerate your agencies and suppliers when the deliverables are continually changing?
This is another key disruption point and a difficult point and frankly we haven’t quite got to the bottom of this one yet.
It’s a different model, which is the problem. The traditional model is ‘you tell me what you’re going to do and I’ll pay you for it’, whether that’s an agency or me and my CFO.
With agile, you don’t know what you’re going to do, not to that sort of level of specificity. You get clear on the goal or the mission for a team or teams, which is like a North Star.
You get clear on how they’re going to measure that, some quantifiable indicator of whether they’re heading towards the North Star or in some other direction, and then you let them figure out how to get there.
So, let’s take an example. You’re going to build me a website and it’s going to do X, Y and Z and it’s going to look like this. This isn’t how agile works. Instead, you’re going to help me engage this set of customers around this proposition and help me convert them to leads.
Figuring this out is a challenging notion for the traditional model because I don’t know what I’m getting. What I’m actually getting is a fixed capacity to do work. That’s basically what it is and that’s how one thinks about software development.
My goal is to make the fixed capacity as productive as possible by engaging the team in the right way, with the right methods, and providing them with the right environment and the right tools, as well as giving them the right opportunities for learning.
My second goal is to prioritise the work I put through that fixed capacity so that I deliver the most business value, the fastest.
That takes continuous engagement with project stakeholders, the part of the business that is funding the work. So, what the CFO is buying now from me is a fixed capacity to do work. The work I’m going to do is whatever needs doing.
And it’s the same with the agencies. We’re going to retain them to do work. We don’t exactly know what yet, we have an idea but that might change. And it always does of course, which is the irony, the non-agile model doesn’t work because what we said we’d build, we didn’t build and by the way we had to change what we were doing halfway through the year in difficult circumstances and do something else instead because the boss changed his view or the market changed etc.
So, it’s a difficult thing, prioritising work in the right way to increase productivity of a fixed capacity to do work.
What are your views on the nature and importance of the working environment in order to get agile working?
I’m very strongly in favour of physical co-location and that’s our model. And it’s expensive. We are physically co-locating a lot of people in downtown Manhattan at a high expense. I’m a big investor in that model because I see – and can count - instant productivity as a result.
If you’re not going to do anything else, get all the people you need to solve your problem and sit them facing each other at one table. And a lot of the people we need to do the work we do want to live and work in cities like New York and London. Once they are all round the same table, they’ll figure it out! Even without guidance and methods and tools – although those things will help them go faster.
The head of our growth markets business once told me about a problem of delivering hardware in China. There was an invoicing problem, a finance problem and a sales process problem i.e. a whole bunch of dependencies that different parts of the organisation had to fix in order to get this very important mechanical piece right so we could start fulfilling demand in the market.
He tried many ways to fix the problems but ended up getting a room in Beijing and getting everyone needed to fix the problem into that room. He put a bank of telephones in the middle of the room and he said to the sellers ‘call this number if you have a problem’. That’s all he needed to do. The team figured it out together.
What about virtual collaboration tools?
You can extend the physical into the virtual. Humans tend to treat virtual representations of humans as objects and not humans, if they’re anything less than 70% of real-life size. So those windows in Google Hangouts are no good. You don’t get that connection you need.
Secondly, and this is our anecdotal experience as well, if you get that human into a physical connection with the team first – fly them in for two weeks, have them sit on the team and bond – and then go back to virtual, the response is much better.
That person will be treated as a human, not as simply an email. We do that as a best practice.
All of our lab teams have 60 inch screens, and then we fly people into the lab and then fly them back out.
Does agile marketing fit with the IBM culture? How important do you think culture is in getting agile marketing to work?
It’s the most important piece. One way of defining culture in the workplace is ‘how we work’. And agile is how we work. So, agile instantly runs smack into culture, which is an emotional thing and a very difficult thing to change.
What I’ve noticed is that when you start talking to people directly about how they work, and try to change the way someone works, you often get the reaction that you’re actually insulting them at a very deep level, like you’re telling them they don’t know how to do their job and questioning their professionalism.
That’s obviously massively counter-productive, so I’ve learnt not to talk about it. What I’m looking for is risk-takers and innovators who were born with the desire to do things differently. Invite them to work with us in different ways. Everyone who has given it a go in some serious way becomes passionately in favour of it. It’s more productive, more enjoyable, more empowering, you get better momentum and better results.
Once you get over the hump of talking about it and not wanting to change the way you work and you actually do it, then things start to change.
That’s how we’ve been working on it, literally one by one. One team at a time we’re inviting people in. At some point it reaches a tipping point where everyone starts talking about this thing that we’re doing, then you get the next wave of people coming in who are following that first crowd of early adopters.
So, it’s very challenging. Most companies I’ve worked with haven’t had this culture. It requires high degrees of trust for the teams. You’re giving them a lot of autonomy and you’re making a lot of change to existing practices. To get started you have to create a protected space for that to happen and shelter that space from the prevailing culture.
Find those early adopters, get them on board, allow them to tell the organisation why it’s great, make yourself pretty much invisible to the organisation because it’ll otherwise reject you, and build momentum that way.
How do people react to this way of working? Does it appeal to certain personality types, or marketing disciplines, more than others?
I’m not sure if it applies to certain marketing disciplines or not. There are certainly people who want to work in this way and there are people who don’t. The dividing line can be described in different ways but one of them is an aptitude for, or a thirst, for learning.
You’re asking people to step out of a mentality of ‘I do this’ e.g. ‘all I do is development, I don’t do design and I don’t do content and all these other things, I just do development. I’m just sat here at my desk waiting for the design to come, then I’m just going to code it quietly myself then pass it on to whoever needs it’.
We find there are people like that and they don’t do well in this lab environment. It’s messy and cross-functional and we’re asking the teams collectively to sign up to a business objective not to be responsible for just making a widget (as an example).
And the same is true of designers. Some say ‘I don’t get involved in production, I do design, a much more elevated thing. I am a creative.’
I don’t understand this agency language of creative. They have creative departments. So everyone else is not creative? Who comes into work everyday to be uncreative?
You have to agree with this proposition that creativity emerges from collaboration across many different types of skill sets. You need to be able to learn. If you’re an advertiser creating short films you should learn about what it takes to build a website – wouldn’t that knowledge allow you to be able to be more creative on the web?
You have to want to learn, to want to operate where the boundaries of functional silos are blurred. Ultimately we’d like to staff every team member with the skills they need, that’s the ultimate, we need generalists.
How do you scale agile marketing?
Scaling is difficult. But we’re cracking the problem. I think of these teams like racehorses, and they’ve got blinkers on because you’ve set them up with this singular purpose of achieving a goal and then you give them everything they need and they’re fully empowered.
They are very exotic creatures. You unleash some real athleticism there but they’ve just got that single goal in mind and they’re running for the line very fast.
The challenge becomes if you’ve got more than one team, how do you start to create peripheral vision and integration across those teams? At what points do you need integration – tech level, platform level, services level, API level, design level and integration with scaled production capabilities.
Ultimately, integration has to come together at the customer experience level, it has to come together, if you’re building tools for marketers, in the marketing user experience.
So how do we achieve that? That’s tricky and that’s the scaling problem. One of the things we’ve done, we have a group of teams in our lab in New York that are actually working with our technology office to create tools and services for our marketing and communications professionals to accelerate the digital transformation of our marketing function.
There are eight of those teams building things like content authoring tools, content APIs, content services, nurture services, interfaces for inside sellers and direct sales teams and so on. And we’ve taken that shared table philosophy and used that, we’ve sat them all together and they all talk together, those teams.
Another thing is how you create a just-in-time design function that looks across these teams integrating and synthesizing the customer experience, the marketing user experience, the API and service layer etc, but then takes the output of that synthesis and drops it into the individual teams for work they need to do. That’s a delicate and difficult thing to do.
Scale is probably the biggest challenge of agile.
What have you learnt from doing agile marketing?
My first transformation was a technology transformation not a marketing one. I ran The Economist digital media business, did an agile transformation of the technology team that built the website and associated functionality for the advertising network.
The reason we adopted agile there wasn’t anything to do with planning cycles, we had a chronic quality problem. So the quality of code was poor, our website kept falling over, the availability of our web applications was poor, our ad network was failing, the tech platform was failing. At its core, we had acquired a bad quality problem.
If you think of project work as the iron triangle of time, quality and scope, something has to vary in that equation and what was varying was quality, because time and resources were fixed and scope wasn’t being managed, it just kept going up.
So what agile does is it strictly time-boxes work and forces adherence to quality standards. The quality transformation is about negotiating with the teams, over time, higher and higher levels of quality in the definition of what work is actually “done”. Scope is what we allow to vary – it’s whatever next-most valuable work we can get done during the next time box at that fixed level of quality.
That was the first transformation and we had some success from that. We learned that the agile method can absolutely fix a quality problem if top management is committed to doing that and recognises that’s at the core of the business problem.
And absolutely, agile can be applied more broadly to different types of planning processes to break down those processes into iterative cycles of development (in the broad sense of the word). That releases a lot of momentum, productivity and value. Marketing is one category we’ve applied it to.
I’ve also at one point applied it to my management team. We got to the stage where we would tee up these giant problems that we had and then we would stare at them and then talk about them and they got bigger and bigger and we wouldn’t do anything. The mountain gets bigger and bigger and you’re paralysed and you go back to what you were doing before.
I said, look, I’m done with these conversations, we all know the problems in the organisation, we’re all very familiar with them, put them to one side, the only thing we’re going to talk about is what we’re going to get done in the next two weeks, and we’re going to run an agile cycle. Then we will decompose our management work into things we can get done in the next two weeks. And we’ll hold ourselves to account for the things we’ll get done in the next two weeks. Run a backlog and go through it. It was very energising. We started taking small steps towards making things better, and we began delivering progress.
Turns out, people feel better about the work they do when they work that way – and you get more engaged employees.
On the management front, my views of what I do and should do have changed a lot in the last six to seven years. I guess I was guilty seven years ago of this idea that we only get more out of an organisation by pushing harder.
Think of water flowing through a pipe. How do I get more out, do I increase the pressure? That’s not my view now. You look at the pipe and find and remove the biggest blockages. This is a core principle of agile, it comes from lean manufacturing and the Toyota Production System in the 1950s – the people on the line were the ones with the most knowledge about making things more efficient, so listen to them, fix it and improve the flow.
You tell me what your blockers are, I might push them back, but some of them I can see you can’t fix and I’ll help you with them. It’s my core management activity. Build the right environment, find great talent, unblock the teams, give them what they need, clarify where they’re going and how they are going to measure progress and let them at it.