A Marketer’s Guide To Agile – Top 7 Reasons Why Your Data Is So Crappy

How and when data is captured is a vital part of decision-making in call center scripting, digital architecture, sales presentations, just about everything that touches a customer. There are things you can do to help make it better, but some issues will be always with us. So, here’s why your data is crapola, in no particular order…

1. TEXTING (yes, TEXTING)

In the data world, spelling counts. Whether data is being entered by professionals or by the customers themselves, text fields will be rife with errors. That is true no matter how clever you get with the drop-down boxes or type-ahead functionality. The proliferation of text-speak has made this worse, and spelling is rapidly becoming a matter of personal choice. That doesn’t bode well for text-mining. And no, spell-correct is not the antidote. Entire websites are devoted to how that can go horribly and hilariously wrong.

2. IT WORKLOAD

“Why can’t the digital dev folks just put another box in the online form so the prospect can enter their promo code?”

They can! They will! Just as soon as that work order rises up to the top of the priority list. Right now the project manager has it in the backlog. Where work orders go to ripen, get covered with brown spots, and die.

3.BAD DROPDOWNS

The data was shocking. Month after month, nearly a third of all disenrolling customers were dropping service due to bankruptcy. Nationwide. All segments. So I planted myself in the call center for a few days. In the CRM system, the drop-down box marked “Reason for Leaving” had 35 choices. “Bankruptcy” starts with a B, so it came up at the top of the drop-down. Too bad “Alien Invasion” wasn’t one of the choices, it would have been caught more quickly. So, yeah, that happens. In my experience, 12 choices is the limit for an effective drop-down in a call center. Any more than 12, and boom – 30% of the country mysteriously goes bankrupt.

4. POOR REQUIREMENTS

The marketer: “This email address is blank – it should be a required field.”
The analyst: “Someone input their mailing address in the email field.”
The email vendor: “Lots of these email addresses are undeliverable.”

Coding an email field with an input mask requiring a “@” character and a period will solve the analyst’s problem. Making it a required field will mean 100% of records are populated, which will satisfy the marketer (at least temporarily). Coding an email field with that input mask plus making it a required field will get you a lot of bad email addresses like “noneofyourbiz@buzzoff.com”. That can get you blacklisted with ISP’s. It can also spike your abandonment rate on the digital form page.

But marketers – it’s not the developer’s job to know that – it’s yours. He or she will code to your requirement specs. Think through the ramifications of stakeholder requirements – and make sure the requirements reflect a considered decision.

5. USER EXPERIENCE

First, let’s get one thing straight. UX and good data capture are NOT mutually exclusive. But what’s great for data capture isn’t always great for the user experience, and the two must be balanced. I once had an HR stakeholder tell me that data was vitally important to her, so it was a requirement that users submit 10 fields of personal data into a web form before they could browse jobs on the company’s career site. I told her that strategy would get her the best data and the three most committed job seekers she ever saw. The rest would bail.

6. COMMUNICATION

The promo postcards start hitting consumer mailboxes at 8am, and the TV ad blitz started airing at 9am. The campaign is a hit! Responses galore! Great! Except Marketing forgot to notify the Customer Service Manager that the promo schedule had changed, so she isn’t staffed up for the traffic onslaught. The unfortunate reps that are schededuled today can’t keep up with the volume. Calls are going unanswered. Their priority today is not great data capture. Their priority today is to take as many calls as possible and make it through their shift alive.

7. INCENTIVES

Sales reps’ income largely depends on how many sales units and revenue dollars they bring in. For customer service reps, bonus criteria often include average handle time, time-to-answer, off-hook time, etc. Sometimes data accuracy is part of the incentive formula, but it’s almost never the lion’s share. Generally, when short-term incentives are introduced for better data capture, data capture gets better. And when the incentive period is through, the gains recede, although hopefully to a little higher than baseline.

Data Analytics – Define Channel

“A third of our sales are coming in through the web channel – let’s move budget from direct mail into display ads!”

Whoa – display ads are in the digital channel – but is display actually driving those purchases? Would more display ads drive in more purchases?

What do you mean by channel exactly? What if I respond to a direct mail piece by calling your Inbound Sales Center, then go onto your website to make a purchase? Which channel do you attribute me to – Direct Mail, Inbound Call or Web?

The answer is that every response has two at least two types of channel attribution.

One is the marketing stimulus channel – in this example, Direct Mail. The other is the response channel – in this example, Inbound Call. In many cases, a third channel is the purchase channel – in this example, it’s Web.

Moving money from Direct Mail to Display might be the right move – or it might cut off the main pipeline into your purchase funnel. I don’t want to make your head explode – but there may be a combination of market stimuli that constitute the actual Market Channel. It’s another facet of multi-channel attribution.

So you’re not measuring all this precisely? You’re not alone – many firms, even some really big ones you’ve heard of, aren’t doing it all that well either. Getting attribution right is a commitment – time and money – and is an iterative process. It should ultimately answer the question of where to spend your marketing money, gaining more precision with time.

How Data-Driven Marketing Contributes to the Class Divide

Once on a calibration call, I heard a customer service rep actually tell a customer who was doggedly asking for a better rate something like “You’re one of our low-segment customers. No matter how many times you ask, none of you guys can get that rate.”

Clearly, that rep was seriously off-script. But the segmentation score on her CRM screen told her that the company didn’t value this customer very much, so she didn’t either. I built the segmentation model that told her that. For me, it brought into stark relief how marketing segmentation can affect dynamics far down the road.

In many years in the field, I’ve seen the good that data-driven marketing can do. It makes online life more relevant. It helps businesses stock products their customers want to buy. But the intrinsic power of data analytics to segment a population can also be wielded to divide it.

The last twenty years in which database marketing has hit the big-time coincides with a period of increasing polarization between rich and poor. I’m not suggesting that segmentation causes this polarization. Rather, it’s that it helps drive the wedge, already in place due to a complex mix of social, economic and political factors, deeper.

The objective of segmentation is to enable businesses to target their marketing capital toward the acquisition and retention of those customers yielding the greatest profit. There isn’t anything wrong with this, per se. Making money is what businesses are supposed to do, and it is the responsibility of their marketing organizations to help make that happen.

Customers and prospects are identified by their potential to enhance the bottom line, and strategies are crafted to reward the more desirable segments for doing business with them and not reward less desirable groups for it (or even subtly discourage them from it). The most profitable customers are not always the wealthiest – but let’s face it, it’s often the way predictive models will tell you to bet.

Predictive and yield models tell builders how to market and build most profitably. A prospect who can only afford a $195K house is courted by no one and can’t find a new house to buy. A prospect who can afford a $950K house is courted by everyone and has plenty of choices.

Profiling will tell businesses which customers are likely to have the wherewithal to pay on time and upgrade to more profitable products. This insight will be incorporated into the firms’ CRM systems. Those segments will receive the best offers, the special concierge customer service phone lines, the waived fees. There might also be “aspirational” or “elite-in-training” groups that get slightly better treatment in hopes that they will start behaving like the elite groups. And the other segments?

It costs them more to do business. They pay more for products. They have to wait in a longer phone queue for customer service. As for the service they do get when the phone is answered, there is no scripting in the CRM system that explicitly says “you don’t have to go the extra mile to treat this customer well”. But it’s pretty much guaranteed that some harried customer service reps will (perhaps in a rush to minimize the Average-Handle-Time metrics they’re bonused on) interpret it that way.

Before analytics, businesses often had policies that every customer should be treated like they’re the best customer – because absent the data, the assumption was that every customer had that potential. But in the data age, there is no more benefit of the doubt. When people complain that customer service doesn’t exist anymore, they’re wrong. It’s still alive and well – it’s just heavily up-market.

To reiterate, marketing segmentation and analytics did not cause the class divide. That has existed for millennia. Let’s at least be aware about how marketing analytics contributes to it in present day.

A Marketer’s Guide to Agile Development – Why Fear Makes People Reject Your Data

“I don’t take much stock in fancy marketing research – Sales knows our markets best.”

Testing showed the dimensional mail piece Sales loved actually performed abysmally. The plain letter they didn’t like (not colorful enough, boring) produced the most leads for them. The “I know best” contingent started to come around when they realized how many leads they were leaving on the table. Rejection can be the first reaction – don’t give up. Don’t go away. Sales was afraid that acting on data rather than their own hunches would make their opinions and recommendations less valuable. Framing the data as assistive rather than directive made it possible to move forward.

“That can’t be true.”

Counterintuitive findings must be presented very carefully. That goes double if the presentees are top execs. First reactions to surprising data are often disbelief, discrediting the methodology at best, and/or shooting the messenger at worst. Have bulletproof backup supporting your results – including visuals – especially if it’s negative news. Be mindful not to make them appear stupid or clueless, or your data (and possibly your career) won’t get beyond the conference room.

“You’re not telling us anything we don’t already know.”

Hard-working folks in the trenches can feel threatened when those slick marketing folks waltz in and act like they’re The Oracle of Delphi, spouting wisdom. When the data supports collective intuition or anecdotal wisdom, you’d think they’d be happy. Yet, the trench-dwellers often declare instead that the research adds no value. Tell them they may be right – it might not be necessary if they can guarantee their intuition is 100% infallible, 100% of the time. Hands? Anybody?

Data-driven organizations get beyond the “Two anecdotes make a trend” approach to business intelligence. But data must be acted on by people, and people are not entirely data-driven. There are emotions to contend with – usually fear – that might make a data message hard to assimilate.

Presenting data with emotional intelligence is as important as crunching it. Anticipate what your audience is afraid of. Then address it with your data.

Agile Humor – New Certifications

The brilliant Peter Saddington, a/k/a AgileScout, posted a wickedly funny April 1st announcement of a Certified Agile Blogger course. Yep, April Fool! Read it, it’s great fun.

Since I blog about Agile from the point of view of the business stakeholders, it got me thinking about other certifications we could use in the Agile community.

CERTIFIED WATERFALL COUNSELOR

This 2-day course will give you all the skills you need to wean the business off Waterfall into the new Agile reality. You’ll learn to recognize the stages of change resistance:

Denial – “We’ve never done it like this, not going to start now. Unless you’re going to make each sprint eighteen months long.”
Anger – “I wouldn’t scrum with you if you were the last PM on earth!”
Bargaining – “Okay, okay – I’ll meet with you to answer your requirements questions, just give me one more product cycle that carries a three-ring binder full of comprehensive and immovable up-front requirements.”
Depression – “You don’t really want my sign-off. Nobody values my opinion anymore, all anybody cares about is that stupid wiki now.”
Acceptance – “Right, so explain to me again how that task moves from ‘In Progress’ to ‘Done’.”

CERTIFIED AGILE SHERPA

Marketing is from Vegas, Dev is from Alderan. (Silicon Valley. I meant Silicon Valley). There’s a language barrier. The two teams dress differently, have different customs. Marketing needs an Agile Sherpa, a guide and emissary, to help them navigate this unfamiliar world.

Upon completion of the Certified Agile Sherpa course, you will be bilingual, fluent in both Geek and Hype.

You will be able to explain to the Marketing team why “Welcome changing requirements, even late in development.” carries as much fine print as “Facebook values your privacy”. And why code complete isn’t as flexible as their expense account.

You will be able to explain to the Dev team that “The sole success criterion will be the number of clicks generated.” carries as much fine print as “Drink responsibly”. And why there would be another success metric besides velocity.

Are there other certifications that could be useful? Drop me a line in the comments. this could be the start of a beautiful collaboration. With a little fine print…

A Marketer’s Guide to Agile Development – Fumbling In the End Zone

Some Agile Marketing projects will wither and die. Oh, they get finished – they just won’t be used. Why?

A SOLO RUN DOWN THE FIELD

Sometimes a developer or team unilaterally decides Marketing’s had enough turns, it’s their turn – they’ll build their own vision. Seriously, I’ve seen it happen. Maybe it really is a great idea and Marketing just won’t green-light it. Maybe the two teams aren’t getting along. Whatever. The point is that deliberately skipping collaboration can allow departmental myopia to take over. It works out occasionally, if there’s a serious UX wonk behind the keyboard. But more often, a tech-only result favors the technical accomplishment – the user CAN complete their task – but the process is so annoying that users want to kick holes in their monitors doing it. And if the style and nav are to the specs of someone’s vision of cool, unmoored from the brand’s, users can bail thinking they’re on the wrong site.

DELAY OF GAME

It’s finished – or rather THIS CLOSE to being finished. Except for that bug that keeps coming back after each build. Except for the two months it went on hiatus to accomplish the Exec Pet Project Du Jour first. Except the requirements changed (bigtime) during those two months it was put on ice. Except the priorities have shifted again and it’s postponed again. Greece will be solvent again by the time it finally gets released.

TOO MANY PLAYERS ON THE FIELD

You know what they say about opinions – everybody’s got one. You’re on the last stage before release. Suddenly the CMO fancies himself a copywriter. The Steering Committee can’t agree on the font. The legal team makes last-minute design suggestions. The data team is suddenly all about the user experience. And the ops team notices three critical steps are missing from the flow – a week after they already signed off on it. There’s only one thing they all agree on: “WE CAN’T LAUNCH IT LIKE THIS!”

CLIPPING

The CTO has issued a directive. Get it out this sprint. Deliver it already. Ship the damn thing. Schnell! Schnell! It will get delivered – even if the features that make it truly compelling got clipped out of the sprint scope to make the release. Those features are no longer iterations on the way to global launch – they’re enhancements in sprint 15. The pressure for delivery is over, so who knows when those will get prioritized? This brings up the definition of “done”, which I’ve covered in earlier posts.

It happened in waterfall. It still happens in Agile – but hopefully with less development time wasted on the clock.

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

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.

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

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.

A Marketer’s Guide to Agile Development – The Ten Commandments for Marketers

Agile is thy methodology – the way, the truth, the absolute shiznet to thy development team. Thou shalt not use any other methodology – at least not here.

Thou shalt not bitch about the lack of up-front requirements – neither shalt thou commit scope creep.

Keep holy the release day. It’s ain’t movin’. It especially ain’t movin’ for thee.

Honor thy development team. Seriously. Some morning Dunkins, a toy, a damn pizza wouldst not kill thee.

Thou shalt not kill the development schedule with late requirements.

Thou shalt test. And test some more. Thou art not a representative sample of thy user base. Truly I say unto you, thou art not.

Thou shalt provide feedback when needed rather than when convenient for thee, lest thine development team proceed without it.

Thou shalt not hire a contractor to circumvent thy development team. Remember thou art part of the same tribe.

Thou shalt remain in scrum for its duration and not bugger off once thy project was discussed eight minutes in.

Thou shalt not covet your colleague’s project’s prioritization on the sprint by seeking to bogart the development cycle for thyself.