Showing posts with label selling software. Show all posts
Showing posts with label selling software. Show all posts

Tuesday, November 11, 2008

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.

Friday, November 7, 2008

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!

Saturday, November 1, 2008

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.

Wednesday, October 8, 2008

Giving it away

In The Coldest Call, Gerry Cullen gives us an pithy rule of sales:

If you can't give it away for free,
you can't sell it.

It sounds tautological at first, but it helps you create products that are easy to sell. Here's how.

Because of Smart Bear and this blog, I hear new company ideas all the time. When I start asking about new products, the conversation invariably looks like this:

Me: Would you get customers if your software were free?

Confident Entrepreneur: Of course! Why not take it if it's free?

Me: That's what I'm asking -- are there reasons people still wouldn't take your software even if it were free?

Confident Entrapreneur: Free is free. Of course they'd take it.

Not so fast there, pardner.

Let's say it's 1998 and you've invented a corporate-wide spam filter. Great timing -- the web is exploding, everyone has an email account, spam is choking in-boxes and wasting time. You've invented a box that sits in front of the mail server, tossing the garbage before it hits your server, much less your workstations and laptops.

So couldn't you give away a free spam filter?

Well. What happens when the filter accidentally marks something as spam when in fact it's a real email? Will we lose productivity as people get confused or spend time digging through a massive spam dumping ground looking for the message? Does email recovery require an administrator? Will he be drowned in requests? Will we have to hire a spam depository admin? Operating this system clearly costs time and money.

How much training is required to get people to use the new system? How many spam-filter-related questions will hit our internal help-desk? Support activities are expensive.

What if the spam filter box gets overloaded with too much mail? If there's a bug, is it possible to loose an email completely? What happens if the spam filter box crashes -- does email cease across the entire company? Losing email is unacceptable.

These concerns are so scary and costly that the spam filter might not be worth it, even for free. And if you're ambivalent about taking it for free, you're certainly not going to pay for it.

So how do you design a product that passes Gerry's test? Ask yourself brutal questions to root out how your product might cause more pain than it solves. Here's some to get you started:

If your product fails catastrophically, what's the impact?

Good answers include:
  • Because the product is completely independent of any other system, in the worse case you're back to how things were before you bought our product.
  • We'll show you how to configure other systems to silently and automatically route around the failure. During the trial period you can test this yourself.
  • We have built-in support for switching back to the way you were doing it before.
  • Administrators are instantly alerted of the failure
  • You can use your existing monitoring/alerting system to detect failures
  • We support live-redundancy and continuous backup

Is it easy to rip this out if I don't like it?

Good answers include:
  • Since this system is completely independent of all other systems, you can just turn it off.
  • All data in the system can be exported at any time in a standard, human-readable format (e.g. XML, CSV). (You can also use this for backup.)
  • Because we handle catastrophic failure gracefully, you can literally pull the plug and everything else continues to work.

How much training does this require?

Good answers include:
  • Our website has pre-recorded training presentations. We give you the source materials for free so you can customize for internal training classes.
  • We have tutorials and screenshots showing how to do common tasks.
  • We have excellent in-product help, as well as a printed manual.
  • Accomplishing typical tasks is obvious.

Can my end users inadvertently break the product or prevent other users from using the product?

Good answers include:
  • Each workstation is separate so it cannot break other people's workstations.
  • The server has quotas, permissions, and other administrator-controlled limits to prevent excessive or improper use.
  • We support running inside a virtual server so our software failures are isolated.
  • We blast our software with load-testing, failure-case testing, and intrusion-testing, so we know that users can't break it with normal use.

If your company goes out of business, what's the impact on me?

Good answers include:
  • Because you own the software/hardware and you host it yourself, inside your firewall, you're not affected.
  • Because your license code is good forever -- only upgrades require you to give us more money -- the software continues to work.
  • Although we charge a monthly fee, the license agreement states that if we go out of business you can continue using the software without charge.
  • We'll put our software in escrow so if we cease support you have the ability to maintain the product yourself. (In this case it's reasonable to require the customer to pay all escrow costs.)
  • Our software is open-source and licensed such that you can continue using it and changing it. (This works if you're selling professional services.)

With these questions in mind, here's some ideas for tweaking the corporate spam filter product:

  • The filter runs as a plug-in to your existing mail server. The email admin therefore has full control over when it runs, making it trivial to disable.
  • If the plug-in fails it makes a log in the mail system which can then be monitored by the same tool that already monitors the mail system.
  • Because it's a plug-in, it scales as your mail server scales.
  • Users get one email per day summarizing the mail that was marked spam. They can glance over it looking for things that are not spam, and use a link next to each one to recover it, in which case it's instantly delivered to their inbox. Thus they can help themselves most of the time without burdened email admins.
  • The summary email can is clear enough that most people will understand it without training classes.
  • Spam emails are stored in a special folder in the mail system, not in a proprietary format. Then data access and backup can be done with any email client, even if you uninstall the spam filter, even if the supplying company vanishes.

Does your product pass Gerry's test? Want to brainstorm about it? Leave a comment and let me know.

Saturday, October 4, 2008

Customers over Employees

Alex Kjerulf articulates why customers can't always come first.

Let me get this straight: The company will side with petulant, unreasonable, angry, demanding customers instead of with me, its loyal employee? And this is meant to lead to better customer service?
Everyone says "put customers first."  They pay the bills, they're who the company exists to serve, they're the ones who must be satisfied, in their hands rests word-of-mouth, the most powerful force of marketing.

But what about employees? The ones who you'd like to be motivated to serve these customers, day in and day out. Where do they fit in the customer service model? When it comes down to employee happiness versus customer happiness, what do you do? And yes, it can come down to it.

Some customers are so poisonous to your poor employees that it's your duty to get rid of them.  Some you should wish on your competitors.  Sometimes the customer isn't right.

Maybe 1% of your customers are problematic, but they're a vocal and time-sucking and morale-draining 1%.  Is 1% more business worth it?

Wednesday, August 20, 2008

Avatar Marketing

Addressing your entire customer base at once is tough, but it's exactly what your web page has to do. Unfortunately most companies approach this in exactly the wrong way.

Examples of our struggle:

  • We want managers to see that they'll get metrics and reports, but we want end users to see that they'll save time and busywork.
  • We want to look professional so big-company managers are comfortable choosing us, but not so aloof that small-company developers think we're too corporate and can't relate.
  • We want to highlight our configurable workflows that allow large customers to apply one tool for all groups, but we need small customers to realize that you can turn all that off so it doesn't slow you down.
The usual response to this conundrum is to cast a wide net. The worry is that if you hit one type of customer on the head, another type will feel excluded and might look elsewhere. So you use generic messages like "The Power to Know."

This is dangerous thinking. Generalized messaging has no power, no emotional connection, no interest. If a phrase like "The Power to Know" is equally useful for business intelligence software, buying decision analysis, and theosophical treatises, it's not exactly hitting the nail on the head.

Let me suggest a completely opposite approach. Start by describing a perfect customer. Give her a name (Carol). Pick a concrete company that she works for, a company similar to one of your existing, thrilled customers. What's her official title and what does she do? If your potential market includes a wide variety of company types and positions, just pick one in particular. Whatever problems your product solves, Carol has all those problems. Write those down from her point of view, the way she would describe them if complaining to a friend over lunch. Whatever advantages you have over your competitors, Carol needs exactly those things. List them.

Carol is literally custom-built to be blown away by your product.

Now the question is: What would a web page / Google ad / print ad / tradeshow booth / postcard be like such that Carol would immediately understand that you are her savior? Remember, you get only 3 seconds to grab her attention and another 5-10 to convince her that your product is the second coming.

Can you make it clear in a picture? Maybe a before/after she can relate to? Will describing three features make it plain? Will pointing out your best competitive advantage make her weep for joy? Can you ask a provocative question, something she identifies with? Is there a phrase she'd laugh out loud at because "that's so true?"

You only get a few seconds, so a paragraph won't do. You have to communicate in a picture and a few words. The good news is you have to please only Carol, and you know Carol. You even know she'll honestly be thrilled to find you.

If your ad can't grab Carol's attention -- your perfect customer -- why do you think it will grab anyone else's attention?

If you still say it's impossible to communicate your message in 5-10 seconds, no one in the world will get your message.

This isn't just an academic exercise; your ad will work on non-Carols too! In fact, non-Carols might not be as "non" as you think:

So called "large company managers" might be running small agile groups; you might do well to appeal to that side of them. Software development managers might like metrics, but it's wrong to think they are unconcerned with their developers' quality of life. Yes big companies like to choose "stable" vendors, but small companies with strong products are in vogue now, and even IBM admits that people can be fired for buying IBM.

When your message is powerful, Carol and anyone remotely like Carol will notice. If your message is weak, no one will notice.

Thursday, August 7, 2008

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.

Friday, August 1, 2008

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.

Thursday, July 24, 2008

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.

Monday, July 21, 2008

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.

Saturday, July 19, 2008

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.

Sunday, May 11, 2008

We're on the same page

Advertisements are typically designed to stand on their own. Expensive ad firms frame comps on black construction paper, focusing attention and emphasizing isolation.

But how would your advertisement stand up if it were displayed side-by-side with your competitor's ads?

This happens a lot actually. Your Google Ads are likely to come up next to competitor's. Product listings in catalogs and websites usually group products with their competitors. Magazine ads are often juxtaposed. Potential customers may even print out your website and physically place it next to your competitor's on their desk. In color.

How does comparative advertising affect your message?

In the age of user-driven information flow, you can assume that a person looking at your website is in the market for a product like yours.Therefore expending effort justifying your market space in general might be a waste of those precious few seconds when a person visits your website for the first time. Besides, extolling the virtues of your market validates your competitors as much as yourself.

Instead, what features (and benefits) does your product specially have to offer? What are your strongest claims, the ones your competitors have trouble competing against? If you're the fastest, explain how speed enables new features that would otherwise be impractically slow. If you're the most customizable, emphasize how your tool can support a process rather than dictating the process.

That's not to say you shouldn't address general market advantages at all. In fact, it's often possible to simultaneously fold general benefits into your specific ones.

For example, which of these ads is more compelling:

  1. Relieves painful migraine headaches.
  2. Relieves migraines faster than anyone else.
The second ad conveys both the general benefit ("relieves migraines") and the competitive advantage ("fastest").

This also points out that communicating the general market benefit is often unnecessary because the end user already gets it. If I have migraines, I already understand my pain and I understand the benefits of pain relievers. You don't have to tell me migraines are "painful," just get to the point!

As another example, this time from Smart Bear, we claim that one way Code Collaborator saves time with code review is that we show chat next to code, and the chat sticks with the code even when you upload fixes (where the line numbers shift around). On one hand, we're describing a general feature (chat in context with code) shared by all 3 of our major competitors, but at the same time we point out features that only we have (i.e. two competitors show chat in a separate window, not with the code, and no competitor is good enough to keep chat in the right place even after files are updated).

If you want to stick out from the crowd, explain why you're the best medicine, not why I need to take medicine.

P.S. Exception: If you're pioneering a new market space, this idea doesn't apply. In that case you need to explain and defend your very existence; in fact this was the case at Smart Bear for the first 5 years.

Monday, April 14, 2008

Agile marketing interview at GeekAustin.org

I just got interviewed about "agile marketing" over at GeekAustin.org. It was fun to show how we apply principles from agile software development to business and marketing efforts.

If you're involved software or marketing in Austin, you should meet Lynn Bender, the founder and organizer at GeekAustin. Maybe come to the Agile Happy Hour in two weeks! They're always a blast.

Sunday, March 30, 2008

Identity Crisis

This (stolen) picture of logos demonstrates a property of corporate image done well: Even when the logo is obscured in an unusual way, I can still identify the company.

I even distinguished the "The" from "The New York Times" and the "The" from "The Wall Street Journal."

Is your corporate image so unique that this trick would work for you? Here's a hint, if your logo is just some meaningless shapes made by a Photoshop weenie, the answer is no.

If your logo were a performer on American Idol, would Simon Cowell say "It was OK, it was safe, but your problem is you're forgettable."

So change it! I know that sounds scary, but if your image is already forgettable, changing it isn't a big deal.

Don't worry about confusing existing customers. Customers love you, not your logo. They will be pleased to see something interesting. They'll be happy you're making a bold statement about who you are. You can announce it to them if you're afraid they'll get lost. When we upgraded our logo not one person was confused and many complemented us on the new look.

Don't worry about resetting your brand equity. Unless you're Google or IBM, the vast majority of your potential customers never heard of you, much less have an attachment to a logo. Even if they've seen it a few times, if you're forgettable, they will have forgotten. Better to reset now and start spending money on an image they can remember.

Finally, remember that "image" is more than logo. It's the attitude of your prose, it's a cool give-away, it's a killer idea presented clearly. Make a bold, unique statement if you want to be remembered.

Saturday, March 22, 2008

Caricatures

Political caricatures are less about exaggerating features and more about telling a story.

A caricature emphasizes unique features. Every candidate has two eyes, a nose, and a mouth, but only one has big ol' ears. A caricature also has a point of view -- is the candidate cool? Old? War-hungry? Defensive?

All in a picture. No words.

If your product had a caricature, what would it look like? What are the unique features you would emphasize?

It's useful to think this way because you can't throw 800 typical marketing words into one picture. "Easy to use." "Scalable." "Fast." "Enterprise-class." "Flexible." "Customizable." "Reporting."

Everyone claims these things. Snore. What if you had to pick just one? Or better yet, find something else that few others can claim. Something you can assert that your competition couldn't even try to say.

And putting it into a picture without words is useful too. Communicate a powerful, unique message in 3 seconds. Something that might otherwise take a paragraph. A paragraph your potential customer might not take the time to read.

An example from Smart Bear is our side-by-side screenshot. If you're a developer, and you reached our web page because you're looking for help with code review, this image is all you need to know. The "content difference" concept is obvious; the fact that it's in a web browser implies you can do this from anywhere, at any time; the piece on the left is obviously a chat area, which implies you can talk; the blue borders around code-line and chat implies you can talk about code.

You can use the same trick for identifying how you treat customers. Now you can't get away with saying trite, meaningless drivel like "we value our customers" or "we exist to serve our customers."

If you really exist to serve your customers, the picture might be of an average-Joe being served wine by a suit-wearing executive. I like that image! But is it accurate? If so, put it up on your "Our Customers" page and show you mean it. But if you the thought of that image makes you laugh, if that's not truly how you picture your relationship, then rethink your values.

P.S. The image above and comes from a fascinating entry in the NY Times Blog.

Friday, March 21, 2008

Discount gambit

Which of these pricing strategies is more persuasive?

  1. If you buy now, I'll get you a discount.
  2. The price is going up, but if you buy now I will lock in your rate.
Both are types of discount. The typical software sales strategy is #1. It's often applied to get the customer to "close" before the end of the month or quarter or some other arbitrary time boundary.

At first blush it seems harder to persuade with #2. After all, #1 means the customer pays less than #2, because #2 isn't a real discount -- it's a discount against some future price, which is a lot harder sell than a discount today.

But for me, the evidence is overwhelmingly in favor of #2. Here's why, from the point of view of the customer.

You've already established your price. In strategy #1 there's a discount if I "act now." Hmm, so that means the old price wasn't really the price after all. The old price must have included a nice slice of pure profit that apparently you're willing to leave behind. So you were gouging me before. And the only reason I found out about it is that it happens to be the end of the quarter?

This is how #1 breeds mistrust -- the opposite of what you're trying to establish with me, your customer. In #2 you're looking out for my interests. You're cluing me in that there might be a rate increase, and you're actively protecting me from it. Sure, I know there may not be an increase, or it may not come for a while. But it's still protection, not a gouge that you graciously chose to reveal.

Four years ago I was trialing .TEST from Parasoft. It was buggy; even after hours of remote desktop control with tech support we couldn't get it to stay up long enough to scan my code.

But the salesman was persistent. The conversation went like this, minus many minutes of sales-speak on his end of the phone:
"How much will this cost me?"
"$20,000."
"Wow, I thought you were going to say $2,000. That's way out of my price range for one person and this product. In fact, I've looked at FxCop and NUnit and [something else] and it seems to me I can do the same thing with free tools. I was willing to pay for some convenience, but not that much."
"Let me see what I can do."
"No nevermind, it's, like, an order of magnitude problem."
He called back the next day.
"$1,500."
I didn't buy. I talked to someone who did, though. A reference customer. That guy said he paid $20,000. I asked how he liked it and whether he encountered the crash problems I was seeing. He said they hadn't installed it yet, but the demo looked great. I made a mental note to try to understand the mentality and budget that forks out $20,000 for a nice demo.

But getting back to the point. If he can go from $20,000 to $1,500, maybe he will go to $1,000. Yes, this strategy means often you will extract extra money from me. But it also means I don't know where the floor is, and I have every incentive to haggle. The process drags out, ending at gunpoint. Meanwhile your "customer relationship" is now more of a "hostage situation."

So let me get this straight: It's better to get an extra 10% on every order, but create an adversarial environment with me, your cherished customer? This is enterprise sales, right, where the pilot is 30 seats and the roll-out is 2,000? And you're going to risk pissing me off over 10% on the 30-seat part?

And now imagine if I had called back that reference customer and told him he could've had it for $1,500? Yet another problem with discounting -- word gets around, meaningless differences in pricing is unfair, and now I, the customer, see you as plain old dishonest. Goodbye 2,000 seat order.

Even if we set the honesty/relationship argument aside, there's the matter of image.

What kind of company provides a #1-style discount? Wal-Mart, Target, Walgreens. No, software companies. Try to get quotes for Microsoft or Oracle or IBM products for 1000 desktops. Everything's negotiable, everything's discountable. At best it conjures images of haggling and struggle; at worst of low-quality or the desperate need to "meet numbers" at the expense of everything else.

Which companies don't discount, ever? Apple, Google, Constant Contact. No discounts on iPhones. No haggling over AdWord prices. What's the image? Desirable. The best. Worth paying for. The leader doesn't have to compromise. The leader isn't desperate for orders.

Strategy #2 implies growth. You've planted "higher prices" in my head now. Supply in software is unlimited, so that must mean demand is increasing. I won't go through that calculus, but certainly I feel the product is becoming more valuable, not less. Discounts feel like unloading unwanted product; price increases feel like success.

Strategy #2 implies I'm part of a club. I've gotten in early, on the ground floor, before the product explodes in popularity and prices go up. And I'm rewarded for this support and loyalty with price protection. A "thank-you" from you to me because I was part of it, because I was there before you were big and expensive, because I took that risk with you.

So there it is. #1 means less money now, an adversarial relationship, a never-ending struggle over money, and a message that maybe the product needs a discount to be desirable. #2 means more money now, a consistent and fair pricing policy, an inclusive, special customer relationship, and a message of market leadership and growth.

So why do 90% of software companies pick #1?

Wednesday, March 5, 2008

Using fear to discover what's important

One of the biggest fears in a software company is that their source code could be leaked. All secrets revealed! All that trial-and-error and long hours with customers and careful planning... the results of that effort are now sitting on your competitor's desktop, free for the taking.

Although we know it probably wouldn't make a difference, investigating this fear turns out to be a valuable exercise

When you cringe thinking of your next open-source competitor having your source code as a starting point, what specifically comes to mind?

Surely not all your source code would help them. Some of our code is seriously bad news. I would wish this code on a competitor.

Besides that, a lot of our code is not interesting or can already be pilfered. The code that lays out our HTML? You can see that using "View Source." Our method for moving data between Java objects and the back-end database? Who cares, everyone uses Hibernate. Our web-application architecture? Who cares, nowadays everyone should be using different architectures that were built from scratch to live in a DHTML/AJAX world.

So what would I actually worry about?

Here's one. Our version control integration library is built from five years of hard-won experience in the field. There are so many corner-cases and combinations of configuration. It represents thousands of man-hours. We have thousands of unit and integration tests, most of which using data that came from the field. Our advanced integration is unique in the market and is used by every one of our customers, so giving up that insight to a competitor would hurt.

There are a few other things, mostly complex, optimized algorithms. But what's amazing to me is that the overwhelming majority of our code could get leaked, and it wouldn't help a competitor.

I'll bet if you're honest about your own project you'll find the same.

Implications

1. We're by far the #1 product in our market, even though almost none of our code is "secret sauce." Maybe having "secret sauce" isn't nearly as important as execution. Maybe your customers are interested in how you treat them and whether you're implementing features they need, and not interested in how much work it took to write the code. Maybe it's more important that you can get eyeballs to your website and that your website gets people to download, and not so important whether you have a patent on something.

2. We should leverage our uniqueness in marketing material. I just identified the parts of our code that make us unique and where our competitors are not likely to catch up quickly. "Secret sauce" in code can point the way to market differentiation.

3. We could be spending less time on the stuff that isn't "secret sauce." You have to be careful with this rule because it would be easy to say, for example, "Because the layout of our website is easily copied, we shouldn't spend time coming up with a great layout." Dead wrong!

Here's a better example: We rolled our own web application framework because we felt it would give us a leg-up in certain ways. But in retrospect, the framework ultimately didn't do anything that special, certainly nothing that a customer would care about. Before embarking on a large, time-consuming project that could be satisfied by a tool or library, consider whether you're truly adding "secret sauce" that will give you a leg-up, or whether you just felt like reinventing the wheel.

4. Perhaps it would be useful to employ selective obfuscation. Whole-project obfuscation is at best a pain and at worst can create bugs in code that depends heavily on introspection and dynamic loading. And this exercise shows that it's not that useful. But there are certain places where it is useful, and obfuscating a small number of well-understood classes is easy and relatively safe.

Tuesday, March 4, 2008

Free for all

What would happen if tomorrow we made freely available all the source code to Code Collaborator?

Can you imagine Intuit releasing the source code to Quickbooks? Or EA Sports handing out the code to NHL 2008? Even cool companies like 37signals go so far as to encrypt their hard drives against theft of code.

Most software companies would consider such a thing contrary to everything they hold dear. But sometimes it's worth challenging assumptions.

Why not?
So what are the specific reasons to not publish our source code? What are we afraid of?

Well this should be easy...

Competitors catch up to us quickly because they can easily copy everything we've figured out how to do: Cool AJAX/DHTML techniques that they don't have; Super-smart file-differencing algorithm; Interfacing with 7 version control systems while handling all the corner cases.

We show them the way, they catch up, and suddenly we're neck-and-neck instead of keeping our lead in awesome features.

Support becomes impossible as customers make arbitrary changes to the code. They could change anything -- from benign things like CSS styles to introducing a subtle bug in application logic. It's hard enough to track down problems in the field without "all the code" being a variable!

Besides supporting bugs, you know we're going to get source-level support questions. Yeah you can say "we don't do that," but it's going to happen and it's hard to turn people away.

Potential customers scared away after seeing the state of your code. You laugh, but it's a valid concern. Much of our code is well-documented and well-tested. But some isn't. Some is downright embarrassing. You never know what someone else's impression might be.

Yeah, but not so much. Apparently all these fears are unfounded.

Here's my disconnect: There are small companies just like us who publish all the source code to their software, and none of these concerns are a problem for them.

Take for example the issue-trackers JIRA (Atlassian) and Fogbugz (Fogcreek). Both are in an insanely crowded space with fierce competition ranging from open-source to small-company closed source to big-company software/services.

And yet, both are popular even with the fear of competitors stealing secret sauce. Both are highly profitable, not buried under a mountain of technical support. Both have ugly pockets of code, but I've never even once heard anyone mention that as a downside, not online, not in the field, and certainly not as a reason to choose a different product.

So what's the explanation?

Ummm, just because?
All the following are theories. I honestly don't know the answer.

To me the biggest upset is in the assumption that competition automatically gets tougher. Here's some possible reasons why it doesn't:

1. Writing an algorithm is just the start. So let's say a new competitor steals our awesome, optimized, unique AJAX/DHTML code for real-time, context-sensitive chat. So now we're even? Well it doesn't matter until a potential customer is checking them out, which means executing on marketing and advertisement. And it doesn't matter if during the trial we give the customer a personal demo and responsive tech support while the competitor asks him to post a question on a forum. And it doesn't matter if all they can claim is that they're "the same." All else being equal, most people will go for the incumbent, proven, most popular tool, which is us.

2. Competitors need to differentiate. Even if you could be just like another product, you don't want to be. Sure you might pick up some ideas for algorithms here and there, but that's not enough by itself to sway potential customers.

3. Developers like doing things their own way. Every good developer I know wants to write code herself. Yeah you might pick up some ideas but your first reaction to almost any code is that you could write it better, organize it better, document it better, make it more flexible, whatever.

4. Most code is not reusable. Almost all our code depends on assumptions, design, and other code that is relatively unique to our product. Sure we have some utility classes that could be copied and reused, but those are the kinds of things that are easy to unit-test-to-hell which means it's not hard to reproduce it even without our source code.

5. Serious companies don't steal. Any serious competitor will have internal rules about stealing code, even if it's an open-source project. Once again, little tricks here and there could sneak in, but not wholesale copies of libraries. A serious competitor has too much to lose -- revenue, customers, possible future upside -- and if that comes out it's all over.

The other two items are easier to understand. Support can be kept in check:

1. Most people won't change the code.

2. Limit support on source code changes. Your customers will understand that you cannot provide unlimited support on that front, so you can just pick and choose how much time to spend helping someone. It's no worse than a competitor who is closed-source.

3. Include a "source changes" report in tech support reports. We have things like verbose logs, config files, and diagnostic pages, so just add something that tells tech support what, if anything, has been changed by the customer. If something has been changed and you cannot reproduce the issue, you can now reasonably deny tech support unless they can reproduce with a clean installation.

So... are you going to do it?

Nope. :-)

Tuesday, February 5, 2008

Tell me a story

Malcolm Gladwell is as successful as any non-fiction writer could hope to be. The Tipping Point was the surprise #1 best-seller for months in 2000. Several stories therein have become part of our American vernacular.

Problem is, it all appears to be wrong. And no one seems to care.

Don't get me wrong, I like Gladwell too. His books are entertaining and they make you think. Getting published regularly in the New Yorker places you in the most elite class of writer. And deservedly so -- if you don't believe me, read this. Brilliant.

But then there's that little problem of him being wrong, a lot.

I first noticed the problem when I read Freakanomics. It's another great book on sociology, written by a science-minded economist (Steven Levitt) and a science-minded journalist (Stephen Dubner) and therefore able to both tell nice stories and back it up with convincing data.

On the cover of my copy of Freakanomics is this endorsement: "Prepare to be dazzled." By guess who? Malcolm Gladwell! Terrific, except the thrust of Freakanomics specifically disproves the prime theory of the Tipping Point. Here's how:

The "Tipping Point" is the critical point where a system can go one way or another. It's where a trend can either take off on a rampage or fizzle out before it gets off the ground. It's where a few small changes can snowball into big effects.

As one example, Gladwell explains the Broken Windows theory that (he claimed) was responsible for fixing the rampant crime problem in New York City in the early 1990's. The idea was to fix little, easy things and the big things will follow (because the Tipping Point will be crossed). So they cracked down on squeegee guys, they cleaned up Times Square, and they put pictures of real windows over broken windows in burnt-out crackhouses so they didn't look dilapidated.

And the crime went down, quickly and decisively. Awesome, right?

Well, science-minded folks are quick to point out that correlations don't imply causal relationships. Just because you did X and Y happened afterward doesn't mean X necessarily caused Y.

This is just the point of Freakanomics. In its most lengthy and controversial chapter, Steven Levitt points out that crime went down everywhere in America, not just New York. And at the same time. And that in various cities and states they were trying various methods of crime reduction from more policemen to curfews to after-school programs to Broken Window strategies, but crime went down the same way, everywhere, regardless. This would seem to imply that none of these factors was the primary factor.

There's only one factor that was common across the entire country: That in 1991 the population of people at highest risk for crime immediately diminished, and that's because in 1973 Roe vs. Wade was passed. In 1973 it suddenly became inexpensive and safe to have abortions, and millions of babies that would otherwise be unwanted and often unsupportable were not born, and did not turn 18 in 1991.

(It's even more compelling than this quick overview. For example, some states legalized abortion earlier than others, and each state saw the decrease in crime 18 years after that state legalized it.)

So back to the main point: That Freakanomics disproves the theory of the Tipping Point, and Gladwell still endorsed the book, and no one seems to care.

Well not no one. Duncan Watts has made a career in network theory, and specifically in debunking the entire "Tipping Point of trends" theory. From a great article in Fast Company:

"It sort of sounds cool," Watts says, tucking into his salad. "But it's wonderfully persuasive only for as long as you don't think about it."
I defer to that article for the fun details, but Watts takes each of the studies Gladwell told and points out how it was either misunderstood or misapplied.

When confronted with evidence like those from Levitt and Watts, Gladwell doesn't even attempt to defend himself:
Duncan Watts is exceedingly clever, and I've learned a great deal from his research. In the end, though, I suppose that I feel the same ways about his insights as I do about Steve Levitt's disagreements with me over the causes of the decline in violent crime in the 1990s. I think that all books like The Tipping Point or articles by academics can ever do is uncover a little piece of the bigger picture, and one day--when we put all those pieces together--maybe we'll have a shot at the truth.
But if you've read Tipping Point, you get the feeling you're being convinced of a theory, not getting a "piece of the bigger picture." To me this is a cop-out, too embarrassing to just say, "Yeah, it's wrong, but at least it had a lot of great stories."

It's this last point that I think saves Gladwell in the end. He is a master storyteller. After being beguiled with interesting, provocative stories, the reader is happy to receive Gladwell's unproven, non-sequitur conclusions.

The stories are so good, they're worth reading anyway. I know I do -- I read Blink cover to cover, the whole while shouting at its illogical conclusions and meandering, self-inconsistent theories, but loving every page and not wanting it to end.

So it's just another way to reinforce Seth's admonishment that marketing should be defined as telling a good story. Sometimes everything else is a second-order effect.

Tuesday, December 25, 2007

Outside-In

What do these things have in common:

  1. The People's Republic of China
  2. Smucker's line of "100% Simply Fruit" spreads
  3. Scrubs will be right back after these messages
They all follow Brandon's Rule: If it's on the outside, it's not on the inside.

China is not a Republic, that Smucker's line is 30% juice, and there's no more Scrubs after the final commercial break.

When something is true, you don't need to announce it. You don't need to convince people of it. You don't have to draw attention to it.

Here's some more:
  • We put customers first.
  • We treat customers as partners.
  • We have unmatched customer support.
The quality of customer support is something you notice right away. Either they answer the phone quickly, or they don't. Either the person on the other end genuinely helps you, or they don't. Either your "account manager" continues to provide service after the sale, or she doesn't.

I can't count the number of times I've heard a C_O say "What distinguishes us from our competitors is better customer service." Theoretically, having good service is not only a competitive advantage, it's also the primary way to develop solid relationships, promote word-of-mouth advertising (the best kind), and can even make a sale even when the first impression was unfavorable.

But you can't convince people you have good support by telling them so. In fact, telling them so might turn them off.

Here's what I tell folks in demos: "While you're trialing our software, also trial our tech support. Give 'em a call and test it out. Make sure we're responsive and helpful."

When you hit someone over the head with honesty, it leaves a mark. People are so used to hearing things like "We have unbeatable customer service" and "Customer service is priority number one," the words are water off a duck's back. Even if true, they're meaningless.

So when I tell them to try it for themselves, I get amazing reactions. "Wow," someone recently told me, "I've never had a vendor actually encourage me to call them for support." My response was: "Well, I could tell you we have great customer service, but you wouldn't believe me." His response to that: "I don't have to call. I already know you guys are going to rock."

When was the last time you built that kind of relationship with a potential customer during the initial demo? Just by being honest.

So don't say it, do it. Encourage potential customers to notice, but let them come to their own conclusions.