Wordle me this

Wordle is fun!

(Click to Enlarge)

It's also instructive. It's clear I write more about marketing and business than about software development. I didn't intend that at the outset, but there it is!

Hello, I'm 1074018628

I just received this email:

Yahoo! is committed to the success of account 1074018628 and we believe there is an opportunity to provide you with improved performance.

There's saying you value your customers, and there's your behavior.

You can use your customer mailing list to barrage me with up-selling "opportunities," or you can send me interesting articles.

You can put your customer service number on every page on your website, or you can provide only a web form.

You can have a recorded message saying my call is important to you, or you can have someone else pick up the phone.

You can answer the phone with the least knowledgeable, lowest-paid employee you can find, or you can empower service reps to give refunds, bend the rules for extenuating circumstances, and escalate special situations to someone who has the power to address them properly.

Is "customer service" a service for customers or a shield against them?

Actions > Words.

The customer is always right?

"The customer is always right," coined by somebody around the turn of the last century, is probably still a good mantra for retail, restaurants, and the like.
But many of our customers are the opposite. In fact, many hope that we'll tell them what's right.

During every demo there's a moment where the customer explains how they're going to do X in their process, and how Code Collaborator seems perfectly suited for X. Then, much to their surprise, I gently explain why X is a bad idea and Y is better.

Sounds arrogant, right? The customer is always right! And they were happy about X and happy that we would support X, so what the hell am I doing? Let 'em be happy!

What I'm doing is enabling them. I'm giving them advice from years of experience for free. I'm demonstrating that we tell the truth, even if the truth doesn't serve the direct purpose of selling the tool, even if it means I'm arguing instead of agreeing. And it's appreciated, because there's not enough truth in sales and business.

Of course the customer isn't always right, and with some types of business you should roll over. If you're runing a restaurant and a customer thinks a barely-red steak is "totally rare," just cook the crap out of it and give it back.

But if you're going to be an expert, be an expert. That means not just agreeing with everything the customer says, but genuinely helping.

Obfuscation

I got a new laptop recently. The main advantage of the new laptop over the old one is that the new one wasn't run over by a car. Long story...

Anyway while I was selecting my wireless card I was accosted by this astounding product description:

Intel Wireless WiFi Link 4965AGN (supporting Centrino Pro)

The Intel® Wireless WiFi Link 4965AGN product is an embedded 802.11a/b/g/Draft N PCIe Mini Card network adapter card that operates in both the 2.4GHz and 5.0GHz spectrum, delivering high throughput and a host of features that enhance today's mobile lifestyle. Deploying WLAN technology in your home and business increases productivity, efficiency and flexibility by enabling faster decision making, reducing down-time, and enhancing employee satisfaction. Quad-Mode Solution for maximum flexibility: the Intel Wireless WiFi Link 4965AGN provides deployment flexibility and connectivity convenience by offering a quad mode (supporting 802.11a/b/g/Draft-N) product, which is capable of connecting to new "Connect with Intel® Centrino®" wireless N Access Points / Routers, but can also connect to any of the legacy Wi-Fi standards, 802.11a, b or g. Data rates up to 300Mbps offer major improvement over today's 802.11a/g products that deliver 54Mbps. This helps overcome network capacity issues, allowing increased simultaneous network activity for large file transfers, network backups, streaming video, multi-player gaming, VoIP and more.

Here comes a rant with an ulterior motive. The idea is to develop a strong editorial voice in your head. You have to take the red pen to yourself so snarky pricks like me don't use your product description as a subject of ridicule!

After a rote description of the product, the writer chooses to list benefits disconnected from features, benefits that would apply to any competitor:

Deploying WLAN technology in your home and business increases productivity, efficiency and flexibility by enabling faster decision making, reducing down-time, and enhancing employee satisfaction.

Furthermore, these benefits are non sequiturs. Wireless enables faster decision making? Really? Reduces down-time? How can that be -- wireless is notoriously less reliable than cabled networks.

And is it really necessary, in 2008, to explain the benefits of Wi-Fi? If I'm considering skipping the Wi-Fi card, will this text convince me otherwise? Because it means faster decision-making?

The true benefit of this particular device is buried in the last sentence: Support for the latest Wi-Fi standard means more data per second, which is useful in specific applications like "large file transfers, network backups, streaming video, and VoIP." That's more like it. Why did it take 168 words to get to the point?

But I can't criticize without offering a solution, right? After boiling the goo out of this text, here's my outline:

• Supports four different Wi-Fi protocols, so it works in more places and takes advantage of the latest technology.
• Supports the fastest Wi-Fi standard, so high-bandwidth activities work better.
• The only card that supports the proprietary Intel N Access Point system

Get into the mindset of the skeptical. Be brutal. Every word counts. Challenge every sentence to advance the cause of either getting the reader's attention, communicating something specific and useful, or showing how you're a better choice than the other products on the page. Tie goes to the briefest.

The Benefits of Features

Common marketing wisdom is: Benefits sell, features don't.

Benefits are what the customer wants; features are merely the means to the end. Customers are interested in "saving money" or "saving time" or being "easier to use;" features aren't interesting until the customer understands and wants the benefits. Everyone says so.

My instinct is opposite. But, not wanting to second-guess tradition, I've dutifully fought my instincts at the behest of marketing and sales gurus. Since the first advertisements at Smart Bear I've had conversations like this:

Guru: Why is this here: "Integrates with version control systems."

Me: That's one of our features.

Guru: Say I'm a customer. Why do I care that you integrate with those things?

Me: Well normally you have to collect files for review by hand, but with this integration we can collect the files for you. So a mundane, 5-minute task reduces to a few seconds.

Guru: So it's going to save me time?

Me: Yes, and doing it by hand is error-prone and it's boring and ...

Guru: OK, OK, but mainly it saves time.

Me: Yes, it saves time.

Guru: Fine, than that's the benefit. "Saves time." I don't care yet how it works, just tell me how it will help me.

Me: So that's it? Just write "Saves time?"

Guru: How about "Cuts 80% of the time out of starting a review." That will grab my attention.

We'd do this with each of my feature points in the ad. So what started out as:

• Integrates with version control systems
• Threaded chat in context with code
• Automated metrics and reports

Turned into:

• Saves time
• Easier to manage than email
• Eliminates manual tasks

Looking back now over the last five years and considering what worked best for us, this technique still doesn't seem right to me because these benefit statements eliminate the interesting, unique properties of our product. Claims like "Saves time," "Easier to use," "Automates tasks," these are things that almost all software promises to do. Although these might indeed be the ultimate benefits, it's the same message as everyone else. I suppose I could claim "Saves more time than competitor X," but is that really the strongest message I have?

I agree that customers are interested in end results. Furthermore they need to picture themselves using the product and achieving those results. TV advertisers have long recognized the power of visualization; nearly every TV ad shows someone using and enjoying the results of the product.

But statements like "easy to use" are completely unhelpful in visualization. Even if you trump it up as "Cut code review time in half," I still cannot picture how that's going to happen. If I'm already a skeptical person -- quite likely with our target audience -- I might not wait around for you to explain it.

If your potential customers are experiencing pain, they'll automatically see how the feature achieves the benefit. Our customers already know code review incurs busywork and can be a huge waste of time. If I say "Writes reports for you" or "Collects metrics automatically" or "Packages and delivers code with one click," it's clear that the benefit is to save time and help with chores, but now you can visualize exactly how.

Be specific and tangible about what you do, just phrase it so it leads automatically to the benefit.

Pecha Kucha

As some of you have already noticed, I have the honor of being selected to give a Pecha Kucha presentation on agile marketing at this year's Business of Software conference in Boston.

Wow, that's too many links in one sentence!

If you're considering a career in running software companies, especially your own, go to this conference. The keynote speaker list alone is reason enough -- there's more wisdom in those heads and ability to communicate it to others than most business schools in America.

Surprised to find bugs?

Code Collaborator just got a great review by game AI specialist Paul Tozour.

My favorite excerpt:

The ostensible reason for this process was to get more engineers familiar with different parts of the codebase that they wouldn't have had any exposure to otherwise.

What we found was far more surprising -- we uncovered an amazing number of bugs before they ever reached QA.

Furthermore, the bugs were coming from everywhere, not just the junior engineers. All the engineers, including all of the most senior developers, had plenty of room for improvement.

This seems to be a common theme among groups implementing a reasonable code review process for the first time. ("Reasonable" means not encumbered by heavyweight process.) We're always surprised that our code wasn't as good as we first thought.

Shouldn't it be obvious? Have you ever written a page of prose that couldn't be improved? That you yourself couldn't improve when you look back a month later, but that you friend could have found with a two-minute scan?

Writing code isn't different, nor should we expect it to be.

By the way, once you get used to having the safety net of fellow programmers catching all your little mistakes, it's scary to go back to isolation. You know the bugs are there!