Agile Marketing: The Movie

I can't believe I started by saying "OK, people."  Talk about your crappy opener.  But with six minutes and thirty-eight seconds remaining, I had to press on.  And plus Alexis had just brought down the house.

Let me back up.  In April I had inadvertently coined the term "Agile Marketing" in an interview.  It means applying certain principles of agile development to the world of marketing and advertising, and it's a nice metaphor for how we approach marketing at Smart Bear and something I'll be writing about more in future.

A few months later I was selected to do a pecha kucha at the Business of Software conference (run by Joel Spolsky & Neil Davidson).  A "pecha kucha" is a rigidly-timed presentation with twenty slides, twenty seconds per slide.  It's a fun format that encourages brevity, sparse slides, and focus -- attributes you've wished upon many presentations.  So now you can see the fun: business and geekery in a single six-minute-forty-second package!

The day of the conference I learned I was presenting second, behind Alexis Ohanian, founder of Reddit.  And his presentation was really great.  Not great in the sense that I was inspired, or learned something, or came away with a new idea; it had none of that, it was satirical.  But it was hilarious.  This was a bad thing.

Bad?  Oh I forgot to tell you.  See, this was a competition.  The conference attendees would vote for their favorite pecha kucha presentation.  Now I know, life isn't a competition; my value as a person on planet Earth isn't established by whether people vote for some presentation at some conference.

Except that, yeah, it kinda is.

So before I started my talk I tried to reset the mood with an old improv comedy crowd warm-up routine where you get everyone all excited and clapping and then make a dramatic sweeping motion to silence the house immediately.  It's a weird effect because you don't utter a word or explain what you expect them to do beforehand; the weird part is that it works every time.

So here it is.  (And please forgive that "OK people."  Sheesh!)

P.S. If you like talking about the stuff in the video, run over to the Business of Software networking and forums website and get involved.  This isn't just another pile of threaded conversations; it's real software entrepreneurs talking shop.

P.P.S. If you're wondering about the panda peeking over the PIP at time index 2:40, here's your answer.  And poor Eric I referenced at 3:57 is Eric Sink.

P.P.P.S.  Alexis won.

The leading provider of meaningless marketing solutions

Why do so many marketing departments strive for ambiguity and meaninglessness?

Witness, for example, this gem of a company description.  As Dave Barry would say, I'm not making this up:

Omniture, Inc. is a leading provider of online business optimization software, enabling customers to manage and enhance online, offline and multi-channel business initiatives. 

Huh?  Turns out they do web analytics.  Oh.  They could have just said so and spent the rest of their words telling you how they're different from other web analytics companies.  

What's the purpose of this language?  Does the phrase "a leading provider of" mean anything to you?  When you read it, do you whisper under your breath:

Awesome, I found the leader!  They lead the other providers around like cattle.  Well, they are a leading provider, not the leading provider, but still, one of the leaders!  I'm impressed.

Nah.  At best you gloss over it -- an overused phrase, devoid of meaning.  At worst you lose interest and click the "Back" button.

Perhaps the worst offender is the word "Solution."  What is a "solution," and how does it differ from, say, a product?  The main menu of many web sites makes me choose between "Products" and "Solutions."  How oh how do I choose?

My favorite example is AT Systems.  Their proud motto:

Now that you know the company name and their motto, here comes the question: What do they do?  After you guess, have a laugh; go here for the answer.

So back to the question: Why do marketing departments churn out meaningless phrases?

Possible Reason #1: Fear.  Generic, widely-used phrases don't offend.  They avoid lawsuits; it's hard to sue over meaningless words.  This excuse might work at Big Company Inc, but in a startup you can't afford to be bland and wishy-washy.

Possible Reason #2: Laziness.  Saying "A leading provider of business solutions" is a lot easier than taking the time and effort to nail your message.  It's hard!  You have to know your customer, boil your company down to its essentials, and be succinct and evocative.  It's easier not to.

Possible Reason #3: Incompetence.  What if you don't actually know what sets your product apart?  What if you can't articulate the niche your company owns?  What if you can't describe your perfect customer?  Then you have to resort to generic phrases.

None of these excuses are valid for small companies.  If you can't articulate your product in a few, choice, specific, words, your potential customers won't get it either.  You have to do the work yourself because you don't have TV ads and 300 sales reps to pick up the slack.

I'll leave you with a tragic example of what not to do.  See if you can guess what this company does:

webMethods (Nasdaq: WEBM) provides business integration software to integrate, assemble and optimize available IT assets to drive business process productivity. webMethods delivers an innovative, enterprise-class business integration platform that incorporates proven integration technology with next generation capabilities into one interoperable set of tools that delivers a unique combination of efficiency, agility and control. webMethods combines industry leadership with a zealous commitment to customers to deliver tangible business value.

Take a scalpal to your marketing content.  Make every word count.

Five ways to listen to customers instead of goin' fishin'

Lots of small business bloggers tell you to listen to the customer and build accordingly. But some people take it too far.

I recently had an experience with just such a company. They had finished their product demo and I was wrapping with a few standard questions.

Me: What's on your roadmap?
CTO: We're going to listen to what you need.

Notice how it evades the question, like a politician. He might as well have said, "The future is whatever you think it should be." Perhaps he's trying to demonstrate receptiveness to feature requests, but it's a non-answer.

Follow-up questions failed to uncover a roadmap. Maybe because they don't have enough customers to know where to go? The next snippet provides more evidence for this theory:

Me: Do you have any questions for us?
CTO: Yes. What is your biggest business problem that you would like someone to solve?

Fishing for ideas? Are you asking me to define your next product for you?

This isn't "listening to customers," this is a rudderless ship. Having clear goals and confidence is compatible with customer-guided development. What you should be doing is active listening:

1. When a suggestion appears, notice and write it down. Restate it in your own words and repeat it back to ensure you understood correctly.


2. Dig into feature requests until you find the root pain point. This means back-and-forth communication so do this on the phone or in person, not email. Often there are ten ways to address a problem and you have other customers and a product architecture to consider.


3. Ask them to order their suggestions by importance. Often a list of twenty suggestions yields only two deal-breakers. No priority levels are allowed, just an ordering; otherwise you end up with seven "Priority 1" line items.


4. If you can't (or won't!) implement something, admit it. Explain why so the customer understands you're being pragmatic and forthright, not dismissive.


5. Collect feedback proactively. Most people won't send an email to support with a feature request; they've been conditioned by most companies that such things go unnoticed. One way we've started doing this recently (with much success) is through a Uservoice page.

Notice in all cases you're simultaneously engaging the customer and honing the suggestions. Engaging means the customer feels like you're genuinely listening and giving thoughtful consideration. Honing means you'll leave with concrete things to consider.

Even admitting something is impossible is constructive because then when you do accept a suggestion they know you mean to implement it. You're displaying honesty and setting up reasonable expectations. People know all twenty of their ideas can't be done; they'll appreciate honest rejection.

Companies that listen are both rare and beloved. Listen, don't fish.

If you have more ideas for active listening or dealing with feature requests, please leave a comment for others to enjoy!

Love the messenger

I'd had Korean food before, but as this was my first trip to Korea House I wanted something different, something authentic, maybe even adventurous. Friday lunch at Smart Bear is usually interesting.

PJ recommended the bibimbap, a bowl of rice covered in Korean namul with beef and an egg. Perfect, but when our waiter got around to Hannah -- herself Korean -- she ordered the dolsot bibimbap. Ooo, it's a sign! So when it was my turn I asked the waiter the obvious question: "What's the difference between bibimbap and dolsot bibimbap?"

His answer: "Dolsot bibimbap better."

That's it! Better. Well of course I ordered the dolsot, and it was fantastic. Turns out "dolsot" means "stone pot." The dish is served in a hot stone or ceramic pot hot enough to sizzle and cook anything that touches the sides. The rice gets crispy, the egg cooks, and the veggies and meat stay extra hot.

At this point, my long-time readers will expect me to make some point about how marketing messages need to be more specific than "it's better," how differentiation always trumps ambiguity, and how every phrase should be meaningful. But actually, his response was perfect.

It was perfect because it wasn't in an ad, wasn't in a datasheet, wasn't part of a 30-second elevator pitch mechanically regurgitated on a tradeshow floor. It was from an old Korean guy who works his ass off at Korea House, possibly seven days a week, probably related to the owner. He barely knows enough English to parse my question -- certainly not enough to articulate the answer -- but he did his best to push me to the right choice, the one that was $1 more and 2x better.

It's the messenger, not the message, that makes the experience wonderful.

So yes, on websites you do need to be specific because websites aren't relationships; they're attention-getters and information-distributers. But as soon as the human relationship begins -- whether by sales pitch or tech support or tradeshow booth -- the most important thing is to be genuine in your passion, knowledge, and desire to make your customers successful.

2000 feature requests: Our foray into Uservoice

Question: What do you do with two thousand feature requests sitting in an issue-tracking system?

Answer: Nothing.

We have so many requests because we make it clear that we want to hear from our customers.  And they talk to us... a lot!  It's great that so many people have submitted so many ideas, but we're drowning.

How do you prioritize 2000 items?  How do you know which ones were really important to the requestor and which were just a passing fancy?  How do you track which ones are related or are duplicates or have a common solution?  How do you have separate discussions internally and with customers to dig up the root problems?

You don't.

And anyway you only have time to implement a tiny fraction of the requests, so almost all the time you spend getting the list ship-shape is wasted on features you'll never implement.

You could ignore feature requests entirely on the theory that the important stuff is requested often enough that priority makes itself apparent.  This works if your product is extremely simple, and if you've decided it won't have many features.  If you can get away with such a product, by all means do!  But not all software can be simple.

Besides, I like the fact that we get feature requests.  Our customers tell us what to build -- it's a logical way to create a product people will pay for.  But thousands of feature requests areimpossible to manage; it's almost the same as having none.

Enter Uservoice.  What a great name; it says what it does, it's evocative, it's even empowering ("giving users a voice").  The concept is simple: Anyone can post feature requests and vote on their favorite ones.  Each request has a mini discussion forum.  The most popular requests rise to the top of the list.

Want to see it in action?  Visit our page: http://feedback.codecollab.com/

We're going to push the hell out of Uservoice.  For example, we're putting a "Suggest" button in the menubar of every screen in our software.  Every feature request sent to tech support will be redirected there, and we'll be going through our feature backlog redirecting folks to the new site.

The hope is that users will self-organize.  Popular features will have more discussion, not just amongst users (because who can agree on the best way to implement something?) but between our developers and our beloved users.  Now we can ask questions of everyone interested in a certain feature, hopefully getting to the heart of the real pain that our users are sharing.  We could never do that with a massive list of line-items in an issue tracker.

If this works, the same technique could be used for all sorts of things:

• We're setting up an private Uservoice site to track marketing ideas -- we have 50-100 ideas and we'd like to start internal discussions on which ones to try next.
• Have one Uservoice site for existing customers and a separate one for potential customers just trying it out.
• Let your customers give you feedback on your website.
  
• If you're a consultant, lawyer, speaker or other professional you could use it for anonymous feedback.
  
• Company "management" could demonstrate they care about doing a good job by opening a personal, anonymous site for feedback (like glassdoor, but private).

I'll keep you posted as we learn more about Uservoice's shortcomings and advantages.

If you have experience with Uservoice or any other self-organizing feedback system, or if you've contributed to our feedback site, please help us all by leaving a comment!

Is it OK to Sucks?

I first read that bizzare phrase -- is it OK to sucks? -- in a Slashdot article seven years ago. Companies like Lockheed Martin were suing people who registered LockheedMartinSucks.com and a big battle ensued over the line between free speech and trademark violation.

I had that phrase in mind when I suggested that the title on our full page advertisement should read:

Peer code review doesn't have to SUCK.

We were brainstorming.  There were other ideas.  I had to admit it might offend some readers.  I lost.  Fine.

We went to press and the ad did really well.  We scored in the top 95 percentile on various measures in an independent test.  We got a surge in folks trying our stuff and asking questions.  So no regrets... but still... "suck" is funny...

Six months later I got the SD West 2007 Conference Guide.  On the inside front cover was a letter from the conference organizer entitled, "A Conference that Doesn't Suck."  Hey!

Then I find David Platt is giving a talk called "Why Software Sucks."  The work "suck" appears three times in the course description.  In fact he even wrote a book with that title.

Nowadays it seems like every day I see a company with big-name customers who uses the word "suck" on their front page.

Turns out it is OK to sucks!

It's better than OK.  Small businesses have to get noticed with no money.  The least you can do is give yourself a notable phrase.  Or image:

Take a chance.  Risk offending.  If you don't offend some people, you're not saying anything worth hearing.  Being notable beats being forgotten.  For every person who is offended there's another who just fell in love.

Procrastinate for Success!

I'm a habitual procrastinator. It's a funadamental component of my psyche. It's also an important factor in success at running a small business. Here's why.


In a small company you're overwhelmed with things to do. At Smart Bear we still have a dense whiteboard full of marketing ideas we don't have time for, dozens of index cards with cool features we don't have time to implement, and 7,000 open issues and minor feature requests in Fogbugz we don't even have time to look at.

And that's now, with five years of work and fifteen employees. It was hundred times worse at the beginning with just one person to do all the work.

This one person must have worked tirelessly. (He did.) This person must have been willing to do every kind of job. (He was.) This person must have been hyper-organized, allowing nothing to slip through the cracks, spending precious time on only the most high-valued tasks, not just working on whatever this person felt like at the time. (Ummmmmm... <looks sheepishly at toes>... not so much.)

"Don't put off 'till tomorrow what you can put off 'till the day after tomorrow." Thanks, Mark, for guiding the overwhelmed.

You really do have too much to do. Prioritization might be best in theory, but plain, gut-feel procrastination might be the right way to go. 

Many things blow over if you just ignore them. The big feature you got worked up about yesterday seems unimportant in the cold light of today. A feature a customer says is vital turns out to be something suggested by their intern, not something actually stopping a sale. An apparent fundamental bug turns out to be a misconfiguration. An important meeting turns out to be unimportant.

Besides, a lot of those tasks aren't as important as you think. Even something critical like accounting can be put off. Late fees, lost receipts, penalties from the IRS: financial burdens more than compensated by additional revenue gained by signing up one more customer.

Financial tasks in particular also have the property of being faster to do in a big sweep rather than as they trickle in. It's faster to enter 100 receipts into Quickbooks once a month than to enter three a day. Little tasks like that still have context-switch overhead, plus you get fast at typing and keyboard shortcuts when you're doing the same action hundreds of times in a row.

Finally, sometimes you've got to let yourself do fun stuff at the expense of priorities. Most of what you do in a little company isn't what you enjoy doing; it's easy to become frustrated and burned-out. So sometimes you need to allow yourself to recover with plain fun. Whatever the cost of putting off duties, burn-out is even more costly.

Yeah I know I'm rationalizing.  But you can't do everything, so don't.  And don't beat yourself up over it.