Tag Archives: technology

A Marketer's Guide to Agile Development

A Marketer’s Guide To Agile Development – When a Turf War Is Justified

Leave a comment

Marketing and Technology both play for the same team – the organization that employs them. Turf wars between the two departments sap efficiency and impede progress. Turf wars are bad. Turf wars should be avoided. Except in the rare cases when they need to be fought. When’s that?

ONE TEAM’S WRITING CHECKS THE OTHER CAN’T CASH

If a non-technical executive is buying a tool that will impact server capacity and performance, the technical side of the house must have some say in the purchase. Even if IT isn’t paying for it. It’s not reasonable to expect the tool to work properly if you’re crunching ten pounds of data into a five pound server. Or if IT unilaterally makes the decision that 24-hour latency is sufficient when Marketing research shows real-time processing is essential, IT has some ‘splaining to do, and Marketing may have to fight for a better outcome.

THE OTHER TEAM’S GLACIAL PACING IS RACKING UP BIG OPPORTUNITY COSTS

Watch it on this one.
1) Is the delay actually hurting the company — not just hurting your reputation with your boss or your bonus?
2) If it’s genuinely hurting the company, can you quantify the damage caused by waiting?
3) Is the damage substantial?
4) Have you exhausted all attempts to present this evidence to the other team to goose them into action?
The answers to all four questions must be “yes” to justify the disruption and unease caused by wresting a project from a too-slow colleague. But if all four are “yes”, tell your counterpart that you have to act. Then do it.

YOU KNOW SOMETHING THEY DON’T KNOW

For instance, UX is an area worth a turf war. Email is another. If someone without deep knowledge of best practice claims ownership of either area, deep damage can result. This can come from both sides. IT can claim they own design architecture and UX’s recommendations are just an opinion they can take or leave. Or Marketing can pound their chests about how they own the messaging and no one has the right to tread on their First Amendment rights as they carpet-bomb the populace with inbox impressions. Either of these situations demand an intervention to preserve the commonwealth, by the most knowledgable grown-up in the room. Who is that grown-up? The one who can back up his or her mouth with the best evidence.

Play nice with the other kids, now. No shoving. Or, no unnecessary shoving.

A Marketer's Guide to Agile Development

THE CIO/CMO RELATIONSHIP – A Marketer’s Guide to Agile Development

Leave a comment

Some observations from the Forrester CIO/CMO Conference last week:

A COMBO CIO/CMO – LONELY AT THE TOP, BUT AT LEAST HE HAS EACH OTHER

Ponder the possibilities of one person serving as both CIO and CMO of the company. I have heard of two examples of executives doing this so far, one of whom I met at the conference. Leadership of both Technology and Marketing is a formidable reponsibility to shoulder on one’s own, but it does yield some advantages. For one thing, if you need to bogart some budget dollars, you don’t have to strongarm or cajole your counterpart. You just reach into the other pocket.

The CIO/CMO I met said that one of the secrets to avoiding getting overwhelmed was requiring all projects to have a 5-year cost/benefit plan. This weeds out a lot of ideas that don’t have strong legs from ever reaching the backlog. And, it weeds out a lot of “hey, wouldn’t it be great if….” mavens who don’t want to do the hard work of figuring out a project’s worth to the enterprise. And Agile development practices ruled the day there.

THE IT DEPARTMENT CHARGEBACK SYSTEM IS SEEN BY SOME AS A WORST PRACTICE

I heard an executive from a well-established company complain that, at her shop, the estimate for her Technology department to load a single marketing database table is three months and $50K. She swore it was not an exaggeration.

For many of us, it’s all we’ve known – the IT department as a cost center. You initiate a project, the hours the technology team spends building it gets charged to your project. Sometimes the hours it spends estimating the hours it will take to build your project are charged, too. It can be a catalyst for an adversarial relationship.

Let me know if this sounds familiar. Marketing battles it out and wins a place on the sprint. The project is built, but Technology had to jettison non-essential but user-friendly features in order to make the release on time. Without those features, it’s a clunky user experience. So adoption sucks. Marketing says that’s because the project’s not done – original features aren’t in there yet. But Technology says it is done – Marketing agreed to the changes in order to make the deadline, now those original features are enhancements which need to go on (cue ominous music…) the backlog. The CMO explodes when she hears this – she’s getting graded on customer adoption, which sucks right now. With arm-twisting, the features get crammed into the already-tight current sprint. Nights and weekends. Overtime. Enough times on that merry-go-round, and eventually IT starts sandbagging the estimates to protect themselves. So now it takes three months and $50K to load a table.

Some companies have combatted this broken system by making the CIO and the CMO equally accountable for metrics like adoption and customer satisfaction. The CIO and the CMO then have a really good reason to agree on the definition of done – their wallets. Another way companies have remedied this is for the CIO and CMO to work as partners – literally, not figuratively. Meetings several times during the day, offices next door to each other, one executive is never without the other in important meetings. They’re Butch Cassidy and the Sundance Kid, only with separate posses.

BEST PRACTICE COMPANIES DON’T ASSUME THEY KNOW

“If I were a user, I would want.”

“I just know.”

“Users liked this, so they’ll probably like that.”

You’d never hear these phrases in some shops. Best-in-class companies wouldn’t dream of mass-marketing or going live with something new they haven’t rigorously tested with users. In fact, one example in one of the keynotes was the application of technology specifically toward making testing easier, quicker, cheaper, and more nimble. These were big-money projects, but there was not even a question of whether they were going to test – the only question was how efficiently. Testing isn’t exactly sexy – but it’s necessary, and often skipped by less committed shops. But robust testing is what happens when the CIO and CMO are equally committed to producing outcomes and not just projects.