ARMed for a Takeover

If I was Intel I would be worried. The hegemony of the Wintel empire is facing a threat like none before. And that threat is from ARM. ARM is not a multinational criminal organization (cue the James Bond music). It’s a processor. Actually it’s a processor core architecture used in a host of processors with a pedigree that goes back to 1983.
ARM processors are subversive. They have been used in small, low power devices forever. They lie under the radar of general purpose computing. ARM is found in the stuff that you don’t think of as computers such as mobile phones, network switches, game consoles, and GPS systems. These little devils are the processor of choice for smartphones everywhere. Android was designed for it. It lives in the Apple iPad. There might even be one in your Blu Ray video player. ARM is everywhere.
It’s only a matter of time before ARM sneaks into the Empire of Intel, snatching away bits of key real estate. We saw that with the first Netbooks. Why? How could this happen? Power! It’s all about power. ARM cores provide that almost mystical combination of processing power and low energy use. Just look at the iPad. Inside is an Apple A4 based on four ARM cores. It gives the device all the power it needs while allowing it to claim a battery life of 10 hours while using WI-FI. Sure, that longevity is not only because of the ARM processor but it certainly is a key factor.
None of this would matter if it weren’t for the fact that mobile devices are taking over. I don’t expect servers or desktops or even laptops to go away anytime soon. There are times you need more raw computing power. But much of the time you don’t. For most home uses, a low-end, Internet enabled device that moves around with you is just fine. Truth be told, a lot of business users would gladly ditch the expensive and heavy laptop in favor of something small and light but long on battery life. The movement to cloud computing makes this even more appealing.
So where does this leave Intel? In mortal danger. Intel finds themselves, for the first time in  ages, with an entrenched enemy on it’s doorstep. They are in the position of having to displace a competitor instead of having someone trying to eat their scraps. In the past, they could rely on revenue in all high growth segments, be they servers, desktop, or laptops. Not now. ARM has infiltrated core Intel markets as mobile computing devices supplant laptops and low-end computers.
For those of us used to the seismic shifts in the computer industry, the ARM ascendance is a bit surprising.  We notice the Googles and Microsofts, the Oracles and Apples more. Companies that burst on the scene with all the subtlety of a Mongol invasion. The fifth column tactics of the ARM processor was not as noticeable. That’s why it’s so dangerous to Intel. ARM may have taken their market from within, quietly. It’s much harder to fight a threat that sneaks up on you.
Intel will certainly fight back. They have the technology, size, and money to fight a protracted war. The strategy has to be different from what they are used to. They are the underdog now. Given that, Intel needs to be more aggressive and less complacent. My advice to Intel is “shock and awe”. Buy and build whatever is necessary to crush ARM before it is too late. Or, one morning, all the residents of the Empire of Intel will awake to find ARM processors everywhere and themselves friendless and forlorn.
The enemy is at the gates! To arms! Oh wait. Wrong rallying cry.

Whereby I Commit Heresy

It is axiomatic that when you develop a product you listen to your customers. Throughout the development process, even before product conceptualization, you are talking to customers. You get their opinions, wants, desires, and hopefully needs. Most Product Requirements include something about the “Voice of the Customer”.

Although listening to customers is a good thing, if it is adhered to too strictly it can really screw up product development. That’s right, listening to customers can mess up your products. Heresy! See, I delivered on my promise.

Here’s how customers can tank your product.

Customers don’t know always know what they need. They more likely know what they want but not always what they need. When gathering data, customers will talk to you about features and technology but not business. Take servers. We keep making faster servers whose CPUs are mostly underutilized. One of the reasons that server virtualization has taken off is because server manufacturers built in too much capacity. They did that because their customers told them too. What customers needed was better application performance. They just assumed that meant a faster processor or more memory. Talking to customers about problems and behaviors yields a better response. It’s just harder to do.

Which brings us to the next problem – customers answer the question you ask of them. Asked if you want a faster server who won’t say yes. A lot of companies don’t dig in deep to find out what they plan to do with that extra performance. If you asked what is the biggest issue they have with applications and infrastructure you will likely get a different answer. Worse yet, sales and marketing people tend to introduce features into the conversation that customers never even thought about. How many times has someone suggested a feature to a customer, had the customer said they liked it, but then the same customer wouldn't buy it. It happens all the time.

Even if you understand what someone needs, that doesn’t mean they can pay for it. Years ago, when I was a product line manager, I was told repeatedly that my product line needed SGI drivers (it was that long ago). There were lots of customers who wanted it, need it even. When we queried those same customers as to how much they were willing to pay for those drivers, we got a different answer. To have listened to the “voice of the customer” would have committed us to an expensive development, test, and service effort for something that no one would pay for.

The biggest problem is dealing with conflicting needs. Unless you have an incredibly homogenous customerbase you will not find a clear picture of what everyone needs. Instead, you will get a fragmented view based on competing needs. How do you resolve these conflicts? Who do you listen to more? How do you make room for innovation? To put it simply, you can’t be all things to all people so compromises will have to be made. That can be difficult especially if you are just chasing features.

Here is where you see the effects of big customers. Big consumers of your products tend to dictate that their needs come first. Wal-Mart is famous for this in consumer goods as are large banks for IT. The problem is that they are not all of your customers and may not be where your growth is. By catering to a few powerful customers, you risk alienating other customers and making it difficult to break into other markets. You might also spend a lot of resources on features with narrow appeal. Even worse, large institutions tend to be conservative. Given too much credence they can stall innovation in your products leading to slow death for the company.

The overwhelming problem with listening to customers is that it isn’t enough. You have to understand their business and industry. Only then will you have enough context to figure out what they really need and what they are likely to need in the future. A great product anticipates future needs instead of simply meeting current known ones.

So listen to your customers. Just not too much.

The Great Untruths

There is a difference between a lie and an untruth. Neither is true but a lie is intentional. So, when I say that something is an untruth instead of a lie I am making a value judgment. The assumption is that someone did not tell the truth but didn’t know that it was not true. Instead, they were ignorant, got too excited/upset/scared or are parroting back what might be another untruth or lie.

A lot of products fail (and some fail dramatically) because of untruths. If an untruth slips in during a crucial phase of development a very bad decision will be made and bad product will emerge.

Here’s some of my favorites.

Everyone Wants This!

You hear this from sales and marketing people a lot. Someone comes back from a trade show or customer visits and hears about a feature that “everyone” wants. There are a couple of untruths rolled into one here.

First off, who is everyone? I can’t tell you how many times it turns out that “everyone” is one person. After hearing it one time, the sales and marketing team feels compelled to ask others about it. They usually get a “Sure. That sounds good” type response. It’s really a sample size of one with all other responses coming from a poisoned well.

More importantly, people often want a great many things that they aren’t willing to pay for. There is a difference between wanting something and needing it enough to turn over money out of a limited budget. This is why there are a lot more Ford Focuses on the road than Lamborghinis. Everyone wants a Lamborghinis, just not enough to pay for it.

Finally, customers don’t often know what they want or even need. Instead, they have problems that need solving. Asking a customer “Do you need this feature?” will get you to the untruth. Asking “What do you need to accomplish your goals” will get you to what they really need to do and might be willing to spend money on.

We Can Do That Too (Version 1)

Someone (Sales, Marketing, a customer perhaps) comes to the development team with a request in the middle of a project. This is commonly called scope creep. We’ve all seen it because it happens all the time. Sometimes, it’s no big deal. Other times it kills products. You can’t just add things without ramifications.

Scope creep kills products in two ways. One, it loads products up with a ton of features that make it bloated. In the end, by trying to please everyone you please no one. You also trash your margins.

Often when faced with these requests Engineering will say “Yes! We can add that.” This is an untruth. Technical folks are, by nature, builders, makers, and fixers. It’s in the DNA. Pride comes from the ability to create something that people will say “Awesome!” to. The last thing they want to say is “We can’t do that.” So they say yes but neglect to mention that they lack the resources or even the expertise to accomplish it. Look out for the techie that says “No problem. We can do that” without first doing some analysis. You will not find out until much later that they are trying to figure out how to do something that they simply cannot do.

We Can Do That Too (Version 2)

Another flavor of “We Can Do That Too” untruth is timeline reboot. Like the new Star Trek movie. If the technical team knows that they have the expertise and resources they will instantly say yes to a new request. Wonderful! However, what they don’t tell you is that they don’t have the time. You find that out when you sit down to review a project and realize that the technical team just assumed that the timelines were extended. The real request is “Can we add this without changing the timeline?” The untruth is saying yes to that knowing that is what is meant.

I can already hear the response – good project management will head this off at the pass. That assumes that the technical folks ever communicated the new timelines to the project manager. I can’t tell you how many times I’ve seen technical teams develop a new timeline in their heads and never mention it to anyone. Their intention was always to stick to the old timelines but when it becomes apparent they couldn’t they extended it and added a touch of collective amnesia.

Who hasn’t heard “The trade show is in two weeks?! How come no one told me that?” Of course you did but they need to save face. It’s about pride again.

We Can Fix This

About the worst thing that can happen in the middle of product development is the realization that something is terribly wrong. You hit a technical snag that was completely unexpected. Unfortunately, some problems are too big or costly to fix. But that’s not the bad part.

The great untruth is believing you can fix the unfixable. There are just some problems that are insurmountable and this is when you shut down the project. A lot of technical folks don’t know when something is unfixable. The assume that with enough time they will come up with a solution. Before you know it every last drop of resource in the company is engaged in trying to find a solution to an intractable problem. The idea of cutting one’s losses is rejected, more out of pride than anything else. This is when you have to swallow your pride and stop fooling yourself. Then you can find a real solution like buying the technology from someone who has figured it out. Or perhaps dropping the feature that wasn’t going to generate much revenue anyway.

I’ve seen this happen with businesses too. Some businesses face a problem they can’t handle no matter how much time, effort, or money they put into it. They destroy all the value in the business in a quixotic quest to find a way out. Sometimes, the only way out is by the door. What’s especially bad about this situation is that opportunities to scrape something out of the business by changing direction, selling the business or divesting of some it its assets are lost. Here’s to tilting at windmills.

Everyone Else Already Has This

I always leave my favorite to the last. This is by far my favorite untruth. To justify more resources, a new feature, or an accelerated timeline someone will declare that you are behind the curve and this is a feature that everyone already has.

The truth is more likely that they have only made announcements. They might even be working on it. It is even possible that one company has an early version of it. Rarely is there a critical feature that no one anticipated that everyone but you has. Everyone does not have this feature yet. Freaking out over it will only cause you pain.

This type of hysteria can derail a development effort. It results in a lot of time and money going into an early feature that no one is ready to deal with yet. Not you and not your customers. The trade off is almost always dropping something that your customers really do need for something that is new. Listening to competitor’s press releases can be dangerous to your product health.

I want to stress again that no one does these things on purpose. Pride and fear are at the root of these untruths. They are powerful emotions. When the emotions are genuine they can make nothing seem like something. It can even be hard to ask questions about the validity of untruths. The people uttering them believe them and will feel like they are being attacked if you question their perceptions.

If you suspect an untruth here’s a tip: ask for time to look into it. Don’t make a decision right away. Ask sales or marketing to generate a revenue estimate for the new feature or a competitive analysis so that you “can be prepared for launch.” Ask the technical team for a revised project plan so that you can better plan your launch. Let them discover their own untruth and they will be less likely to react emotionally.

Whatever it takes, don’t let the untruth guide you.

Of iPads and Hamptons

Last week I was on vacation with my family in Williamsburg, Virginia. I highly recommend it if you haven't been there. We stayed at a Hampton Inn which is usually considered a budget hotel. It was a fantastic hotel. I often stay at Hampton Inns because they have everything I want and need at a great price. Big rooms, comfy beds, a decent TV with 100 channels, and a free breakfast buffet. They also have attentive and super friendly service. They always seem to be be staffed with nice and helpful people.

Hampton Inn gets my business on a regular basis for one reason – they focus on things that are important to travelers and don't bother with needless frills. A well appointed business center is more important to me than a fancy lobby that I will never sit in. By focusing on what is of real value, they keep costs low and provide a great experience.

That got me thinking about the iPad. I know it sounds weird but I think about products a lot. I love the idea of the iPad. I have doodles in my notebook from five years ago for a tablet device like it. Yet, I've found little enthusiasm for it amongst regular folk (meaning non-geeks). Even hardcore Mac people who seem to be willing to buy every little thing that Steve Jobs comes up with aren't that interested. Why?

The typical answer I get is that they don't know what it is for. Some will point to their iPhone and say “I already have one and it makes phone calls too!” or “What is it? An eBook reader? Internet device? I already have a laptop.”

The problem with the iPad is not that it can only run one application at a time. That's certainly a problem but one that Apple will eventually fix. The big problem is that it isn't solving a big problem. It doesn't focus on what is important to people. The iPhone did. Apple understood that people wanted information wherever they were. The netbook concept was also successful by providing only Internet access (pretty much) and not trying to be a full blown laptop. eBook readers such as the Kindle or Nook are addressing the needs of voracious readers. They want to be able to carry ten books on a plane and still have it fit in their carry-on bag.

The iPad, in contrast, is neither fish nor fowl. It's an Internet device but with few advantages over a laptop or netbook. It's not exactly an eBook reader. Those have special displays to making reading easier over long periods of time. Traditional displays can be tough on the eyes when reading a book (I know. I tried it). As a media player, it is rather large to haul around just to listen to tunes.

All products must pass two tests. One is the “who cares?” test. Will anyone care enough to take a look at it? Does it grab your attention in some way? The second test, a more stringent one, is the “show me the money!” test. Will someone care enough plunk down their hard earned cash to buy one?

Apple's reputation and design aesthetics will almost always pass the first test. Pretty helps. Cool gizmo features like the giant touch screen will also help to get people to at least take a look. The second test can only be passed by providing enough consumers enough value for the right price. As far as the iPad goes, I'm not hearing the love out there.

I like the idea of the iPad. A small, lightweight, device that surfs the Internet, let's me check email, read eBooks, listen to music, and watch video on a screen that is big enough for my old eyes to see. Others don't share my enthusiasm. Perhaps the iPad tries to do too much. It does seem to want to compete with other devices that most people already have. Or perhaps it is simple too much money for something that doesn't replace a laptop or even an eBook reader.

For a great many people, the value is simply not there. Apple, in trying to create a trend, may have missed the most important aspect of product development – give people what they really want at a reasonable price and nothing more. Here, the value/price ratio appears to be way off. I'm hoping I'm completely wrong since the death of the iPad could set the entire tablet computing segment back.

Or maybe Steve Jobs should needs to stay at a Hampton Inn from time to time.

People. People Who Need People.

If you ever saw Sesame Street then you know the tune to “Who Are The People In Your Neighborhood?” Sing with me...

So after complaining bitterly about people who kill innovation and products, I thought it made sense to talk about the people who do the opposite. The people who make innovative products happen. I'm not talking about the folks who are tasked with designing and creating new products like engineers. They can make a product but cannot make a product happen.

So, here I want to sing about the unsung heroes of the product development process. Cue the Bob and Muppets please.

The Visionary

Behind every successful product stands a visionary. The Visionary recognizes good ideas and has that irrational need to see them turned into useful products. They never lose faith even when the folks in Sales declare they could never sell it and the Finance people are totally freaking out with thoughts of bankruptcy burning in their heads.

It's not that The Visionary doesn't get the risks, they just see beyond them. They provide the energy that keeps people going in the face of setbacks and derision. Lacking The Visionary, the most innovative products die on the vine, starved for affection and direction. Without The Visionary, everyone on the product development team eventually wanders off to more acceptable projects with more predictable outcomes. In other words, incremental boring product development instead of the truly wonderful.

The Visionary provides the necessary moral support during the darkest days. Kind of a combination of mom and Yoda.

The Git-er-done Guy

Whereas The Visionary has the faith, they often don't have a clue how to make the vision occur in real life. That's where The Git-er-done Guy comes in. They can map out all the things that need to occur in order for the vision to be realized. The Git-er-done Guy makes sure everyone stays on track and actually makes the blasted product. If there is no Git-er-done Guy, product development degrades into naval gazing and staring at the stars. Nice recreation but rarely productive.

Let me put it another way – no one buys vision. Okay some VC's do but not your average consumer. The Git-er-done Guy makes sure the grand idea becomes a grand product.

The Plumber

Sooner or later, all product development runs into problems. This is especially true for the most innovative products. Often, it's the internal workings of the corporation that are clogging up the works and impeding progress. It's sad but true that there are a lot of people within a company that will not benefit from an innovative new product. It might be because it will take away resources or attention from their own products. Another likely culprit is FUD – Fear, Uncertainty, and Doubt. When a company does something it has never done before, it scares the heck out of a lot of well meaning folks. And there are the power mongers who see a new initiative as a threat to their own status and well being.

All of this negative energy has a tendency to hold up product development like a stuck drain. Enter The Plumber!

The Plumber knows how to remove obstacles. The Plumber knows the workarounds. The Plumber gleefully unclogs the corporate drain and lets the project flow normally. You can tell who The Plumber is because they are first person to say “ Let me see what I can do..” when some obstacle is holding up forward motion. They have the skills and, more importantly, the desire to roto-router the clog and get things moving again. They might only appear once during a project but boy are you glad they did.

Making products, especially the best, most innovative, and coolest products, is an act of faith. Lots of people lack that faith and actively suck the air out of the room. The Visionary, The Git-er-done Guy, and The Plumber make sure all the negative vibes (and action) don't kill or maim the wonderful and new. Find them. Foster them. Then thank them.

When People Kill Good Products

People Kill Good Products.

That's right. Good products don't get ruined by circumstances or the “market”. They get trashed by people, usually long before actual launch.

It's sad but true. I'm not talking about the obvious mistakes. The classic ones, such as a serious defect or taking too long to get to market, often become predictable. With time a company can reduce these errors and eliminate bad product caused by them.

The bigger problem is the people in an organization who seem hell bent on insuring that innovation never see the light of day. Why do they do this? I don't know. It's the kind of thing I've never been able to understand in over twenty five years of product development. I don't get them but I can identify them. It's easier to recognize behavior than to explain. Here are the most common types of product killer. They all have one thing in common – the tendency to obstruct progress and trash ideas that are not their own.

The Prove Its!

These are the folks who have to have everything validated to the nth degree (where n is a very large number). Nothing satisfies them. They come in two flavors – the Prove the Impossibles and the Prove the Unknowns. The Prove the Impossibles always seem to ask for some form of proof that is simply impossible to obtain. These are the folks who demand that you show them 100 customers who want a feature when you only have 10 customers using the product. My favorite is where someone says – and I'm not making this up – that you show them some number of people willing to place orders for something that doesn't exist yet. This is chief in my pantheon of impossible situations. Who will order a product that hasn't been designed and built yet? No one and the Prove Its know this.

A subtype of the Prove the Impossible is the Outer Limits. These folks will ask for some form of validation that is possible to obtain but for which there are no resources. For example “Perhaps of you could survey 5000 people we could get the information we want?” Well since there is no budget or personnel for a survey of that magnitude and they know it, it's just an attempt to stop forward progress. Most of the time, these so-called “reasonable requests” are not at all reasonable.

Another form of Prove It is the Prove the Unknowns. They insist that you prove things that defy logic since you can't prove what you don't know, only what you do. They know this of course but that's not their point. One of my favorites – and I'm not making this up – is “can you prove someone else isn't working on this too?” Of course not! I might know that someone is working on it but not that they are not working on it. Just because we don't know that someone isn't doing something doesn't mean that they aren't. Only that we don't know. Another one “Can you be sure that there won't be a different technology that does this in six months?” How can I unless I can predict the future. That's why we know this is not a real question. It's only designed to obstruct.

The Irrelevants

This is a true story. I couldn't make this up if I tried. In a design review for a military radar system, an engineer asked “If the ship is hit with a nuclear weapon, will the software reset?” What?! Even as a very young engineer, I was struck by how silly this seemed. Silly because it was completely irrelevant. That's one of my favorite forms of obstruction – focusing on something that doesn't matter as if it does. It slows everyone down as they scramble to put aside an objection that has no right being raised. I find The Irrelevants especially irksome because they not only obstruct but also annoy. Most of the time they walk around with the type of smug expression that drives people nuts.

A fairly insidious form of irrelevancy is make outliers seem important. You talk to 100 customers about a feature. 99 love it and 1 doesn't. Truth be told, that one hates your sales guy but you can't say that. The fact that your meeting opened with a 30 minute diatribe outlining all the things he hates about the company starting with your tie is not important to The Irrelevants. Nope, the one person who will never buy from you again anyway (we told the sales guy not to date his daughter but did he listen?) is given the same credence as the 99. The fact that those 99 wanted to have you over for dinner after hearing your great idea doesn't seem to matter. So, you spend a month trying to dilute the nasty comments of one customer with an ax to grind. The Irrelevants love the first guy and hate the 99 others.

By the way, the answer to “will a nuclear blast reset the software” was “I don't know but it will probably reset the operator.” I loved that response.

The Ignorants

These folks are my Room 101. We are talking about the Pointy Haired Boss types who insist on commenting on something they know nothing about. Think about the engineer who tells sales and marketing what customers really want when they have never met a customer in their lives. Or the salesperson who tells a bunch of programmers that something is just a SMOP (simple matter of programming). You can see it coming when they start their sentences with “I don't see why we can't just...” The "just" is the keyword here.

There is a difference between the Ignorants and the Truly Ignorants. The latter are sad but well meaning. They are trying to be helpful but out of their league. The Ignorants are trying to demean. By being dismissive of ideas they kill them. Another indicator that there is an Ignorant in the room is how they resist explanations. The Truly Ignorant will listen patiently even if they don't understand a word you are saying. They are suffering because they want to understand and be helpful but can't. Be kind to the Truly Ignorants. The Ignorants on the other hand don't want an explanation. They want something and explanations get in the way of them getting it. These folks will dismiss explanations with a Dogbert like wave of the hand and a hearty “Bah!”

A combination of an Ignorant and an Irrelevant are the “Sky is falling” types. They fill up the discussion with both the ignorant and irrelevant points designed to paint a picture of the end of the world. If you are talking about Global Warming or Nuclear War, a certain amount of that attitude is to be expected. When the subject at hand is a new laptop then the Chicken Little routine is an indication that you have an Ignorant Irrelevant in your midst.

I still can't figure out these people. Is it a power thing? Feelings of inadequacy? Hubris? I don't know and stopped caring awhile back. What I do know is that when you encounter these folks they need to be neutralized quickly before they destroy a perfectly good product initiative.

Of course, once they wreck a good product, they will point to that as an example of the type of failure to be avoided. Bizzaro logic for sure but quite effective. If you run into these people stop them be for it is too late. Otherwise, a perfectly good and innocent product may die or be crippled. And you don't want that on your conscience, do you?

How Accountants Ruin Customer Experience and Other Cautionary Tales

I am always amazed at how smart people can make stupid products. The quickest path to bad products is not bad engineers though. It's good engineers listening to accountants, especially cost accountants. Don't get me wrong, accountants are themselves usually good people and pretty smart. They just see the world in a certain way, as a giant spreadsheet. Make a cost number smaller, the bottom line gets bigger. Makes sense but not for customer experience.

A case in point is the new ATM at my local bank ( HSBC – “The world's local bank”). For the past 30 years, since the dawn of the ATM, these awesome machines have accepted deposit envelopes. While I am the first to admit it stinks to be stuck behind someone in line who didn't fill out the envelope before walking up to the machine (why is that anyway?), envelopes serve an important purpose in the deposit process.

• They keep everything nicely bundled. This way you don't have checks floating around your car or flying away in the breeze.

• They keep your deposit protected. Envelopes help make sure your money does not get crumpled, twisted, folded, spindled, or mutilated.

• Envelopes aggregate your checks into one transaction. One envelope, one action. Done.
  

Given that envelopes are an important part of the customer experience when depositing at an ATM, why in the name of all that is intelligent in the universe would you eliminate them. Why indeed but HSBC has done just that. Their new ATMs will not give you an envelope and the machine will not accept one. So instead of taking my five checks as a unit I have to feed them in one at a time. Cash has to be fed in separately as well. The result – lousy customer experience. Here's the result:

• It takes as many times longer to feed checks into the machine as there are checks. Five checks? Five times as long. Nice.

• I am sure to have a check get away from me to be lost in the breeze or trashed in a way that the machine will not be able to process it. Thanks for the paranoia. As if I didn't have enough of that from banks.

• Since it will take longer to process deposits, the folks behind me in line are bound to be more annoyed. Or have more opportunity to rob me. Now that's looking out for your customers HSBC!

• I have to press a bunch more buttons raising the chance that I will make a mistake and have to spend more time correcting it or, more likely, start over. (Okay, for you statistics weenies out there – the chance is not higher, just the incidence since the number of tries is higher. You knew what I meant!)

• Given all of that, more people will now go into the branch, overwhelming the few tellers left leading to even longer lines and delays. I get goosebumps thinking of that one.

• I now have more incentive to take money out than to put money in. Huh? Don't banks need money going in faster than out... oh forget about it. It's too stupid for words.

Why would HSBC be so willing to wreck the customer experience of a technology that benefits them as much as it does the customer? Accountants, that's why. No matter what they might say (“Our research shows that customers like to punch buttons until they have carpal tunnel syndrome.”) this is an obvious attempt to not pay for envelopes. Someone in the bank calculated that so many pennies per transaction will be saved by eliminating envelopes. It probably never even occurred to them how it would negatively effect customers. That doesn't show up on the ledger sheet right away.

One more thing this requires to happen though – a gutless vendor. Likely scenario:

HSBC Bank: “Can you make an ATM that doesn't use envelopes?”

Diebold (ATM maker) : Sure! With out new optical scanning technology we can have customers feed checks in without an envelope. They will then be scanned with 98% accuracy!”

HSBC Bank: “Great! Let's do it.”

as opposed to:

HSBC Bank: “Can you make an ATM that doesn't use envelopes?”

Diebold: “Um. Are you sure? I mean, won't that really annoy your customers?”

HSBC Bank: “Well, how so?”

Diebold: “Where to start? Okay..”

ten minutes later...

Diebold: “and we would be making it easier for people to take money out and harder to put it in. You being a bank and all, they doesn't sound like your business model.”

HSBC Bank: “Holy CDO! Um. Forget we ever asked. And remember, this conversation was under NDA. Whew.”

So remember folks – the best vendor is the one willing to tell you what you don't want to hear even at the risk of a sale. That is the vendor that would not let you walk off the HSBC cliff. Also remember that the customer experience generates revenue. Never, ever even look to cut costs there. That is the path to destruction. Spend money there even if it means cutting executive salaries.

Night of the Living Dead Products!

Products, like living things, have a lifecycle. We conceive of new ideas and birth new products from them. They then begin to mature, finally to begin the slow decline to death. The period when they are in decline, past their maturation period is, hopefully, a long one. When it takes a long time for a product to reach end of life, we call that the long tail and boy is it sweet. You get free money, basically.



Sometimes, however, it doesn't work that way. It may be that there is one critical customer who still loves the product and wants a few more. Perhaps the folks who conceived of and built it have an emotional attachment to it. Often, there is this trickle of revenue associated with it that no one wants to give up. That is the most usual problem and the fact that the support costs are exceeding the profit on the product don't seem to work into anyone's calculations.



No one wants to invest in these products. It is recognized that they are old and other products have supplanted them. So they neither grow nor die. They are Zombie Products! (big B-movie scream here).



You know what I'm talking about. The product that is balanced between life and death. It lives in a netherworld, not moving forward nor toward end of life. The living dead!


Zombie products represent a real problem. They cost real money to make, stock, and support. Parts can become scarce as suppliers end of life their old products. They don't make the kind of margins that are needed to maintain the business. They don't even show the company well - if someone see a Zombie product they may get a negative impression of the company and its products.


So what does one do when there are Zombie products shambling about? Do what you always do to zombies - shoot them in the head. By that I mean, you have to kill them. No matter what it takes, you have to kill them! If the first shot doesn't take them out, try again and again. They must be killed.


Before they kill you...

I Am Dumb

If you haven't heard about this already, then let me be the first to give you a chuckle. Apparently, someone uploaded an application to the new Apple iPhone store called "I Am Rich". Priced at 999.99 (the highest price the store allows) it does basically nothing. If you click on its icon, which is shaped like a ruby, it displays a picture of a bigger ruby. The author makes no attempt to hide the fact that this application doesn't do anything. He is right upfront with this being $1000 for something completely useless. The application's sole reason for being is to display to the world that you are rich enough to toss down $1K on nothing. It is the 21st century version of lighting your cigar with $100 bills. Channel Web had a great article about it.

Two things really caught my interest here. First, that eight people actually paid for this. That's incredible. Even if you are Bill Gates-wealthy you don't throw your money away like that. The more important fact to emerge in this whole farce is that some of these people were not rich and did it because they thought it was a joke. Are you kidding me? At what point after they entered their credit card numbers in did this cease to be funny. Hello! It's not a joke when you pay serious money for it.

This leads me to the real purpose of this rant - idiot proofing. There has always been tons of talk in the engineering profession about making something idiot proof. As this situation shows, it simply can't be done. By definition, smart people don't understand how idiots work. They simply cannot conceive of the stupid thinks some people will do. Internally, they dismiss the really dumb behaviors of some people as being impossible. To themselves they say "There's no way anyone would do that". They might not even be able to think of something to mentally edit out because it is not how they would act or think. Just look around YouTube and you can see all the stupid things people do that a reasonable person wouldn't even be able to wrap their head around let alone come up with on their own.

Simply put: You can't predict what an idiot will do. You can only react to what they have already done.

You can, however, predict what a reasonable person will do. Even if the person is inexperienced you know they will act in a reasonable manner. As a reasonable person you can understand and predict that. You can say "Oh. I can see how someone would do that."

So, I want to advocate a different design philosophy called "reasonable person proof". Strive to make products such that you keep a reasonable person from doing reasonable things that are somehow harmful. If this product is in an area you don't know very well, ask people in that area what they might do. Observe normal people using your prototype in normal ways. If you design hammers, watch a carpenter hammer nails into a wall and come up with a way to keep the shaft from shattering. Don't try to keep a moron from getting hurt when he uses the hammer on his big toe to see what it feels like. (If you don't believe me on that one check out this video of a bunch of morons doing just that. All I had to do was go to YouTube and type in "hit toe with hammer." For the record I only looked for the video after writing the sentence but I digress.)

Rather then try and keep all manner of stupidhead from doing something completely dumb and harmful with your product, recognize that you can't predict that. Put on all those warning labels that cover you legally but don't try and design around it. It's a fools game (pun intended). Instead, assume that your customers are reasonable people and design for them. They deserve that attention. The idiots do not.

Oh, and everyone email Apple and tell them to put "I Am Rich" back on the Apple Store. Whether it's a demonstration of fabulous wealth or a honey pot for dummies, they should let us make the choice including the dummies.

Waiting on Extensions

I don't know when the Mozilla Foundation will finally get this straight but here it is again - some extensions really matter! For those upgrading to Firefox 3.0, there will be grave disappointment when they discover certain popular and key extensions are not yet updated.

I get the philosophy of having a lightweight browser where you add the features you want through extensions. However, some extensions are so popular that they take on the same weight as a standard feature. Ultimately, if the extension is not ready, then the whole software package is not ready. You can't act like extensions and plugins are part of the rich universe of your product and then ignore them when you launch a new version of that product. When the extension doesn't work it is the same as having removed a feature.

Take IETab. This extension is not only great to have, it's essential. There are still a great many websites that are built for Internet Explorer and won't render or function correctly in Firefox. IETab elegantly deals with this problem by allowing Firefox to use the IE engine in a tab. Other extensions simply launch IE which is not what you want when you open a bunch of tabs. This is a critical feature for Firefox to be useful outside the closed world of Open Source people who have disdain for Microsoft. Yet, IETab is not ready for download into Firefox 3. Heck, I can't even find it in the Add-ons site anymore. It only seems to exist at the development site, Mozdev.org.

Every time Mozilla launches a new version of Firefox or Thunderbird, we go through this. Half of the important extensions don't work or are unavailable from the automatic upload service. This is too consistent a problem to be accidental.

It calls into question the whole idea of community development. I'm not criticizing the author of IETab. They have better things to do than keep up with Mozilla. It's up to Mozilla to make sure these important extensions (really features) are available. If the community can't do it then Mozilla has to. This is the millstone around the neck of the Open Source community - inconsistent support for vital features. If Mozilla has to rely on people who do this as a hobby for their product to be functional, it will never be truly competitive.

Since I hate complaints without solutions here's what I suggest. First, find out what extensions are important to the majority of users. These are now features. Whether you make them available as a built in feature or an extension doesn't matter. They just have to be available. Second, design Firefox to insure backward compatibility with older extensions. A lot of extensions won't load because they say they only support the last version. My guess is that many of these extensions would run fine if it weren't for the version check. Maybe the solution is as simple as a override on the version check for a particular extensions.

Finally, stop releasing product until you have tested the critical extensions. Recognize that your work is not done until the extension maker's work is done. It would also help if the latest version is available for automatic update. Sometimes extensions are available on the author's website for quite some time before they hit the automatic update facility.

Luckily, I backed up my extensions and kept FireFox 2.0 around. I'll stick with that until I know all my critical extensions are updated. This is not the way I would have liked it to go.

Why PRDs Screw Up Product Development

Anybody who has ever been involved in product development, especially in the computer industry, knows that it is a process that rarely proceeds smoothly. At some point in the development process it is becomes obvious that the product will either not be what was hoped for or will be late. If you are lucky, you will get a product that is just about good enough and close to on time.

Sometimes, you get what you want (or more accurately, what the customers want) when you want it. Rarely. Products like the iPod are the exception to the rule. They hit the right market at the right time with the right features. It's rare because it takes an extraordinarily visionary with the clout in the company to make it happen. Not every company has a Steve Jobs.

Instead, we all get to that point in the product development cycle where Engineering and Marketing/Sales are at each others throats and things are heading south quickly. The culprit? The Product Requirements Document a.k.a. the PRD. It might be called almost anything (Specifications, Requirements, Concept) but it's always the same - the document that defines what the product is and who it's meant for.

"Now wait a minute!" you might be saying "That's the very situation the PRD is supposed to avoid!" By outlining the features in sufficient detail, engineering knows what to build and marketing has the commitment that it will be built when they need it. How could that be the problem.

The problem isn't the document per se. It is what it really means to the people involved. To most of the folks involved in product development, the PRD is a social contract. An agreement between those who build and those who sell to produce something that the company can make money with. There is a lot of emotional and social capital invested in it. For marketing people, their ability to do their job properly as well as their reputations are on the line. For the engineers, their sense of self - as builders and innovators - is at risk.

Inevitably, there is some important feature that turns out to be much harder to produce than was originally thought. That is the nature of innovative products. When the PRD - the contract - cannot be met all kinds of social problems start to raise their ugly heads. To some, failure to meet the PRD is a failure of the people involved, a kind of dishonesty. A breaking of the contract. There is a tendency to try and find fault with "the other side". The feature wasn't well defined. Sure. You guys in the back have been goofing around with unimportant features. Right!

This inherent conflict cannot be resolved easily either. Too much is at stake for all parties for that to happen. Two major drivers inhibit resolution. The first is humiliation. To the engineers especially, this is personal. They are the makers and they can't make. It's like a chef messing up burning your steak. Few organizations are able to deal with this effectively. Even if most of the team acts well, there is almost always some who do not. There is always a few folks who will act dismissively. It is typical for the marketing fool to say something like "I don't understand why this is so hard. It's just code (or plastic or whatever). This is a non-too-subtle way of saying "You are a loser who can't do your job". Not that the marketing dweeb in question has any idea how hard it can be do to code or plastic or toilet seats.

By the same token, there is always some geeky engineers who, in trying to save face, say things like "Why don't you just sell the features we have finished". Again, a dismissive attitude about something they know nothing about. Sure. No problem. Of course, the fact that the competition has what we have plus the feature you can't make doesn't matter. Sometimes that's ignorance talking (most engineers have never had to sell anything - and we are thankful for that). Most of the time it is a clumsy attempt to deflect criticism. In the end, acting this way toward each other makes everyone furious and shuts down the ability to solve the problem.

As an aside, one of my favorite behaviors that you see in these circumstances is The Pointing Out of Flaws. Similar to the Airing of Grievances at Festivus (Watch Seinfeld reruns if you don't get that) it consists of one arrogant jerk pointing out all the problems with a plan while never offering up a solution. I can't stand that. It accomplishes nothing while making everyone want to slap the pompous ass doing it. These people must be put on the spot with "What do you suggest then?" or "Thanks for the analysis. I'm making you responsible for coming up with solutions to these problems."

The only thing that short circuits this behavior is a lack of tolerance for it. Team members have got to be able to admit they are struggling with something without fear of being publicly humiliated by others. Not only shouldn't the dismissive behavior be tolerated but an environment has to exist where small failures can be admitted so that the team can come together and form a solution.

The other reason for product failure is, oddly enough, lack of accountability. In too many cases, either no one or the wrong person is held is held accountable for failure. That happens all the time. In some cases, we are afraid to take people to task because they will become unmotivated (a highly questionable assumption). In other cases there is no way to do so since metrics are vague or nonexistent. Or worse, the metrics are stupid such as lines of code per day. Since no one is accountable for failure, no one is responsible for solutions. So, you don't get any solutions.

The whole team suffers from the slackers or incompetents. Either everyone has to work doubly hard to make up for those who fall behind or everyone gets blamed. That's when the humiliation factor kicks in. If you feel like you are being tarred with the same brush as the guy who isn't keeping up, you will get pretty defensive. It's simple mental self-protection..

The way out of this dilemma is also good management style. Those who bear the most responsibility, the team leaders, need to identify ways to measure outcomes along the way and deal with those who are not making the grade. That can be frightening when it means you may end up shorthanded on the project. Shorthanded is still better than behind held back. If you can't rely on someone, you're better off without them. Jettison them immediately before they do too much harm.

And perhaps, most of all, change the PRD into something that sets the initial course of the project then, toss it in the back of the file cabinet. Let the managers manage to the people and the needs of the market and not a slip of paper. Make decisions together rather than pointing at a paragraph in a document and say "See! It's right there and you signed it. Loser!"

PRDs are fine for describing what you want to do. The team is what makes it happen. Free your team from the contract, refuse to tolerate dismissive behavior and hold everyone (including yourself) accountable for success and failure. You will get better products that way and on-time.