The Flip Side of ‘Service Velocity’
by Leslie Ellis // October 17 2011
“Fail quickly.” On driving home from the airport recently, I tuned into the middle of a show on BBC. In it, four delightfully British people were talking about the advantages of the Internet for startups. Four times, one of the top-3 reasons stated was the ability to fail quickly: Think it up, put it up, see if people like it. If they don’t, take it down. Gather lessons learned, dissolve, move on.
Example: You want to open a store. In the old world, that meant finding space, then signing a year’s lease. Online? Try it out. If it doesn’t work, take it down. Fail quickly.
This is all great, unless you’d just spent cash money on the product or service. Or you really liked the thing that failed quickly.
Another example: Your salon gets you completely hooked on some new hair care product. You agree: It’s the best. Then, six months later, they don’t carry it anymore. You reluctantly try the new thing. Get hooked. Six months later …
In the rolling transition to “all things IP” (Internet Protocol), one benefit comes up a lot: Service velocity. Launch new services more quickly. Say goodbye to the dreary muck that is hooking into back office systems that grew up in the proprietary-heavy past. Keep content fresh. Add new features in eight weeks, not 18 months.
Service velocity is everything you’ve seen happen with “the guide,” all tightened up, studded with graphics, and available in ways that aren’t constrained to the remote control: On an iPad, on your smart phone.
Here’s how people talk about it, culled from an ever-growing batch of notes on the topic of The Big IP Transition: “Development cycles are getting shorter and shorter. For set-tops, we have about 300 developers and quality assurance (QA) people who do nothing but set-top box software. With those 300 people we put out a total release of the guide about every 18 months.
“Compare that to the development of an iPad app. We had 10 developers and QA people. Start to finish, we put it out in five months; today we’re on the fourth version of the app. Last year, this time, the tablet wasn’t even in people’s hands.”
That was Comcast CTO Tony Werner, talking to a Canadian audience earlier this year about service velocity. Another part of it, he noted, is the back office. “Five, six years ago, we started to stand up all the back-end systems into web services.” Goodbye, huge internal integrations; hello, web-based interfaces to practically everything. Hello, cloud.
Service velocity is important, for obvious reasons. Cloud gets you there. So far, the only obvious examples of “fail quickly” in the video world are those apps, usually not related to video, getting taken down from connected TVs.
Failing quickly, as a byproduct of service velocity, is inevitable. All I ask is this: When you decide something’s a failure, think about how to treat those people who really like it, or who just spent hard-earned cash on it. Give us an alternative to reluctantly try. We thank you in advance.
This column originally appeared in the Platforms section of Multichannel News.