Structured Creativity Month

Posted in Aliens, Dark Side, Force Training on January 29, 2010 by Jeff Foley

Recently I’ve spent a lot of my time on the content creation side of the marketing world.   This is sometimes the hardest thing for an engineering mind to handle, because creativity in programming or design is not the same as creativity for explaining something to the masses.  And 9 times out of 10, that’s what you’re doing when you’re being creative in marketing — trying to find a way to communicate something so that people will understand it and retain it.

Over the next month I’ll be talking specifics about what I call “structured creativity.”  It’s some techniques I prefer to use for repurposing the no-nonsense, bits and bytes engineering mental approach in a way that can produce results on the creative side of things.

  • How to use a creative brief, with some practical examples and on-your-own exercises
  • How to talk with aliens, also known as the creative people.  They don’t speak your engineering language at all
  • How to collaborate and give feedback on subjective topics that don’t necessarily have a right answer
  • How to write a script, whether for a live product demo, an animated flash or video, or any not-in-person presentation, like a webinar.
  • Tips and tricks for getting your brain into creative gear when it wants to be in analytical “do” mode

By the end of this series of posts, whether you’re on the engineering side or the marketing side, you’ll be better equipped to tap into your creative side without losing the engineering mind that probably got you where you are in the first place.

But first… I may need another trip to Starbucks so I can sit down with my laptop and churn out another script, without being connected to the Internet, without alt-tabbing to email, without people walking into my office or calling…

Five Ways to Keep It Simple

Posted in Dark Path, Dark Side, Light Side on January 11, 2010 by Jeff Foley

Most engineering minds love to delve into the details.  They want specs.  They want operating parameters.  They want exceptions.  They want to know how you handle unusual bizarre situations.  After all, that’s what coding is about.  That’s what industrial design is about. That’s what Murphy’s Law is really about.  How do we stop someone from screwing everything up? So you overspecify.  You catch errors. You do QA testing to find the loopholes.  You try to anticipate every odd combination of circumstances that might cause a problem.

In marketing, you need to do the opposite.  A positioning statement, a key message, an expression of a benefit — all of those are examples that require you to simplify, simplify, simplify.  To get into specifics is to go down a rat hole.  To discuss the details is possibly to waste 50 minutes of a 60 minute pitch meeting.  All to cover something that only 2 of 10 people in the room actually care about.  You waste people’s time.

“But wait,” you say.  ”The customer should know about this.  And this. What about this?”  This is the kind of thinking that gets you option dialog bloat in software.  Tabs upon tabs of different categories of what-if’s and gotcha’s, all of them important when you need to make that tiny yet meaningful adjustment to the software’s behavior so that it does what you really want it to do.  Arguably that sort of thing is useful for an option dialog.  It has no place in most marketing collateral and sales tools.  You can’t be explicit and cover all possibilities when you’re trying to ram home a marketing message.

In many ways, marketing is about not wasting people’s time.

You often don’t have time for that when you’re in marketing, because you only have so much time to communicate your message to your prospective customer.  Consider:

  • In a lead generation situation — like an email blast or webinar — you need to get to the point quickly because you’re interrupting someone and may only have a few moments of a person’s attention to get your point across and pique his or her interest.
  • In an inbound marketing situation — like a blog or web copy — you need to express yourself persuasively but succinctly, so that a person reads what you have to say and doesn’t glaze after the first few lines, and you’ll be intelligible when you come up on search engine excerpts.
  • In a B2B sales situation — like an opening presentation to an interested prospect — you need to get the basics out about your message as quick as possible so that you can establish a “that’s nice, but what I *really* need” conversation with your potential customer and not dwell on the minutiae of what your product can do.
  • In a B2C sales situation — like box copy on packaging — you may have to meet an economy of space as well as avoid the same glazing that someone reading your website might do after the words start swimming before their eyes… “blah blah blah robust blah blah unique blah blah easy to use blah blah.”

How do you simplify?  Here’s five suggestions for ways to take a step back and simplify whatever you’re trying to communicate.

  1. Un-jargon. Are you needlessly inventing new terminology or acronyms? You’re going to have to explain each one.  And if you’re spending time explaining terms, you’re not spending that time answering “so what” for the customer.   Save that level of detail for a person who’s holding you up for comparison to competitors and is really investigating what you have to offer. And even then, simplify, simplify, simplify.
  2. Drop the word count. Are you using too many words to say something?  Get rid of the wishy washy.  You’re not “trying to solve”, you’re “solving.”  You’re not providing “one of the many ways to,” you’re providing “a way to.”    You may be surprised how many “this is exactly the kind of thing that” phrases collapse to simply “this is.”  And drop the passive voice.  It’s just another grammatical pitfall that unnecessarily lengthens your writing.
  3. Ditch the marketing gobbledygook.  Why do people think all marketing communications must have that formal, stilted style of doubletalk?  Stop being pleased to announce that you’re focused on a unique, world class, robust solution.  So what?  Or better yet:  NO.  ONE.  CARES.
  4. Stop talking about everything. But everything is so important, right?  You need to cover all the bases!  No, you don’t.  Stop it. Pick at most 3 topics to convey.  Find commonalities between topics and combine them.  Better yet, find some overreaching theme and just focus on that.
  5. Adopt your customer’s point of view. Does your customer really care about the fact that you have 5 different variations of your core engine?  Does your customer need to know that you have a piece of connector software that you give away free with your solution?

Look at Seth Godin’s blog.  It is amazing how well he can communicate a deep thought with only a few sentences.  He keeps his lessons clear, simple, and to the point.

Here’s a more relevant example to high-tech product marketing. Today, a colleague and I were talking about an introductory slide deck for one of our products.  The fourth slide in was titled “Types of Outbound Notifications” and proceeded to discuss four different flavors of notifications under two separate categories.  It started introducing all these extra terms like “power dialing” vs. “preview dialing” or “proactive notifications” vs. “precision notifications,”  all valid terms that were associated with various product features and had been used at least once by our sales force.  In each case, the two options typically differed by only one or two features.  So why distinguish between them?  At this stage, you’re happy if the prospect remembers the name of your company by the time you leave the room after a presentation.  If you were in a technical meeting, dealing directly with engineers who had already finished a deep dive analysis of your product, then I could see drawing some of these finer distinctions.  At the business level presentation — the level at which most of your marketing communications should probably be aimed — you’re trying to get a talking point across (“we can offer this either on-premise or as a service”) without blinding your prospect with options (“We have four add-on modules, each with a unique pricing plan, and a new separate name for you to remember.”)

So, to simplify: take a look back at whatever you’re trying to say. Focus on your key message and cut away the cruft that stops your customer from understanding it. Put that engineering mind to rest: stop trying to be factually complete and exhaustive.  Instead, make sure you’re not wasting anyone’s time.

Agile as a Marketing tool?

Posted in Dark Side on December 30, 2009 by Jeff Foley

I’ve often told friends that most marketing tasks are pretty easy because they aren’t that different from engineering tasks.  Hell, they’re not that different from knowing how to get things done, no matter what the discipline.  Most of it is application of common sense, coming up with a plan, communicating clearly, managing project with lots of moving parts, keeping track of deliverables from individuals responsible for subprojects, testing hypotheses and making improvements… am I building a marketing campaign or coding a new product feature?  The Force is the Force, whether you’re on the Light Side or the Dark Side, some things don’t change.

Now the marriage of marketing and engineering may be getting even more formal.  A good friend sent me this link from Marketbright pointing out that marketing really has no methodology to speak of.  Sales has their selling cycles and methodologies that move prospects through a pipeline from lead to sale.  Engineering has their agile and their waterfall development techniques to turn customer requirements into released product features.  Marketing has… uh… the 4P’s?  Generally it’s whatever worked last time, with modifications to see if you can make it better.  It’s frontier land.  It’s constantly changing.  You succeed by applying engineering principles for problem solving and figuring it out.  RTFM?  There’s no M that you can F-ing R!

So what if you could apply the Agile manifesto development processes – 6 week sprints with daily sprint meetings, welcoming changing requirements and mid-course corrections, closely tracking commitments and metrics, working lockstep with customers, finding efficiencies — to the marketing team?  Would it work?  How very, very interesting.

I can see objections and problems immediately, but the objections I come up with seem like they already exist in the development world and they’ve figured it out, right?  Things like the amount of external dependencies usually involved in getting projects done.  I think about projects like “create a flash video that showcases our product line.”  Most external agencies couldn’t easily handle an agile marketing setup. They bid for the work, if we’re lucky they have a project manager and a traffic cop, they set up review cycles, and x weeks later we have the deliverable. For them, mid-course corrections = extra fees, scope creep, change orders, etc.  However, if you’re talking internal “agencies” doing the work instead of external vendors, I could see the iterative process working.  Or if you had an agency on retainer (you guarantee them $X/month worth of spending with them, they guarantee resources set aside to help you.)  Hmmm.  It could work.

Likewise, it’s hard to imagine a sales time wanting to spend significant time stopping to help out a marketing team.  Sales teams want marketing to help them, but they don’t get paid to help marketing figure out what sales tools to create… they get paid to sell, sell, sell.  And there’s a fundamental distrust between the bounty hunters of sales and the dark jedi of marketing.  As Geoffrey James at The Sales Machine loves to say, “The operative behavior for marketing groups is to find a parade and get out in front of it.” Often sales departments don’t think anything marketing does results in revenue, they claim marketing is just trying to take credit for their hard work.  However, if sales teams feel marketing doesn’t communicate with sales enough and doesn’t really know what’s going on… a regular agile-style meeting with them might help with.  If sales bought into it, then you’ve effectively got customer buy-in and can get the feedback loop you need to remain nimble via the agile process.

I want this to work.   I’ll definitely be following the Marketbright experiment — and any others I hear about — with great interest.

Getting Your MBA in Naming

Posted in Dark Path, Dark Side, Force Training, Light Side on December 5, 2009 by Jeff Foley

Remember the suggestions I gave for coming up with that perfect name?  If not, read my previous post again.

After rereading my previous post, I realized that I needed to re-code it to be more efficient.  It wasn’t nearly clear enough about the process.  The good thing about blogs is you can go back and change stuff.

The old:

So how does one come up with a name?  Without succumbing to some level of marketing cutesy-ness that makes engineers gag?

Take a step back and figure out what you’re trying to convey with the name.  Since a name is essentially a mini-positioning statement, you should avoid the temptation to simply come up with merely a descriptive name.  Boring!  You may also try to avoid conveying something.  For instance, if you want something to sound easy to use, you may not want a very complicated-sounding name.   If possible, write down in prose what your intended reaction is when someone hears this eventual name.

Got that?  Great.  Now start writing down as many words as you can that are related to what you’re trying to convey.  Pop up a thesaurus and go nuts.  One word may inspire another; give yourself permission to go off on tangents.   Once you’ve got a good list of words, you can start picking through them, combining them in whole or in part, discarding ones that give the wrong connotation, and otherwise manipulating them until you have a short list of favorites.  Try to come up with at least 3-5 choices.

It’s pretty clear, right?  But it’s not memorable.  This comes up in bad presentations all the time.  Never use a wall of text when bullet points will do.  If you’re ever giving

Now here’s what my new version looks like:

So how does one come up with a name?  Without succumbing to some level of marketing cutesy-ness that makes engineers gag?  Let me help you get your “MBA” in naming:

1) Message.  Figure out what you want to convey.
2) Brainstorm.  Write down all the related words you can think of.
3) Assemble.  Pick through and select different favorite words and combinations until you have a short list of 3-5 you like.

First, the Message. Take a step back and figure out what you’re trying to convey with the name.  Since a name is essentially a mini-positioning statement, you should avoid the temptation to simply come up with merely a descriptive name.  Boring!  You may also try to avoidconveying something.  For instance, if you want something to sound easy to use, you may not want a very complicated-sounding name.   If possible, write down in prose what your intended reaction is when someone hears this eventual name.

Got that?  Great.  Now the second step: Brainstorm. Start writing down as many words as you can that are related to what you’re trying to convey.  Pop up a thesaurus and go nuts.  One word may inspire another; give yourself permission to go off on tangents.

Once you’ve got a good list of words, you can Assemble. Start picking through them, combining them in whole or in part, discarding ones that give the wrong connotation, and otherwise manipulating them until you have a short list of favorites.  Try to come up with at least 3-5 choices.

Two huge changes.  First of all, it’s the old “tell ‘em what you’re gonna tell ‘em, then tell ‘em, then tell ‘em what you told ‘em” idea.  That’s been working since your 10th grade English teacher forced you to learn how to write five paragraph essays with an introduction and thesis statement, three key points, and a conclusion restating the thesis.  The second is distilling what I’m trying to say into three key bullets — with bonus mnemonic acronym, no less! — and then reinforcing each point afterwards.

I made similar subtle but meaningful changes to the follow up post — just look for the bolded words.  It really does make a difference!

Practicing How to Come Up with the Perfect Name

Posted in Dark Path, Dark Side, Force Training, Light Side on November 19, 2009 by Jeff Foley

Did you do your homework?  In my previous post, I suggested you try and answer the question of how to name a given software feature using the MBA method — Message, Brainstorm, Assemble.  You needed to figure out for yourself what Message you’re trying to communicate about the suggested feature, then Brainstorm a list of words to meet that goal, and finally Assemble your words in combinations until you pick 3-5 potential names for the feature.

Really, if you’re interested in learning how to come up with good names — and if you’re in the hi-tech world, you run into the name game for not only made-up marketing terms, but also technical features, products, working groups, your next start-up company — I strongly encourage you to try out this and other exercises first before continuing.

Go on, I’ll still be here.

<cue The Girl From Ipanema music>

Back?  Excellent.  Let’s compare notes.

First let’s talk about the key Message to convey to the customer.  It’s pretty straightforward.  In the unlikely event that the system is not available when a person calls, customers have an option to configure a wav file to play a prompt and transfer the caller to a phone number.  The engineering team specifically wanted to emphasize the flexibility this feature gave customers, and they wanted to avoid the word “failure” if possible.

Then, my Brainstorm.  My possible words list went like this: baseline, backup, alternative, catchall, unavailable, emergency, replacement, switch, transfer, configuration, response, alternate, failover.

That seemed like enough, so I started going through the list to Assemble options that could replace “Default Call Action.”  It helps to evaluate words individually first.  I like the word configuration in there to convey the ability of the customer to specify the response, something that default wasn’t succeeding in doing.  I liked response too instead of action because it was more directed and better captured the concept of playing the prompt.  I decided that failover wasn’t as a terrible word to use as fail or failure in this case because I thought it accurately described what’s happening.  Baseline and backup felt good too, although backup implies we’re making a copy somewhere to restore if there’s trouble, and that’s not the case.  Catchall sounded like duct tape was involved.  Emergency and unavailable both sounded too alarmist.  Alternate and alternative sounded more like lifestyles and got tangled on my tongue when I combined them with other words.

It also occurred to me, after making the word list, that I was assuming that “call” was the main noun here, since we were dealing with calls.  But if there was a problem, it was because the whole system was down… so I revisited my list and considered “system” as an alternative to “call.”  Nothing says you can’t go back.

Given that, I started to mentally Assemble a few permutations of these terms for things that sounded right when I said them out loud, and didn’t have a bad acronym (System Unavailable Configuration would be a SUCky feature name.)  The “say it loud” and “acronym” tests are two other good tricks to consider.  Here were the five name suggestions I responded with:

  • Baseline Call Action
  • Call Failover Configuration
  • Call Backup Configuration
  • System Unavailable Response
  • System Unavailable Response Configuration

I checked back a few months later, and they had decided on Call Failover Configuration — and were even already abbreviating it as “CFC.”  Yes!  Is this validation of the methodology?  Perhaps.  It’s just nice to add value on the engineering side, since by trading in my Jedi robe for a black helmeted mask, my coding days are long behind me.

One extra useful sanity check when coming up with any name is to do a quick Google search.  This, plus a visit to the online patent & trademark office, is what lawyers do anyways when they do a first pass to see if there’s a risk of a trademark violation.  You may have come up with the perfect name… but found out that three other people are already using it.  Here, I see that the term is not trademarked (not a surprise, given that its generic descriptive nature would make that very difficult) and that the term “failover configuration” is used in Cisco’s product and by several other SIP-related software solutions.  If we were naming a product, this might be bad, as it would lead to market confusion.  For our purposes, this is a good thing; it means we’re in line with the industry.  We’re not trying to differentiate ourselves here, we’re trying to provide clarity and parity with competitive solutions.

I’ll walk through one more good example of the naming process in my next post, before we continue on with the broader topic of structured creativity… especially as it relates to the aliens known as creative geniuses.