Jason Fried writes about a recent speaking gig:

But the one thing that really sold me on these folks is why they invited me to speak in the first place.

UIE professes a user testing and research driven methodology. We have a different point of view on how to build usable and useful products. Most folks who make their living on testing and research would not invite someone with a significantly different approach to speak directly to their customers. But UIE knows that different perspectives are ultimately good things for their customers.

Just like how Amazon lets their competitors sell against them on Amazon’s product pages, or how Progressive Insurance gives you the quotes for their competitors, UIE is a purveyor of valuable information, not just their information. I think that shows the mark of confidence and a genuine interest in helping people make good decisions. Shielding people from opinion because it’s not your opinion is petty and shallow. UIE is smart to avoid that tack. They know well rounded customers, a.k.a. informed shoppers, are ultimately better customers.

Jason is well known for his company’s Getting Real philosophy, a main tenet being that marketers should always design products not for their customers, but for themselves. That’s a stark contrast to the research-driven approach favored by UIE.

Both Jason and UIE have embraced their competition, however. They recognize that ideas aren’t always mutually exclusive, and having an in-depth knowledge of the competition fosters innovation and keeps you on your toes.

Posted on Apr 21.08 to Random Or Close To It   

Admittedly I’m a little late to the party, if only because Mother and I were still collating. If you’ve been living on another planet for the past week, here’s what you missed out on: to much fanfare and criticism, Google recently announced App Engine, a platform to “run your Web applications on Google’s infrastructure.”

The Genius

It’s been expected for quite some time that Google would compete with Amazon’s cloud computing offerings. Big companies make immense investments in developing highly scalable architectures, and it certainly makes sense to offset those costs by leasing the underlying technology to others.

Since the launch of Simple Storage Service (S3) in March 2006, Amazon has absolutely mopped up in this space. They continue to innovate on a seemingly daily basis, and Google chose wisely not to attempt a game of catch up. Instead they stuck to what they know best: distributed computing using BigTable, MapReduce, and Python. While Amazon’s cloud computing offerings are flexible enough to accommodate a wide variety of uses, developing on AppEngine serves only one goal: creating an infinitely scalable application from day one.

You mean no servers or deployment problems to worry about? Sign me up!!!

The Danger

Not so fast kid. Scaling is a problem most engineers wish they had. And such is the true genius of Google’s approach: it appeals to the emotional as opposed to the rational. Research has proven time and time again that people tend to buy primarily for emotional reasons, and Google didn’t get to where they are today by ignoring this fact. Only after an emotional decision has been made do rationalities begin to form: seamless integration with other Google services, creativity spurred by limitations, and even the possibility of a reduced barrier to acquisition by the Big G itself.

As sexy as scaling problems might be, they just aren’t that common. Twitter aside (you’re always going to have an edge case), most web services will never reach the performance limitations AppEngine aims to solve. It’s tempting to imagine hundreds of thousands of people flooding your new service only days after it launches, but that’s probably not going to happen.

And finally we reach the practical. Premature optimization is an evil, evil scourge that can kill a project before it gains traction. Designing an infinitely scalable system from the very beginning is hard–really hard–which is why Google continues its hiring rampage despite the fact that it already employs thousands of engineers. Even with such a substantial platform like AppEngine to build on, porting an existing application takes months or years, as evidenced by the time it took to integrate MeasureMap’s concepts (acquired Feb 2006) to Google Analytics (updated May 2007). Not surprisingly, many of these ports lead to brick walls. Just ask Dennis Crowley, whose presence-aware Dodgeball site languished under Google’s technical complexity. Now presence-aware web apps are all the rage and Dodgeball is left out in the cold.

AppEngine is billed as easy and liberating for developers. Worry about your code and Google will handle the rest. While that isn’t a lie, it’s a red herring. The lack of a relational database makes sorting result sets hard, and simple operations like MySQL’s AVG() are impossible without some kind of indexing layer in between. That’s just one example of how AppEngine simply replaces one problem with another.

In the context of creating a new web service, scaling is one of the last things to worry about. Gathering an audience is a much harder problem to solve, and building it doesn’t mean they will come. Thinking big is what entrepreneurs are hardwired to do, but making it a development mantra is resource intensive and borders on suicide.

The Outcome

There are only two possible outcomes for AppEngine. Either Google (or a middleman) will release new tools that model many of the features of traditional development environments (relational data modeling, caching, process scheduling, etc), or thousands of developers will embrace the platform, only to discover lust for premature optimization as a crippling blow to their projects’ success.

Considering that Google love is in such abundance, the former is the most likely scenario. Once again Google proves its brilliance by analyzing the market and designing a strategy which plays to all its strengths and sidelines all other concerns.

And there you have it, a strategic recipe for success. If you’re not already following the same approach, why not?

Posted on Apr 20.08 to Strategy   

Registration for Joel Spolsky’s Business of Software Conference is now open for registration. Joel has a lot of interesting things to say about developing software, and the rest of the cast is an all-star lineup. I’m not big on conferences, but this is definitely one I’m looking forward to attending.

It’s ironic, however, that Richard Stallman–the inventor of the free software movement–is speaking at a business conference. But hey, $0.00 is the future of business, right?

Read more at Joel’s blog post.

Posted on Apr 14.08 to Random Or Close To It   

My dad called recently with a pressing question that he’d been wondering about for a while. Bracing myself for something much more serious, the simplicity of his request was a surprise: he was curious what it meant when someone said they were going to “Google” something.

There were two ways which I could describe this to him:

1. Going to google.com in your browser, typing in a search term, and looking through the results.

2. Just like “xeroxing” is a nickname for making a copy of something, “googling” is a nickname for searching the internet.

The first approach describes the actual process, but doesn’t give it any context. The second uses an analogy of company as verb from his own generation. If it wasn’t already obvious, it was the second explanation he understood best (I described that one to him first, then proceeded to go into the details of the process–at which point I lost him).

Get in the habit of customizing your message for different audiences. To communicate successfully, you have to think how they think, talk how they talk.

Posted on Apr 14.08 to Analogous   

Every project needs a clearly defined goal. Without one, you’re flying blind.

Hmm, that analogy doesn’t work. How about “Without one, you’re not sure which airport you’re flying to”. Ugh. That analogy still sucks, but bear with me, because if you decide to land at a different airport mid-flight you might not have enough fuel to get there.

In engineering we’re pretty strict about forcing our users to define their goals. What do you want me to build–and why? We call them specs or RFPs or blueprints or wireframes. Clients hate them, but we love them.

Unfortunately, you can be extremely talented at eliciting other people to be really crisp about what they want, but it doesn’t necessarily translate into a personal habit.

Right out of high school I decided to start my own freelance consulting company. A budding young entrepreneur, I knew that studying business was a smart way to level up. I read over and over that goal planning was a key part of business development: what’s your 3 month plan, your 6 month plan, your 2 year plan?

That seemed ridiculous to me. How could I possibly know where I would be in 3 months, much less 2 years? I was an impressionable young lad, however, and I decided to give it a shot. What I learned is that the value is in the exercise itself, not the accuracy of your plan. Forcing yourself to be conscious of your career (and not just your product/service) is crucial to being a successful marketer.

I’ve written about goals before–on a blog that hasn’t been updated in at least two years. I haven’t fulfilled any of the goals I outlined back then, but that’s ok. I’d argue that I’m much further along in my career than I anticipated–although I’ve traveled along a different path. I’d also argue that my success (this is an internal metric, I’m not trying to brag or argue here) is because of, not in spite of, the planning I did back then.

“I’ll wait and see, because things might change” is a poor excuse for not having a plan. As an engineer, it’s all too easy to get wrapped up in the details. After all, that’s your job. But every now and then it’s important to put on your favorite tunic, pretend you’re a Zen Master, and develop an Awareness beyond the Right Now.

So, what exactly is it that you want to accomplish?

What will it take to get there?

How do you get started?

Oh, and if you had multiple answers to the first question, you’re lucky enough to have a fourth one: Will working on all of these goals simultaneously distract you?

The answers aren’t always obvious. But like I said, it’s the exercise that counts.

Posted on Apr 10.08 to Careers   

Bzzzzzzz.

Your alarm goes off, but you hit the snooze. It keeps buzzing though, and you curse your aunt for buying you that stupid all in one foot massager/alarm clock from Sharper Image (yeah, I wasn’t aware that they were still in business either….).

But wait a minute, it’s not your alarm clock! It’s your cell phone, and there’s an emergency at the office. You quickly throw on a pair of pants (no undies though, it’s been “laundry day” for at least 2.5 weeks) and your favorite Threadless tee. Jumping in the car, you quickly consider the options and decide that yes, the extra 3.8 minutes it takes to stop by that brand new Starbucks drive-through (it’s just so convenient) on the way to the office will pay for itself. Hey, if Barry Bonds can get away with juicing up, so can you. Good thing caffeine is legal or you’d be in big trouble mister.

Arriving at corporate headquarters, you hit the power buttons on all four monitors (because programmers love big screens). HAL boots up, and you start investigating right away. Your server farm figured it was a good idea to upgrade itself to the latest version of its search indexing software, but it didn’t compile correctly. Ouch. Now thousands of customers can’t search your web site, and the natives are getting restless. You consider updating your company’s blog to let everyone know you’re working on the problem, but decide it’s probably faster to just get the thing compiled.

Quit what you’re doing right now, because you just made a huge mistake. You made a decision involving customers, but you didn’t approach it like a marketer. There’s a surprise waiting for you here–Afterthought Myth #3: marketing isn’t only about how you treat new customers, but existing ones too–and you’re ignoring it. Sure, it might only take you 5 minutes to roll back to the previous version of your search application, but it might take you 5 hours or 5 days. Like so many engineering problems, you just don’t know how long it’ll take until you’re done.

Here’s another shocker: how long it takes to fix doesn’t matter, and you need to spend 2 minutes to update that blog anyway. Being transparent about a problem you’re facing, and the steps you’re taking to solve it, are your heaviest artillery in fending off irate customers who can’t believe you would have the guts to purposely break your search engine on a Monday morning at 6am.

I know and you know and you know that I know that you didn’t break the search engine on purpose; it just happened. But that’s not how your customers see it, and until you inform them otherwise, they’re going to form all sorts of conspiracy theories (at least half of which involve Bill O’Reilly or Karl Rove) about why it just isn’t working. It’s not their fault–you’re just not giving them enough data.

Now that you’ve updated the blog (right?!?), you can get back to fixing the bug. Sure, you’ve just broadcasted to the world that you screwed up and broke something, but is showing your human side really a bad thing?

Oh, and if you thought you could get around the problem by blaming the search engine or your server farm or some other inanimate object, quit reading right now because you just missed the entire point of this post.

Ugh. Wait, hold on a second. Since I’m such a nice guy, and since you have such a thick skull, I’ll try one more time to explain this to you:

Mistakes happen. Act human. Confess right away. Fix the problem. Rinse and repeat.

You don’t have to thank me for the advice. You can, however, thank me for the hours you’ll save doing damage control after the fact–since keeping your customers in the loop helped them realize that a) mistakes do happen, b) you’re a human being who is actively working hard to fix it, and c) you weren’t deliberately trying to destroy their entire day in the process. But then you have to mean it.

Cool?

Posted on Apr 10.08 to Myths   

I just had an IM conversation about career paths with a good friend. He excitedly told me about new opportunities to work on two great projects. Problem is, he can’t pursue both simultaneously.

Believe it or not, this is less of a problem than he thinks. One concept foreign to many engineering projects is leverage. If someone tells you to build something a certain way, you usually don’t have a choice. In the business world, however, leverage is a vital part of every negotiation. Leverage is the equivalent of “compound interest” in the finance world. It’s what takes you from linear to exponential growth.

In the context of career planning, the fact that he has more than one option gives him leverage to go exponential. Don’t worry, I’m about to explain what that means.

Most job offers are made based on what the applicant is currently worth. But if you’re serious about your career, you should always aim to level up when switching from one job to the next.

leveling up [lev-uh-ling uhp] -verb: Engaging in a new activity that requires crossing the boundaries of your experience.

Finding an employer (or customer) who believes in your abilities enough to want to help you to level up is important. Luckily, with the right preparation, it’s not impossible.The differences between a job and a career are dedication and planning, and the only way an employer will let you level up is if you can fully demonstrate that you’re capable of growing into a new role.

So what does all this have to do with leverage? Much, young jedi. Leverage is that extra firepower you need–aside from confidence and dedication–to level up. In the case of my friend, having several great opportunities boosts his confidence, which makes it all the more likely that he’ll be able to prove his worth. In marketing, perception is always worth more than reality.

Posted on Apr 06.08 to Careers   

Spring is here, and we can finally look forward to the weather warming up a bit. Speaking of which–if you haven’t done so already–it’s time to warm up to your customers, too. Detach from your masterpiece a moment (this is the hard part) and allow yourself to see what they see, feel what they feel (this is the easy part).

Forget for an instant that there’s a very good reason why your plasma gun runs on AA batteries (no proprietary parts! easy to replace!) and ask yourself if someone who had no prior knowledge of your product or who had no experience with a plasma gun at all would get why that’s important.

If most people who use your plasma gun like the AA batteries then you might just have a messaging problem. If the majority your customers complain, or if you in fact have no customers at all, well wake up, because running a plasma gun on Energizers is not going to work buddy.

There are two important caveats here.

First, true innovation happens way ahead of the market–usually measured in years. If you wholeheartedly believe that you fall into this category (a risky assumption), your strategy better include plenty of time to wait it out. And when it finally does catch up, remember that it’s not necessarily a bad thing so long as it legitimizes your idea.

Second, companies don’t become successful until they find a problem worth solving. Often, the problem they end up solving is different from the one they first believed in, which makes it a common reason–or excuse–for anyone who wants to abandon something that’s not working. This is risky, too, because abandoning a great idea before it gains traction is tantalizingly easy compared to seeing it through.

The hardest part is remembering to apply this test to every aspect of your business, every day. What’s right today may not be right tomorrow.

Posted on Mar 31.08 to Emotion   

In my introductory post I talked about Grandma. Today I want to talk about Mom, and why it’s important that she understands what you’re building.

If you’re like most engineers (ok, I’m not being scientific here–definitely at least me, but it could apply to you too so pay attention), you spend your entire life in quiet frustration and embarrassment that your family has absolutely no idea what you do for a living. Year after year you explain it to Mom over a holiday dinner, and watch as her eyes glaze over while you illustrate the finer points of forging a widget. You explain how the metal has to be just the right temperature before molding it into shape, or else the structure will be prone to fracture. Then you watch her fake a phone call, or turn on the TV, or get up from the sofa, rudely interrupting your train of thought while patting her stomach and saying, “I’m staaarrrving. I’m gonna check if the turkey’s ready yet. I’m sorry honey, I’ll be right back.”

You and I both know she’s not coming back. It’s not something we talk about, but it’s real. And depressing.

I can’t help solve your depression, but I can make a larger point about how Mom is really just a microcosm of the rest of the world. Before I do that, though, you need to get over it; it’s not that she doesn’t care what you do. The moment you realize that this is your fault, not hers, the better off you’ll be. And guess what, this goes for your potential customers too.

Instead of talking about how and why your solution works (aka your problems), maybe you should talk about her problems. Explain how your widget washes her windows for her using perfect strokes, so never again will she scream and throw another wine glass across the room because no matter how hard she scrubs, the “streak-less” cleaning fluid still leaves evidence of her gigantic paws on the windows. Or explain how using your widget could help sell her house just a little bit faster. Wow. And instantly she gets it. Then she’s on the phone with her friend friend Sally who owns a seashell factory and needs a widget too.

Sure, it’s not always that easy. I guess what I’m trying to say though leads me to Afterthought Myth #2: Your problems are not their problems. Often it’s not about explaining how your solution works, but about how it can make an impact on someone’s daily life. Keep that in mind when you start geeking out over features (it’s got a dual channel mode! it glows in the dark!). At the end of the day it’s about them, not you.

Posted on Mar 29.08 to Myths   

Go ahead, blame Kevin Costner. No, not because Fields of Dreams was such a kitschy movie, but because it instilled upon us engineers what I hereby dub Afterthought Myth #1: If you build it, they will come.

It’s easy to imagine that if you build the shiniest gizmo using the hippest tools and the trendiest designs, that users (argh, I mean customers) will flock your way. It’s easy to imagine that if you just get the algorithm right, or if your use^H^H^Hcustomers can get where they need to go in two screens instead of six, that you will have won. But alas, my young padawan, it’s just not so.

Marketing isn’t an afterthought that you tack on once your product is complete. You don’t have that luxury. It’s got to be baked right in, just like the chocolate chips in your grandma’s homemade cookies. If it helps, picture the scorn in her eyes when she catches you pulling the cookies out of the oven and frantically trying to dump chocolate morsels on top so they melt before the cookies cool down. What do you mean you forgot to add them before the pan went into the oven? You were raised better than that. Tsk tsk.

Now go forth and market thyself. Grandma’s watching.

Posted on Mar 28.08 to Myths