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.

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.

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?

Resumes considered harmful, or at least useless

In our recent hiring effort, I've noticed that I've approached all the resumes the same way: I don't read them.

Sure, I go through the resume before the phone screen, marking passages for discussion. Hope for the best, prepare for the worst...

...Oh you know 11 programming languages? Great, let me ask you a deep technical question about number 9, Visual Basic. How do you get the length of a string in Visual Basic? No idea? Oh you'd look it up. So the extent of your knowledge is your bookmark to the "Visual Basic Functions" page in MSDN on-line. OK, so which of these can you actually answer questions about? Just Java? OK...

...It says here you were the team leader in developing a reporting system against an Oracle back end. Nice, so you know Oracle? Great! What does "SELECT" mean in SQL? You didn't run into that bit of arcane knowledge? How did you write those reports? Oh a contractor set them up. But you did some data analysis? Oh a "team member" did that...

Am I alone in feeling that resumes are useless? That junior developers can't be judged by resumes because they have nothing to say yet and that senior developers can't be judged by resumes because after 10 years everyone can say the "right things" on paper?

Apparently not! Take it Seth:

Great jobs, world class jobs, jobs people kill for... those jobs don't get filled by people emailing in resumes. Ever.

Chime in Joel:

The standard job application of cover letter plus resume is a phenomenally weak way to introduce a candidate. They give you only the faintest clues as to the quality of an applicant.

It's everywhere. Almost a meme. What did Warren Buffet have to say in the latest Berkshire Hathaway annual report? (highlights)

Charlie and I are not big fans of resumes. Instead, we focus on brains, passion and integrity.

OK but wait, is this really fair? Maybe if you're applying for some cool position but what about getting a regular job? Well yes, if you want a regular job it might work to approach things in a regular way. If that's what you want. Is it?

What's stopping you from having a completely different perspective on the resume-and-cover-letter strategy? Are you afraid the HR department will toss any resume that doesn't match their acronym pattern? OK, with many companies you're right. But do you really want to work for a company that rewards acronym-counts over interesting achievements? That values standards-compliance over unique accomplishments? That rewards professional conformity over personality and passion?

Seth sums it up wonderfully (my emphasis):

Having a resume begs for you to go into that big machine that looks for relevant keywords, and begs for you to get a job as a cog in a giant machine. Just more fodder for the corporate behemoth. That might be fine for average folks looking for an average job, but is that what you deserve?

If you don't have a resume, what do you have?

How about three extraordinary letters of recommendation from people the employer knows or respects?
Or a sophisticated project they can see or touch?
Or a reputation that precedes you?
Or a blog that is so compelling and insightful that they have no choice but to follow up?

Some say, "well, that's fine, but I don't have those."

Yeah, that's my point. If you don't have those, why do you think you are remarkable, amazing or just plain spectacular? It sounds to me like if you don't have those, you've been brainwashed into acting like you're sort of ordinary.

We called him Tortoise 'cause he taught us!

We're interviewing for junior software developers right now. I've just completed about 20 phone interviews and the lack of useful experience is appalling.

Let's not rehash the arguments about what is "computer science" and how to hire and about how most people are no good and all that.

I'm not even talking about how smart they are. I'm just talking about the coursework.

It's time for "computer science" to become "science" and not math. Meaning: Learning to use the tools and techniques of the trade, not just formulas and mathematical analysis.

For example, of the 100 resumes and 20 phone interviews I've done in the past month:

• 3 have ever used a version control system; only 1 of those could describe what version control is.
• 5 even claimed to know anything about SQL; none of them could tell me what an "outer join" was.
• 6 have ever done a unit test; zero had ever done a unit test in school.

I can't understand why, for example, "SQL" isn't a required course. I'm not asking for much -- OK if you want to emphasize the mathematical properties of queries, OK if you want to teach data normalization theory. I'd prefer practical things like "never delete data" and "auto-increment versus GUID's" and "how to diagnose slow queries" and "how database vendors differ," but I'll take anything at all where they could at least form basic queries and know roughly how they work.

Even "unprofessional" open-source projects all use version control. The vast, vast majority of software companies do too. Version control is almost as important as the compiler. I'd be happy if there was a course where you learned things like branching theory, but I'd be content if they just used it at all, at any time. Schools love group projects, so how is it that the group project doesn't involve version control?

And no unit testing? Ever? That's just lazy. Why is that not required for all coursework? By the way, if you required it, almost all assignments would be correct when they were turned in. Isn't it better to teach people how to make sure they always get an 'A'? How is unit testing now on par with how to debug?

Which is another thing. I never had any instruction on how to use a debugger. To me that should be an entire class -- how to find out what's wrong with code, especially when you didn't write it. And unit testing should be a part of that.

I can think of two reasons why these obvious things aren't taught:

1. Professors don't know these things either because they don't keep up with new trends and practical processes. Of course I'm making a wide, unfair judgment, but witness for example the slow acceptance of Java.
2. Departments don't want to "sully" their pure, theoretical, artis liberalis culture with practicalities. Analogy: The math department is mostly theoretical. If you want applied math, be a physicist or an engineer. My problem with this is there is no alternative. OK, so have a theoretical computer science degree, but then where's the "engineering" alternative? Some colleges have this concept, but for example at UT the alternative just meant fewer hard CS classes, not more practical classes.

Oh well. From what I can tell it's the same in a lot of disciplines. Most of the MBA's I know can't run Quickbooks or read a P&L, and the ones that can tell me they learned it on the job.

OK, I like on-the-job learning, it's the best kind, but throw me a bone. At least broach the concepts somewhere in the 4-5 year curriculum.

We Won the Jolt Award!

For those of you who don't spend 80% of your lives in front of a compiler, the Jolt Award is the Oscar of the software development world.

Code Collaborator just won the 18th annual Jolt Award in the category of "Collaboration Tools." We beat out some excellent competition including Atlassian's Confluence and JetBrains' TeamCity.

Now, before you ask...

Yes, that's a real 24-ounce can of Jolt soda.

No, Jolt is still in business and still sells the cans in some places.

No, real soda would explode in the process of being encased in Lucite, so the can is tapped, drained, and pumped full of silicon, which makes the whole thing really heavy.

90 grams of sugar.

Yes, I'll report back on how winning the award affected our web traffic and download numbers.

The thanks goes to everyone at Smart Bear for not only creating an incredibly successful product, but treating our customers so well that our message becomes news and a story and not just another product at another company.

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.

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. :-)