Strategy Consultants Strike Again? ... This time at eBay

In today's WSJ story about Ebay's co-opetition dance with Microsoft, Yahoo and Google, consultants are given some responsibility for laying a faulty foundation that lead to Ebay's predicament

• "Few at eBay initially saw reason to fear Google, say people at the company, in part because of a 2003 study it commissioned from McKinsey & Company concluded that Google wouldn't use its search capabilities to break into e-commerce. That made Google a manageable threat, say people familiar with the study."

Obviously, Ebay wants to put the blame for this on someone else; when in doubt blame the consultants. Good in theory, but seldom are strategy consulting recommendations baked without CONSIDERABLE input and direction from the client. I don't know the details of the Ebay study mentioned, but I bet it consisted of 3-4 consultants and 1-2 ebay employees. The findings were probably thoroughly baked with Ebay executives. I'm not defending a study that so obviously was incorrect. But as an Ebay shareholder, I hold management responsible for making that incorrect call. Consultants are, at best, a tool. Consultants are not responsible to share holders, most don't have equity ownership in their clients and most will not work at the same client more than once or twice.

Having been a strategy consultant and worked at companies that employ strategy consultants, I am amazed at how they are utilized. Fortune 500 companies would be well advised to have an internal consulting management group, which does nothing but manage consultanting engagements. The ROI of consulting projects is consistently under attack. Some of the problem lies with the consultants. Some of the problem lies with the executives who don't know how to engage with consultants, wasting considerable budget on their services.

The Art Of The Upsell

Yesterday, I was in a Blockbuster store and I heard the manager talking to his associate. The manager said, "The store looks pretty good, but you guys need to do more upselling at the cash register .... popcorn, gift certificates, whatever ... you need to do it." Unable to resist, I asked the manager how much additional revenue he brought in through the upsell. I got a polite, "I can't really say", but I'm not sure if he even knew. When I told him that in fact, I found the upsell so annoying that I would avoid stores that do it if I had a substitute, he thanked me for my advice. I doubt he spent last night building an excel model to balance the lifetime value of a customer versus the value of the upsell.

I really dislike the upsell around ubiquitous, commodity products. If I wanted popcorn, I probably could have gauged and responded to that desire on my own. I only appreciate the upsell when it is a value play for the customer where the customer either

• saves money (e.g., supersize this) or
• where the product has some unknown or confusing features (e.g., sommelier who says try this pinot noir instead of that one because it better matches the food, even though it is more expensive) or
• where the customer doesn't know about an option (e.g. navigation system on a car)

When the upsell is only around making more money for the business, it is so blatant that I could actually see it driving some customers away ... it has a negative impact on the brand. I think this principle is probably true no matter what you are selling .... cars, movies, enterprise software, whatever.

The old saying, though, about never projecting your own thoughts onto the whole customer base holds true. I'd be curious to see some numbers on this to determine if there is sizable revenue bump from the commodity upsell. Maybe more people than I think actually appreciate being reminded to buy popcorn.

Information Overload - from a decision perspective

I had an interesting discussion yesterday about information overload. The framework, though, was from a decision perspective: What percentage of decisions made are based on what percentage of information collected.

In my own life, I hypothesize that easily 80% of decisions I make are based on 20% of information I take in. In other words, 80% of what I read has no real bearing on what I choose to do.

Daily, I daily read the WSJ and various websites/blogs. Weekly, I read the Sunday NYT, Economist and a book or two. There is not only a lot of redundant information there, but a lot of information that is never even applied to a decision. That's not to say I'm going to stop reading all those sources. There is a lot of satisfaction in "knowledge for knowledge's sake". There is also social and entertainment value derived from information independent of its use in decision making.

For corporations or governments, however, where each piece of information carries a cost in either time or money, that 80% of information needs to be cut back. What form does it take? Unnecessary consulting reports, overlapping group output, unnecessary email trains, decks with no impact on a decision, etc.

How do corporations and governments solve this? Some of it is tools. Our group is using Wiki's which cuts down on unnecessary information such as vapid email trains. However, I think a lot of this is cultural. You need strong leadership that is able to say, "No, we aren't paying for another consulting report, we have all the information we need." That is really difficult to do. You can't expect someone who appreciates "knowledge for knowledge's sake" to suddenly flip a switch and be a different person at work where information is purely utilitarian.

The 57 flavors of Open Source business models

Last month I wrote that open source isn't a monolith ... it's different things to different people. With this framework in mind, it was interesting to hear THE open source business model practitioners discuss the topic on a panel at Linux World. Included were Marten Mickos from MySQL, John Roberts from SugarCRM, Marc Fleury from JBoss and Peter Levine from Zensource.

Each of the CEO's had a different view about the key driver in an open source business model; some were focused on the increased quality assurance in the development cycle while others were focused on the distribution aspects. I had the sense that these open source companies have more elements of a traditional business model than one would first guess.

It's too early to draw any broad conclusions from the few open source business models that exist. Given the variations in their focus, though, it's clear that open source isn't a cookie cutter business model that can be wrapped around any business. As for the threat to enterprise business models? It looks like a slow death. The panel had a general belief that the Open Source business model would squeeze traditional software companies, but within some debated 5-50 year time frame.

At the end of the discussion Peter Levine said something along the lines of, "You don't invest in something because it's Open Source. You invest in it because it provides a valuable service." That is the takeaway - Open source is only important to the extent that it provides things of value to a customer & company such as low cost, adaptability, speed to innovation, etc.

note: my post was from the viewpoint of a capitalist. Things get interesting when you consider groups that deploy Open Source in its "purest" form, as a means of production without a business model but instead to fill some communal need.

Command Center Reality

I had heard from some friends that Secretary of Homeland Security, Michael Chertoff, loves the Fox television show "24". An interview in the New York Times confirms this. Given his role, I always found this interesting, but now I know why. He has command center envy. Compared to what he deals with in reality, the command centers on "24" are things of beauty.

I remember about 7 years ago I had to give a reporter a tour of a command center after a newsworthy event in the Northeast. The tour started out great. The reporter loved the requisite security checks and security cameras. We had this cool vault like room for communications. Everything fit that "command center feeling" .... then we got to the command center itself. Apparently four computers, scattered communication gear, paper charts and a dirty coffee pot didn't quite fit the image. She was completely let down. What finally made it to the news? A shot of a Senior Chief using the phone system. Apparently, its sleek black console and 30+ buttons at least looked cool.

In any command center, there are legacy systems that don't talk to each other and communication always blunted by static. Information is rarely real time and decisions are made on 70% information at best. The lifeblood of these places isn't equipment or systems, its people who can execute.

The Democracy Bundle

Experts tell you to avoid negotiating over a bundled deal; instead break down the bundle and deal for each individual component. I couldn't help but think of this advice while watching "Meet The Press", where the topic was again focused on spreading democracy. What struck me is that democracy isn't a monolith as many seem to suggest, but it's really a bundle of many components. In the US, it's a bundle that typically consists of freedom (a framework which lets individuals act as they choose), representative democracy (a system for individual control over the government), capitalism (a right of private property) and the rule of law (a system of understood consequence management).

The Democracy bundle has always been built up component by component. The American founders had visions of an end state, but they negotiated over components and made tradeoffs when they put the Constitution together. And they relied greatly on some components that had been established prior to American independence.

Instituting the Democracy bundle has and will always be a messy affair, requiring tradeoffs and a long maturation process. We like to talk about Democracy as an end result, but a lot less time is spent discussing the necessary steps, component by component, to actually reach the end state. Implicit in such a discussion would be a realistic understanding of the cost, benefit and timeline.