The Bell rep, was telling his friend about some new Blackberries coming out that were supposedly “just like the iPhone, only…” – don’t even get me started on that one. But he told his friend the code names of the 2 phones: Barcelona, and Black Forest (I think).

I got to thinking about product code names. Coming up through the ranks as an engineer early in my career, I thought product code names were cool. There was a mystique about them. After spending some years now on the business development, sales & marketing side of the business, I’ve completely changed my opinion.

When I hear a company talk about product code names now, I see it as a symptom of a disease that company is inflicted with. I can just picture how that company works… Development has begun building a product based on some set of specs (that they probably came up with themselves), and the company doesn’t even know what they’re going to call it yet. But worse, probably hasn’t answered any of these other fundamental questions internally:

1. Who the audience is
2. What the need/pain/messaging is
3. How much it costs or what the price plans/options are
4. What the sales/marketing strategy is for the product

I can just picture engineering finishing this product, then throwing it “over the wall” for Marketing to figure out what to call their new baby, who should care, and how they’re going to sell it.

This is ass backwards. This is an engineering driven company, not a marketing driven company. And engineering driven companies have a tendency to fail. Sure, some of the big, old guard can get away with it for a while (I’m looking at you Microsoft, and you RIM), but not forever. And if you’re not as big as they are, God forbid you’re trying to build a startup, it’s the beginning of the end.

You need to be a market driven company. When you conceive a new product, engineering should be the last part. You should know your pain, concept, messaging, audience, go-to-market strategy and yes, product name, before you build the thing. Otherwise, how do you even know if there’s a real opportunity? Pretty big gamble to just build something for months on end, only to toss it into the public’s hands and hope somebody cares.

To make matters worse for all of you who haven’t answered all those marketing questions yet, I can tell you that during any dev cycle, your engineering team is going to make, oh, about a million product decisions without you, that relate to the details of the product along the way. If they don’t know who their audience is, what segment you’re going after, what the pain they’re solving is, whether it’s consumer or enterprise, what the pricing is, or what the damn thing is even called – what do you think the quality of those million decisions are going to be?

Don’t be an engineering driven company. Be a marketing driven company. Don’t use product code names. Answer those key questions before you start building. At least have a working hypothesis.

Otherwise you’re doing backwards.

I believe that market share is just not very relevant to anything these days in most product categories. Tech, being a monster set of markets, can often set the standard for what people look at as indicators of the success of a business. How we measure tech companies, we in business, often measure other companies. And for a time, market share was the thing that could make or break a tech company. But that was in the 80′s. Let me explain before you close your ears and go ‘la la la la’ There’s a method to my madness here.

Back in the day, there was something web historians now refer to as the PC wars. This was long before even the browser wars. It was Microsoft against the world. Windows was fighting to establish itself as the dominant platform. Any hardware or software vendor had to choose up front whether they would build for Microsoft, IBM or Sun. Because once you made your choice, you’d be incompatible with the others. So the obvious data point to look at was market share. Which of the 30/40/20/10 market share owners do I want to bet on?

That was when compatibility was the big battle ground that these wars were being fought on. Most of the hardware and software could only play nice with one ecosystem, then you’d be locked out of the others. So market share was king! Who wants to build products for the poor ecosystem that only has 10% market share? No one! And so you get squeezed out of existence. If you were lucky enough to get 70% in a market though, you won. Because that 70% was enough to make those other decisions of which ecosystem to choose, a no brainer. If you got 70%, you’d get 100%.

But then came standards. Hardware standards. Software standards. Web standards. Cell phone standards. Compatibility is no longer that big of an issue. We’ve moved past it. Products from any ecosystem, Macs, PCs, Android Phones, iPhones, Linux Servers… they all play nice together. So what does that mean? Consumers don’t need to (and shouldn’t) look at market share any more. Because whatever products they choose, for whatever reasons, are going to play nice everywhere. We are finally free to choose the products that suit us best, without the fear of not being compatible with the products that our friends and colleagues choose. It’s awesome.

The compatibility issue is solved. And yet tech journalists continue to hold market share as some sort of beacon of success – or the name of the game. Even when in one particular market, smart phones for example, one player who came out with the least market share, gobbled up 50% of that market’s profits. The journalists still prattle on about market share.

When did market share become more important than the financial health and success of your business overall? Isn’t building amazing products, making your customers happy, and taking home ridiculous profits much better than market share for the sake of market share? Apparently tech journalists don’t think so. Neither do some investors. How the financial markets focus on market share as the bell weather for the success of a company blows my mind. It also signals a naiveté for the fundamentals of business. It tells only such a small portion of the larger story.

If you’re an entrepreneur building a business, forget market share. Worrying about how you’re going to ‘dominate the market’ is going to lead you off into the weeds, focus you on a feature race with the other players in your market, and commoditize you real fast. It’s going to take your eye off all of the challenges of TODAY that you need to be worrying about to survive and grow. Like deepening your relationship with your customers. Focusing on making their experience with your business and your products as delightful as it can be. This is what builds loyalty, and grows your business.

Any business person who does not stand in awe of what they’ve done, largely under Steve’s unique inspired benevolent dictatorship, I believe will never amount to greatness. Because whether or not you’re a fan of Apple is irrelevant. The results speak for themselves. Anyone who doesn’t give them credit for that greatness (now the most valuable company on the planet), apparently wouldn’t recognize greatness if it was kicking them in the ass – which it is.

I believe that love’im or hate’im, Steve “got things” in a profound way that most people don’t understand. I truly believe that due to Apple’s success, our industry will be internalizing the lessons he and Apple have taught us, for the coming 10 years. It won’t happen overnight, but I hope we have all been paying attention and taking notes. The coming era of tech is more human focused, less gigahertz focused.

And with the spotlight, comes the criticism. “Blah blah, Steve, blah blah, Apple, blah blah, not so great.” I believe that until you yourself have repeatedly delivered products to market that make thousands of people line up for days in advance to be the first to get their hands on what you’ve created – then who are you to criticize? It should be every business person’s ultimate measure of success, to achieve those kinds of results. Apple fan boys you call us? What have you done that’s so great as to create such a loyal, passionate following? -crickets-

Many of my own values and ideals in building tech companies and leading people, I realize in hindsight, have been hugely influenced by Steve. The almost dysfunctional and obsessive focus on user experience first. The relentless pursuit of always raising the bar. The refusal to accept “good enough”. The refusal to accept “compromise” (i.e. corner-cutting). Which other titan of tech will I look up to now? Hmm. I guess I’ll have to be my own.

I say Steve and not Apple, because for those of us old enough to remember, Apple without Steve fell to pieces the first time around. I believe it will remain 75% of the company that it is today, going forward without him at the helm. I believe little cracks will surface without him watching over, but hopefully the company has now embodied those values as to be able to carry them forward for the most part in his absence.

Steve was the lead singer of the band. Sure, they’re all great musicians, but it’ll be a noticeably different band going forward.

Like a great magician, Steve is leaving the stage before the rest of us have truly figured out how he did it.

So often in the software biz, we the engineers, get tempted to lay down the ground work for something we think may happen in the future. Whether it be optimizing for performance and scale (because OBVIOUSLY everyone will LOVE our product and we will be SWAMPED with traffic), or for some future feature we think we may want down the road – after all, we can always THINK of new features much faster than we can BUILD them. If we ‘just’ do a little now, it will save us re-work later. This seems pretty logical when you look at the development cost factor in isolation. It seems like a pretty good tradeoff to spend 1 week doing something now, that will save us 4 weeks of ripping it out for something better later, right? Not so fast bucko.

What this strategy fails to consider is that in the software business, the total cost of engineering of a product is relatively cheap. For the cost of a developer for 1 year, you can build something that theoretically generates millions in revenue. So wasting 3 weeks of developer cost (re-engineering later on) in that case is negligible. However, in almost all cases, elapsed time is incredibly expensive. You’re ALWAYS racing against the clock to get that product (or feature) out the door. You’re racing your competition, you’re racing against your business plan, you’re racing against cash flow and you’re racing to keep up with customer requests. Anything you can do to get that feature or product out the door faster, serves to accelerate and increase revenue (for the period).

I read this great quote. I’m afraid I can’t remember who said it:

“Startups don’t die because they couldn’t scale – they die because they didn’t have enough customers”

Brilliant. It’s easy to forget that if you focus on getting the right product/feature into customers’ hands FAST, they’ll give you lots of money that you can then use to solve the scaling and performance problems later. They’ll give you so much money that pulling out old temporary architectures and replacing them with new high performance ones will be a pleasure. But, if you give them something they don’t like, or deliver too late (after they’ve moved on to something else), even if it scales ridiculously well and includes a whole bunch of groundwork for future features, then… NO MONEY FOR YOU!

This is increasingly true as we all become more agile and responsive to our markets – stopping on a dime and heading off in another direction. Whatever we think we know today, about what features are on our roadmap, we’ll only ever know MORE tomorrow, not less. So… it stands to reason that if we can make less architectural decisions in advance, we save them for a day when we know more – and have more money. Since knowledge, experience and cash are presumably only ever increasing, not the other way around.

The primary challenge for a startup is achieving product/market fit. This is done by engaging with your customers, pumping out features that match their requests, trial and error and ‘finding your way’ as you go. This is a bad time to be committing to long term technology investments. Otherwise you’ll likely die before you ever get to benefit from them. Performance optimization, engineering time optimization, long term product road maps – these are the challenges of a larger company with an established revenue stream, who’s biggest worry is squeezing margins. Solve those problems then. Until then, just get your work into your customers’ hands ASAP and prove that they’ll actually buy it first. Even if you have to rip it out and re-do some of it later. At least you’ll have a customer base paying you to do it.

When we think of competition in a marketplace, most good little free-market capitalists (like myself) would say that it’s a good thing.

And while you’d never catch me saying that competition ISN’T a good thing, lately I’ve been noticing different kinds of competition – some good, some bad.

In the early days of a market’s development, you mostly see what I would call “innovator competition”. This is where the focus of all the companies in the market is differentiation. They’re all looking to create some uniqueness to their brand and give you some reason to choose them. It’s a bit of a land grab and each company is trying to plant it’s flag. This is the most exciting time for product design because here is where we see the most variety and creativity. It’s the glory days. This is the kind of competition people think of when you take about competition in the marketplace. It’s all about the great variety products and approaches.

It bums me out when I see another increasingly common kind of competition: “zombie competition”. It comes at a later stage in market development, around the time commoditization starts. Instead of companies striving to innovate and differentiate, they run around like mindless zombies copying each other. Their strategy turns from “give customers a reason to choose us” to “take away any reason for customers NOT to choose us.” It’s defensive playing instead of offensive playing. At this point, it’s not a capability/benefit message any more, it’s all about the spec sheet. “They’ve got a fast processor? WE’VE got a fast processor. THEY’VE got 4GB of RAM? WE’VE got 4GB of RAM.” Markets at this stage of the game have mature, established products and customer expectations. Brand equity and recognition have been built up to the point where companies don’t actually need to provide quality products or services anymore. It’s all about the brand-name now. Customers will choose them despite having crappy products. Markets in this stage include: PC manufacturing and most consumer electronics (TVs for example, with the exception of 3D, the only real innovation in some time).

Here’s why I hate zombie competition so much: I believe it destroys markets. Whoa, that’s harsh, eh? Take the PC industry. NO-ONE is innovating anymore. Manufacturers are just running around copying each other’s spec sheets. They’re all the same. It’s not the lack of variety that bothers me. It’s that once the homogenization happens, and brands can’t compete on capabilities, guess what they compete on? PRICE. This is the beginning of the end. Once they’ve played their last card and have nothing left to go on but price, margins get squeezed as there’s always someone else willing to offer their copy of your product at $1 cheaper. Once margins really get squeezed, product quality and service go into the toilet. There’s an expression, “A rising tide floats all boats.” – this happens in a new market as the hype cycle puts it in the spotlight. Unfortunately, zombie competition sinks all boats. It drags everyone down to the lowest common denominator.

I have a lot of respect for companies that resist zombie competition by forging their own path, ignoring the competition, maintaining their margins through their product quality and innovation, and not following everyone in the race to the bottom.

“Developers in Pain”

The ideas behind Devshop:

I would be interested in putting the source up on GitHub as an open source project. If there’s someone out there who’s run an open source project before that would be interested in taking the reins and has a bit of a vision for what they’d like to do with the product, please feel free to email me: craig@devshop.com

The scariest part of the article is the position of the Outlook Product Manager:

Having multiple HTML engines could reduce performance, as well as create an inconsistency in terms of what type of content the user is able to create vs. consume.

Microsoft is using the Word rendering engine so emails composed in Outlook will look consistent when viewed by other Outlook users.

In other words, more walled garden thinking. The old Microsoft is back at it again. I mean, um, the whole world uses Outlook right? Cough.

MS claims they’re listening. Outlook 2010 is still in Beta for another year so there’s time to raise a little hell. See if we can smack some sense into them. This is a ridiculous step backwards.

There’s a Twitter campaign here:

www.fixoutlook.org

Like most things in life, whether it’s “good” or “bad” depends on context. So…

Here’s some context.

I’ve heard of people deciding to split A/B test little tweaks to their designs, that someone has a hunch will make a positive difference, but where there’s been some internal debate about it, or the champion hasn’t been able to articulate their hunch and therefore hasn’t swayed their colleagues. In these cases, someone often exclaims, “Let’s A/B test it!” Well, ok. The good thing about A/B testing is that it’s democratic. May the most popular design win (as judged by end-users successfully completing their tasks with the design). Hard to argue with that, right?

In other situations, I’ve heard teams decide to A/B test whole modules or whole features of applications. This tends to come from more agile oriented shops who are often more reactive about design than pro-active. I say this not as a jab, but as an observation. Less decisions up front, more “figure it out as we go.” This is a complimentary style to A/B testing, in a Darwinian sort of way. Trouble with using A/B testing on larger chunks of designs, is there’s a point where it starts costing way too much. This is a similar optimization problem to How much unit testing is too much unit testing? To A/B test something implies you have both to test, PLUS you have some mechanism to randomly shuffle the 2 across users. So, you eat the cost of developing both and some switching mechanism so you can do your empirical observation.

The fundamental danger of relying too much on unit testing as opposed to the alternative (which is a dictator-like designer calling the shots based on their own skills and experience of the space), is that a good designer should have accumulated enough flight time to have internalized the knowledge that A/B testing often delivers, at least at a higher level. So, if used at a macro level (larger chunks of the design), it can be very costly. Also, the larger a chunk you’re testing, the more moving parts there are, the more likely that other influencing factors will creep in to the test and blur the findings.

That said, here’s my take. A/B testing is best used to optimize a design that was put together by a good designer. It’s about taking an existing design and either uncovering design errors, or optimizing it to squeeze every last drop of effect out of it (i.e. what happens if we move the purchase button closer to the screen shot tour?). It’s for things like testing wording, layouts, aesthetics, proximity, etc. It’s by no means a substitute for a strong designer making an executive decision.

The other major use for it I see is to de-risk a cut-over from an existing design to a re-think. If you’re worried about the switching drama (“Gah! Where’d my favorite button go?!!!”), it’s an alternative to having a separate Beta program where a sub-set of your users get to react to it first before you force it down everyone’s throats.

For the alternative version of this post, click here. Just kidding

We’ve all participated in debates about form follows function and vice versa. I have never heard such a well reasoned and scientific (i.e. observed, measurable & repeatable) perspective on the subject before.

This is a must-read for anyone embarking on a new UI design or a re-design of an existing product. Heck, those thinking about branding should read it too (after all, UI design and branding are as joined at the hip as form and function).

Here’s a snippet to wet your appetite:

By making intentional, conscious decisions about the personality of your product, you can shape positive or negative responses. Take a look at Sony and how they applied this knowledge in the Sony AIBO. Let’s consider why they made this robot resemble a puppy.

Here, you have a robotic device that isn’t perfect. It won’t understand most of what you say. It may or may not follow the commands it does understand. And it doesn’t really do all that much.

If this robot was an adult butler that responded to only half our requests and frequently did something other than what we asked, we’d consider it broken and useless. But as a puppy, we find its behaviors “cute.” Puppies aren’t known for following directions. And when the robot puppy does succeed, we are delighted. “Look, it rolled over!” What a great way to enter the robotics market.

Here’s the link again:

In Defense of Eye Candy