Category Archives: A Marketer’s Guide to Agile Development

A Marketer’s Guide to Agile Development – When Your IT Department Pushes Back on Digital Tracking Tags

1. “Tracking tags will slow down our site.”

In my experience, tracking tags are often the first thing developers blame when sites load slowly. But even in the bad old days before asynchrony, tracking tags were rarely the real culprit. It’s even less likely now with tag management systems like Google Tag Manager and Tealium. So why does tagging get blamed instead of image formatting/sizing, java script minification, widgets, etc? Because IT is busy, and IT usually doesn’t own tagging. So, they kick the can to you. So, make sure the page tag is placed properly, prove through metrics that tag weight is negligible (it usually is), and kick the can back.

2. “We don’t have time to add tracking.”

IT departments in an agile development environment may classify tracking as an enhancement rather than a launch requirement. Remember, your IT buddies are graded on (a) coding and launching a digital asset on time, (b) adding enhancements and (c) making sure the asset continues to function well. Their bonuses do not depend on your ability to track. So take your favorite Finance Department buddy to lunch, sigh heavily, and opine about how much more efficient your budget could be if ONLY you could track right from launch. You’ve just gained political clout to move tracking from “nice-to-have” to “must-have”.

3. “Tracking tags can interfere with site functionality.”

Well, they could. But they won’t under your watch. Because you will make it your job to ensure tag library names are unique, and tracking is placed correctly on the page. Tags will be tested in the dev environment before going to production. Those are typically developer competencies, but your tags aren’t top-of-mind to your developer buddies. So help them help you. Once your developers reach a comfort level that your tags won’t break anything, the road ahead gets a lot smoother.

4. “It’s a waste of time to track all that stuff.”

Maybe so. That’s why you will have use cases – something like “If I knew “X”, I could do “Y”. For example:

“If I knew [which tools visitors from partner sites used], I could [optimize content to those visitors to increase engagement]”.

“If I knew [user article view sequence], I could [suggest ‘you-may-also-enjoy’ links for each article].”

Track what’s actionable now and in the future, and be prepared to justify each tag you add.

5. “Don’t tell me how to code.”

“Here’s what we’ve found works best” or “Here’s how other sites usually do it” can go a lot further than “Code it exactly the way we tell you.” I’ve found that patience, persistence and emotional intelligence can help Marketing and IT build a culture of measurement pretty quickly. At first, IT organizations may feel their autonomy is at risk when subtle code changes are needed to accommodate Marketing’s tracking. That happens. I knew we’d gotten past that hurdle the day a developer called me and said “Hey there’s no tag plan on this new functionality they just gave me to code – think we should we tag it?”

A Marketer’s Guide to Agile Development – Insource or Outsource?

A few years ago at a National Center for Database Marketing conference, a panelist said that the decision whether or not a marketing organization should build their database management functionality in-house often rests on the relationship between two people – the marketing chief and the head of technology. How does that dynamic play out in your organization?

Is their relationship collaborative and friendly? Then building and maintaining a marketing database in-house can work well. But if the two executives regularly engage in silo defense and turf-grabbing, then outsourcing may be faster, less stressful on the business, and offer you more autonomy.

Naturally, politics shouldn’t be a key factor in the decision. But it usually is because politics drives delay – and delay drives opportunity costs. You can successfully pull an internally-managed database solution into the station even if your CMO and CTO are ‘frenemies’. But it will take longer while they argue over who’s driving the bus.

How much incremental revenue, cost savings, or efficiency do you lose in the meantime? You need to figure it out, then figure it into your decision process.

I was once refused administrative rights to a database, due to a business rule that only the I.T. team members were qualified DBA’s. I challenged the rule, citing my assistant’s graduate degree in Computer Science and the fifteen years of database experience between
us. We finally did get our rights because we had the proper credentials, not because we were entitled to autonomy. If you don’t possess real qualifications within your team or have immediate plans to hire people with them, outsourcing is probably best.

You’ve got to put yourself in your tech manager’s shoes. A poorly written query against a database on a shared server could grind her production system to a halt. When the field offices suddenly can’t enter any new contracts, she’s the one who has to stand in front of the Sales VP’s desk explaining what happened, not the hapless marketing guy who set the whole thing in motion.

So give her a comfort level by talking like a DBA instead of a marketer. Which statement will be more effective in dispelling her fear?

a) “We should be able to control our own database – we know what we’re doing – you won’t be sorry.”

b) “I promise, I’ll never perform a six-table outer left join without a where clause or import a two million row table without proper indexing.”

If you know what (b) means, she will realize you’re aware of the type of bad acting that brings down servers and she has your word that it won’t happen on your watch. If you don’t know what it means, you should seriously consider outsourcing.

Consider safety and continuity. The server corrupts, the on-call junior tech loads the backup, which corrupts too, and keeps loading each previous backup until they’re all damaged. Or you discover that the backup failed every night for the last three weeks, but the failure notification went to the phone of an employee laid off last June. It happens. Tight procedures and consistent oversight help mitigate it, but the risk is inherent to any in-sourced solution.

Many consider outsourcing safer. But consider the October 2009 T-Mobile Sidekick debacle – a catastrophic database failure in which some vital client data was irretrievably lost. And the keeper of the data wasn’t some undercapitalized DB startup – it was Microsoft. They’ve since recovered a portion of the lost data, but confidence in outsourcing and cloud computing in particular took a definite hit.

Outsourcing data failures are fairly rare, and you at least have the option to sue. But either outsourced or in-house failure can cripple your operation and lose customers. You need to honestly assess how well your in-house staff can execute on database maintenance best practices, compared to the vendor’s ability to do the same, and use those risk factors in your decision.

PLAN B: TRAINING WHEELS AND TRANSPARENCY

If you definitely want to take your database operations in-house, and your tech team balks, you can offer to launch with “training wheel” rights and gradually earn your way to autonomy. Offer to:

 Accept read-only and row append rights to start.

 Submit all query coding to an IT manager for quality assurance prior to a live run.

 Schedule meetings to review server load metrics, table change requirements, and new data loads you need them to support.

 Call for advance clearance to append more than a 100K records into the database.

Give it six weeks and ask again. If you’ve been diligent, you’ll likely be granted full rights to manage your database. The tech department doesn’t really want to review your code, add more meetings to their schedules, or interrupt their day to approve your appends. They just want a comfort level that:

a) You acknowledge you are playing in their sandbox.

b) You won’t break anything.

c) You will be a good steward of the data.

No matter the relationship between your CMO and CTO, you can better develop your own relationship with IT by seeing things through their eyes.

A Marketer’s Guide To Agile Development – Survey Says…

The customer base shrank, revenues fell, and prospects told sales reps repeatedly that the product was losing relevance. Not true, said the executives. It was only a misperception, they claimed – industry-sponsored studies indicated product usage was steady, even increasing a little in some areas! But the studies were wrong. The decline was real.

Why such a huge disconnect between the survey results and market reality? Simple. For the most part, they surveyed consumers with landlines, publicly listed phone numbers, who were at home during weekdays, and had the time and willingness to take a long survey. This method has been used for decades, and could be reliably extrapolated over the general population. But the world has changed. The increasingly older consumers willing to answer the phone in the example above still comprise an important constituency – but they are not and should not be construed as the average consumer. This traditional survey bias was also a factor in the 2012 Presidential election polling. Skewed survey results masked problems with candidates’ outreach operations and produced nasty surprises on election night.

In the case above, older consumers were still using the product at the same rate. But younger consumers weren’t. Younger consumers are also less likely to have landlines, have publicly listed phone numbers, spend weekdays at home, and agree to take a long survey. That’s why the surveys (which were otherwise conducted with scientifically accepted methodology) let the executives keep believing the decline was temporary. They told their sales reps to defend the product by explaining to prospects that their perception about product relevance was wrong – they had the surveys to prove it. That did not turn out well.

When the real world indicators don’t look anything like the marketing research, defending the research is usually not a winning strategy. Conduct the research so it WILL unearth the worrying trends and inconvenient truths about your products. At least you can develop a roadmap to deal with them before your competitors do.

A Marketer’s Guide to Agile a Development – Who Said It:

When it comes to meetings, meanings of common phrases differ depending who’s talking;

“So that’s the problem in a nutshell. Thoughts?”

– “I’d like to hear your opinion on how I might approach the solution.”

– “I want you to solve this for me, but I don’t want to ask you outright.”

– “I got nothing. Any ideas? Pleeeeze?”

– “Tag – You’re It!”

“Let’s circle back on this later.”

– “There are more pressing priorities, so we’ll revisit this topic at another time.”

– “We aren’t making any progress here – and I need a Red a Bull really bad right now.”

– “You’re clearly delusional. We’ll talk about this once you re-enter earth’s atmosphere.”

– “If you don’t stop talking, I’m going to gouge my eyes out with this pen.”

“That’s a great question.”

– “Good question.”

– “Stupid question.”

– “Phew – I know the answer to this one.”

– “Crap – I got nothing.”

A Marketer’s Guide to Agile Development – You Can’t Make Me

I fly US Airways a lot. Not road-warrior status, but several thousand miles per month.

In the many years I’ve flown US Airways, my assigned boarding zone has varied. You know, sometimes you win (Zone 1 or 2), sometimes you lose (Zone 4 or 5). But something’s changed – in the last few months, I’ve been consistently assigned Zone 4 or 5 for boarding. Understand, it’s not just drawing the short straw occasionally – it’s become a running joke among my travel colleagues – “Bye Cathy, see you in [insert city here]”.

Lately I’ve eschewed wheeled luggage for soft duffel bags that fit under the seat. As any traveler knows, Zone 4 or 5 equals no overhead bin space. As in, “sorry, we’re gonna have to go ahead and gate-check that bag for ya, ma’am.”

I am loyal to the airline. I’m frequently assigned TSA Pre-Check status. My ticket fares are almost never in the aggregator bargain-basement tier. They have every reason to like me. So why is this happening?

I have a theory – I’ve never signed up for their credit card.

I suspect my consumer and behavioral profile fits US Airways’ propensity model of customers who should. One of the perks of a US Airways credit card holders is – wait for it – Zone 2 boarding for all flights. My hypothesis is that the inconvenient boarding zone assignments are being used as a prod. They’re to nudge me into signing up for their credit card so I can start carrying a wheeled bag again. Too Machiavellian, you say? Perhaps. But that’s my theory.

I’m so onto you, US Airways. You are the masters of segmentation. But I don’t care how many times you assign me to Boarding Zone Siberia. You can’t make me get your credit card. I can hold out. Two words. Travel knits.

Update 4/18/14: The siege is over – got Zone 2!!

Update 6/18/14: No, it’s not over – oh, alright, I’m getting the damn card. You win.

Agile Humor – Why Did The Chicken Cross The Road? – Ad Agency Edition

Data Analytics

Cell 1 [Side of the Road A] Attrition = -1
Cell 2 [Side of the Road B] Acquisition = +1
Net Gain = 0
Key Drivers; Insufficient Sample Size, More Data Needed

Creative

She didn’t. Chicken concept didn’t fly – focus group liked the puppy.

Digital

The Side Of The Road A landing page needs to be retooled to improve engagement.

Client Services

No puppy. The client chose the chicken concept. Actually they asked if it could be a rooster.

Client Services

Can the rooster be black? With red tail feathers?

Client Services

No roosters. We need to bring back the chicken. Their CMO was once bitten by a rooster.

Accounting

Tell the chicken to code the time spent road crossing to Account CHIXCROSS438.

Client Services

The client’s just signed on a new CMO. She liked the puppy.

A Marketer’s Guide to Agile Development – A Tale of Two Christmas List Apps

Last year I downloaded an app to help me keep track of my Christmas shopping. I paid the small fee for extra functionality and no ads. It did all the things it said it would do. But it annoyed the crap out of me every day I used it.

This year I downloaded a different app to accomplish the same task. The design is clunky and uses gaudy colors. It’s done up in some kitschy font – looks like Comic Sans on a bender. It also does all the things it said it would do. And I like it much better.

Why? Both apps track budgets, recipients, gifts and costs. But here’s the difference. This year’s app lets me think like a Christmas shopper, while last year’s app forced me to think like a DBA.

Let’s say I bought my nephew Alex a Tom Brady jersey for $48.

Last Year’s App:

Step 1: Click to the Recipient area
Step 2: Enter my nephew Alex’s name.
Step 3: Click “Save”.
Step 4: Click to the Gift area.
Step 5: Enter “Tom Brady Jersey” in the Gift field and $48 in the Price field.
Step 6: Click “Save”.
Step 7: Click back to the Recipient area
Step 8: Find Alex in the Name drop-down.
Step 9: Find “Tom Brady Jersey” in the Gift drop-down.
Step 10: Click “Save”.

I had to repeat these steps for every recipient, and almost every gift. It did have a feature where I could choose multiple recipients for the same gift. Useful if I was giving all my nephews the same Patriots jersey – which I wasn’t. So using it got pretty old, pretty quick.

This Year’s App:

Step 1: Click to the New List area.
Step 2: Enter Alex’s name.
Step 3: Enter “Tom Brady Jersey” in the Gift field.
Step 4: Enter $48 in the Price field.
Step 5: Click “Save”.

And we’re done. It probably creates the same tables as the other app. But it lets me enter the data using a shopper’s thought process instead of a programmer’s. So it’s a keeper. I guess now I have to pay $1.99 so I don’t get an ad every 30 seconds begging me to play Candy Crush.

A Marketer’s Guide to Agile Development – UX: Don’t Try This At Home

Calling one segment “A” and the other “B” doesn’t make it an A/B test.

You are not a representative sample. You have skin in the game and you know too much.

Your typical user is not a programmer. Don’t force him or her to think like one.

Designers rule at Apple. Programmers rule at Microsoft. One created the iPod. The other created the Zune. UX matters.

If you can’t find the relevant copy on the site, it doesn’t matter how cool the font is.

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.

Agile Humor – Definitions

Kanbanter – Small talk exchanged while you and a fellow developer view progress on the board.

Custermation – When a project’s resources estimate is about as accurate as Custer’s prior to the Battle of Little Big Horn.

Reverse Time Lapse – When seven hours elapse while finishing a piece of code with a one-hour estimate.

Pessimestimation – When you start padding six extra hours onto every hour of estimated work.

Doubtsourcing – When stakeholders start contracting out work because all of the internal team’s time estimates appear six or seven times too high.