The Flip Side of ‘Service Velocity’

Publish date:

airport recently, I tuned into the middle
of a BBC show. In it, four delightfully
British people were talking about the
advantages of the Internet for startups.
Four times, one of the top three
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

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

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 smartphone.

Here’s how people talk about it, culled from an evergrowing
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 executive vice president and
chief technology officer 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.
The 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 try. I thank you in advance.

Stumped by gibberish? Visit Leslie Ellis at