Beware Sharp Edges!

October 23, 2009

BewareSharpEdges

I am sometimes chastised for saying it out loud, but engineers have a hard time with context.  Every physics homework problem that advises, “ignore the effects of gravity and friction” adds another brick to the wall that separates solutions to technical problems from solutions that are meaningful to customers.  I am not making a value judgment.  In fact, we would never make technical progress at all if every possible real-world variable had to be taken into account at the outset of a project.  An engineer once worked for me who insisted on starting every engagement with “What do we mean by reliability?”  before listing all of the possible ways that a system – any system, not necessarily just the one we were supposed to be talking about – could be unreliable.  None of those discussions ever came to a satisfactory conclusion.

However, as we saw in “Well, what kind of fraud is it?“, worlds collide when there is confusion about context. The collisions are damaging to business and sometimes it is impossible to recover from them.  It may be a technical feat to hone the edges of a warning sign to lethal sharpness, but it is not the purpose the sign.

Corporate culture can make it hard to blend context, and it is especially hard for companies with strong engineering roots to draw the line between valued technical advice and technical value that can be delivered to customers.  There was an internal joke at HP:

How can you tell where the sales meeting is?  Look for a dozen white Ford Tauruses in the  visitor parking lot.

The typical HP company car was a white Taurus, and it was common to hold customer meetings in which HP engineers outnumbered customers by five to one or more.

There is one sure-fire way you can tell that engineering culture is driving the business operations to a destructive collision.  I call it the catalog rule.  Imagine a sales meeting with N salesmen and M customer representatives.  One of the salesmen should be able to arrive with all of the sales material and, regardless of how large N is, there should be only M sales packets on the table — one for each of customers.  It happens so often that there are M times N catalogs on the the table that you sometimes scarcely notice it.  A customer wants to buy a solution to a complex problem. At the first customer engagement, glossy specifications for all of the carefully engineered component parts are dumped on the table.  This is the point in the meeting where the customer is supposed to have a flash of insight, leap to his feet and start congratulating the engineers.  In the real world, however, the reaction is a little different.   Very few customers want to be their own system integrators. My former Telcordia Applied Research colleague Dennis Egan puts it this way: “Our engineers just want to see their stuff used.”  It seems like a simple thing to ask for, but sometimes this urge for appreciation trumps all other concerns.   In particular, it can confuse the true business context, although you might have to look hard to find it.

It wasn’t that long ago that choosing a data communications service was a confusing and expensive task.  Many telecom customers chose the safe path and called their traditional voice telephony service providers, although it was frequently a big mistake to do that.  Data services in 1995 were a jumble of  software and hardware standards,  confusing pricing models, and regulatory inconsistencies.  A phone call to Bell Atlantic in 1995 inquiring about ISDN service inevitably led to questions that few commercial customers and almost no residential customers could answer.  The question “How far are you from the Central Office?” would usually be met with: “What’s a Central Office?” Because maps and engineering diagrams were frequently inconsistent, an ISDN customer would sit patiently through explanations of loads and coils and why the service probably would not perform as advertised anyway.  A thick reference book titled Engineering and Operations in the Bell System, published by Bell Labs, was given to every engineer in the company. Later, after the 1984 divestiture of the regional phone companies put the physical plant in the hands of seven independent regional operators, Bellcore maintained Engineering and Operations as the network engineering manual for all telephone infrastructure in the country.  By the time DSL service became widely available in 1997, Engineering and Operations specified a work flow diagram for providing DLS service to a single customer with steps that could only be completed after a hundred other independent steps all were completed.

These were the early days of e-commerce, and a clever group of entrepreneurs formed a company with the wonderful name Simplexity to simplify the life of telecom customers in the new age of data.  They had been buoyed by Michael Dell’s brilliantly simple business plan for the company that was to be Dell Computer™:  four pages that said in plain language that it was a hassle to buy computers and that virtually every potential buyer would choose to make a single phone call directly to a manufacturer if it would cut the hassle.  Buying data service was a hassle, too.  Simplexity’s founders reasoned that the 1997 equivalent of Dell’s single phone call for telecom services was this simple website:

Simplexityloginscreen

By negotiating with service providers for a percentage of all subscription fees – a process that was well understood in the industry because resellers of voice and data services were common – Simplexity was able to project a steady growth in revenue as data customers chose the Dell direct-sales shopping model.  Their first few customers apparently verified the market hypothesis, and Simplexity was one of the start-up successes of 1997, raising substantial venture funding and positioning itself for a successful IPO.

The engineering was flawless.  Simplexity’s Virginia-based development lab looked a lot like silicon valley start ups: an open floor plan with ping pong tables, bean bag chairs and board games scattered everywhere.  Java programmers seemingly fresh out of high school chattered excitedly about the next generation of services that would be marketed through Simplexity.com.

Then Simplexity’s revenue growth stalled.  The large number of smaller contracts that investors had anticipated did not follow the small number of large, early contracts.  In fact, new revenue began to decline even as data services began to explode.  Surprisingly, reseller revenue continued to rise as new customers shopped around and additional data service contracts were added to existing customer accounts in record numbers.  Simplexity began cutting its technical staff and adding traditional sales staff to compete head-to-head with the resellers.  This undercut the cost savings as Simplexity found itself paying more in commissions to order-book-carrying salesmen.  By early 2000, Simplexity had run out of cash, and, shortly after that, the company ceased operations.

In my discussions with company executives it was clear that they understood only too late that Michael Dell’s model did not work in telecom.  Customers had been purchasing voice and data services from human salesmen for years and the inherent inefficiency in doing that was more than offset by the personal relationships that drove sales.  A website – no matter how efficient – could not replace the long-standing social ties between buyers and sellers.  Simplexity was a great technology in a marketplace that did not need it.   The Dell model was a red herring.  Dell worked in the PC marketplace because there was no longstanding and trusted way of buying computers that had to be displaced.

Why didn’t Simplexity’s market research expose such a basic flaw in their business model?  I attended Simplexity’s early customer briefings – meetings for engineers aimed at selling their technical advantages.  They went out of their way to avoid positioning themselves as just another vendor.  Meanwhile their bricks-and-mortar competitors were fighting it out over who would get the next order.  It was “just another vendor” who got the order.

This is the message that I give to new start ups:  if it’s a choice between an exciting technology meeting and a boring sales meeting at which you are just another vendor, choose boring.   Your customer may not understand it, but if your product is really that good it will outshine the competition anyway.   And, if you are in a vendor meeting, chances are someone  is interested in buying.   It may be more exciting to warn everyone about your sign’s incredibly sharp edges, but that’s not the real reason it’s there.

.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: