The more debate I hear over protocols and product positioning in the networking market today, the more I realize that networking has a very big problem with myopia when it comes to building products. Sometimes that’s good. But when you can’t even see the trees for the bark, let alone the forest, then it’s time to reassess what’s going on.

Way Too Close

Sit down in a bar in Silicon Valley and you’ll hear all kinds of debates about which protocols you should be using in your startup’s project. OpenFlow has its favorite backers. Others say things like Stateless Transport Tunneling (STT) are the way to go. Still others have backed a new favorite draft protocol that’s being fast-tracked at the IETF meetings. The debates go on and on. It ends up looking a lot like this famous video.

But what does this have to do with the product? In the end, do the users really care which transport protocol you used? Is the forward table population mechanism of critical importance to them? Or are they more concerned with how the system works? How easy it is to install? How effective it is at letting them do their jobs?

The hypermyopia problem makes the architecture and engineering people on these projects focus on the wrong set of issues. They think that an elegant and perfect solution to a simple technical problem will be the magical panacea that will sell their product by the truckload. They focus on such minute sets of challenges that they often block out the real problems that their product is going to face.

Think back to IBM in the early days of the Internet. Does anyone remember Blue Lightning? How about the even older MCA Bus? I bet if I said OS/2 I’d get someone’s attention. These were all products that IBM put out that were superior to their counterparts in many ways. Faster speeds, better software architecture, and even revolutionary ideas about peripheral connection. And yet all of them failed miserably in one way or another. Was it because they weren’t technically complete? Or was it because IBM had a notorious problem with marketing and execution when it came to non-mainframe computing?

Take A Step Back

Every writer in technology uses Apple as a comparison company at some point. In this case, you should take a look at their simplicity. What protocol does FaceTime use? Is it SIP? Or H.264? Does it even matter? FaceTime works. Users like that it works. They don’t want to worry about traversing firewalls or having supernodes available. They don’t want to fiddle with settings and tweak timers to make a video call work.

Enterprise customers are very similar. Think about WAN technologies for a moment. Entire careers have been built around finding easy ways to connect multiple sites together. We debate Frame Relay versus ATM. Should we use MPLS? What routing protocol should we use? The debates go on and on. Yet the customer wants connectivity, plain and simple.

At the recent Networking Field Day 9, two companies that specialize in software defined WAN (SD-WAN) had a chance to present. Velocloud and CloudGenix both showcased their methods for creating WANs with very little need for user configuration. The delegates were impressed that the respective company’s technologies “just worked”. No tuning timers. No titanic arguments about MPLS. Just simple wizards and easy configuration.

That’s what enterprise technology should be. It shouldn’t involve a need to get so close to the technology that you lose the big picture. It shouldn’t be a series of debates about which small technology choice to make. It should just work. Users that spend less time implementing technology spend more time using it. They spend more time happy with it. And they’re more likely to buy from you again.

Tom’s Take

If I hear one more person arguing the merits of their technology favorite again, I may throw up. Every time someone comes to me and tells me that I should bet on their horse in the race because it is better or faster or more elegant, I want to grab them by the shoulders and shake some sense into them. People don’t buy complicated things. People hate elegant but overly difficult systems. They just want things to work at the end of the day. They want to put as little thought into a system as they can to maximize the return they get from it. If product managers spent the next iteration of design focusing on ease-of-use instead of picking the perfect tunneling protocol, I think they would see a huge return on their investment in the long run. And that’s something you can see no matter how close you are.