There are a number of problems with expertise.

As Gladwell wrote in Outliers:

The idea that excellence at performing a complex task requires a critical minimum level of practice surfaces again and again in studies of expertise.

Gladwell suggested 10,000 hours was the minimum. Although this has been disputed as a myth, there is no question that expertise requires a lot of time spent in pursuit of a subject. What this tells us is that expertise is mostly singular. It’s unlikely that an expert in one field has anything useful to say in another. In other words, expertise is seldom elastic. Polymaths are rare.

Yet, we are all too happy to latch onto the latest opinion of so-and-so expert even when he or she is talking about subjects outside of his or her expertise. Actually, it’s more likely that we are allowing the “cult of the personality” to affect our own thinking and judgement.

The Web is full of “expert advice” from start-up gurus who will trumpet their opinion about how to succeed. Most of the time, their opinions can hardly be called expert ones unless they’ve had multiple successes by mastering the same methods. Such examples are almost impossible to find.

Sure, a guy who spent his life taking photos can probably tell you how to get a shot. A guy who built 100 iPhone apps will probably tell you a thing or two about optimisation and common bugs. He might even tell you a thing or two about app store optimisation, though I doubt it will amount to much.

The real pitfall to watch is when you’re asking an “expert” what to do in order to make a life-direction decision, like starting a business, moving jobs, finding satisfaction in what you do, raising kids and all those other things where real expertise is rare and the reason for asking an “expert” is usually lack of self confidence, or some other fear.

Sheldon Kopp laid it all bare in his psychotherapy book “If You Meet the Buddha on the Road: Kill Him!”

His thesis was to remind us that the guru we seek is only human like us, full of faults and uncertainties, proclivities and every other human ailment. They can only lead us to what we probably know already, to answers within, answers that we fear to give the light of day they deserve.

Kopp says:

Therapists do not and cannot give answers. Explore the true nature of the therapeutic relationship, and realize that the guru is no Buddha. He is just another human struggling.

In my now 23 years (and easily more than 10,000 hours) of being in the blessed position of working in and around innovation, I have noticed only one constant. What separates the non-expert innovator from the expert is only the willingness to try.

The greatest barrier to innovation is simply that folks don’t give themselves permission to innovate. They are held back by the myth of expertise – their supposed lack of it or their fear of it in others. When it comes to innovation, there is no such thing. We are all innovators.

If we want to return to “manufacturing greatness” then we have to think anew. We need to redefine what making things means. This transformation is already underway with the emergence of a “Maker Culture.”

The movement is seen mostly as a kind of hobbyist activity, but what if we could scale it up? What if we could take the Linux approach and disrupt other industries, such as making cars? What if we could escape the mundanity of mass-manufacturing and discover a new world of mass customisation?

The car hasn’t really evolved since Henry Ford‘s famous refrain:

You can have any color so long as it’s black.

I find it frustrating that I spend so much money on a car, and so much time sitting in one, yet I’m subject to the tyranny of a fixed design that has little to no prospect of customisation. Cars are almost completely unhackable.

Kit cars (or should that be Kitt?) have been around for some time. During my teenage years, I watched with envy the guy over the road building a yellow sports car atop of a VW Beetle chassis. Dave Smith of Factory Five says:

Building your own car puts you in a special and exclusive club.

I hope not!

I have a vision where building your own car – like Lego – is the new normal.

Why not?

Here in the Bay Area, I can pop to my local Tech Shop and build pretty much anything. This is the age of open source, AutoDesk, 3D printing, Arduinos, Raspberry Pis and retrofit hybrid kits.

Sure, I’m not expecting that the whole car is squeezed from some sausage-CNC-milling-printer gizmo, but with the right standard parts (based on a popular vehicle, licensed from – who knows – Ford maybe), open source control software and a “designed-to-be-hacked” architecture, a hybrid (as in mixed, not electric – but that too) kit-assembly-line car is easily within grasp.

Will it work? Will it be safe? Will it beat 100 MPG?

Who knows?

The real question – and point – is what would the budding Henry Ford of today do with all this technology at his disposal? And how do we create a nation or budding Henry Fords?

By teaching our children to dream of reinventing old industries, to become the new Wright Brothers, Fords and Elon Musks. By incorporating more “project based learning” in our schools. Or by simply reinventing schools altogether, liked the DaVinci schools in LA.

[Paul Golding is currently researching the idea of creating a project-based school in Silicon Valley around the very idea of re-inventing the car. Reach out if you'd like to know more.]

My labs team is trying to solve various problems to do with perception, taste and color harmony. The end goal is to suggest decor products that the user will find pleasing in his or her current, or planned, space.

This inevitably means that we have to use software to figure out what people might love. I’ve met and interviewed various color experts, interior designers, and all manner of folks in the “color business,” whether that’s fashion, decor, painting or image processing. We’ve set out to build a “decor engine” that will attempt to understand color, decor, taste and then find products that fit with various “decor taste profiles.”

If you want a very good introduction to color models, the Wikipedia page does a great job for the most part (and the HSV, HSL page  offers lots of additional detail). For those with a greater thirst for color insights related particularly to painting, Bruce MacEvoy’s (January 2010) Color Vision book is a fascinating and curious read. Pantone publish lots of books about color, many written by the fabulous Leatrice Eiseman who has influenced a lot of my thinking about the importance of color moods.

One of the most intriguing discoveries was the existence of color prediction and an entire “color cabal” dedicated to predicting color trends, as far out as five years for the automobile industry. Of course, they are not predicting at all. They are deciding and then publishing the trends for entire industries to follow.

Now, all of the theory and machine intelligence in the world won’t make a difference without a credible user interface. And it is here that I spend most of my time pondering the issues of “interface language.” You see, all interfaces “talk” to the user, via symbols, text and a variety of visual structures.

Take the humble color palette for example. The web is now strewn with sites that offer to create, curate, suggest and design color palettes. Colourlovers.com is one of many examples. What does a palette with five colors say to its viewers? Why five, not three? Why this particular order and not another (the inevitability of using an array of color chips is that the array has to be ordered). What does the order mean?

Such questions have to be answered in terms of both the mental models that the intended recipients might have about color and color palettes, and in terms of what the “palette curator” is intending.

In product design, separating out the “technical language” from the “user language” is one of the most challenging problems. We see this all the time with software products and electronics. The greatest mind shift comes when a product manager or designer realizes that he or she is really an advocate for the user, not for his or her own design ego and worldview.

Oh, and just so you know, 2013 is the year of emerald green.

If we are honest with ourselves, we are all easily distracted, especially in this multi-tasking world that we now live in. I typically work on >3 projects “at once,” and switch constantly between email, IM, browsing, writing, thinking, researching, note-taking, coding, slide-building, drawing and various creative tasks. As I write this, I have 7 apps open (far fewer than normal) and 15 active tabs in my browser.

When I get frustrated by a particular task, I find myself switching back to Gmail to check my mail. I don’t need to check it, but it’s my “distraction habit.” It’s my “Minecraft.”

But Minecraft, or Gmail, is not the problem, nor is ADD necessarily (notwithstanding all the issues surrounding that “condition.”) There is a group of children who find it hard to do certain types of task simply because their brains are wired differently. If you believe one theory, it’s because they have more of the “Hunter gene” that would have caused their ancestors to scan the horizon often. When “confined” to certain tasks, environments or processes, such a child will “struggle.” They will day dream or switch to another task.

However, it turns out that there’s a flip side.

There’s always a flip side.

In this case, it could well be creativity and rugged individualism. And the down side to trying to “solve” the distraction issue is that it can easily crush the “creative chaos” that comes with a set of traits that Lucy Jo Palladino describes as “Divergent Thinking” or “Edison Traits” in her original text “The Edison Trait: Saving the Spirit of Your Nonconforming Child.” She re-titled the book to: “Dreamers, Discoverers & Dynamos: How to Help the Child Who Is Bright, Bored, and Having Problems in School.”

Per her description of Edison himself:

Edison flunked out of school twice, but he went on to become a prolific, world famous inventor. What caused this tremendous turnaround? His mother, Nancy Edison, identified her son’s passion for science and used it as a basis to motivate him to succeed. She made a deliberate decision to define her child by his strengths, not his problems.

By developing this “Edison Trait” theme, the book offers some important insights. The most intriguing for me is the suggestion that ultimately there may be little a parent can do to get their “divergent thinking” child to “conform” with regular patterns of learning and experience. That being so, the most critical and generous act is to let go of your expectations and enter into their world to see, cherish and then encourage their strengths.

The most powerful line in the book is:

Your child’s belief in himself begins with your belief in your child.

Telcos are rapidly headed towards their own fiscal cliff because the model they built their industry upon is crumbling. Many of them don’t believe it, but only in the same way the Roman Empire, or any empire, constructed a worldview mostly in terms of past glories. There is also a good dose of denial – “it can’t happen to us.” That is the child-like naivety that we all like to cling to – that bad things only happen to other people. Telco innovation is the only way out, but it remains an elusive and misunderstood concept.

The problem is one of human psychology and no business strategy will fix it. Just like any procrastinator knows, change must come from within before circumstances will improve. A procrastinator is entirely aware of his self-destructive behaviours, but constructs elaborate excuses to blame his plight on external factors – lack of money, lack of this, lack of that.

That’s why a parent who balls at their underachieving child is making a critical error, what logicians call a category mistake. An underachiever is fully aware of parental values like the importance of hard work, the benefits of good grades and so on. They are fully aware of their laziness. Shouting the same old refrains of “encouragement” will make no difference. An underachiever is afraid of taking responsibility, as are the majority of folks in a telco whose job it is to build a new company. The reasons might be different, but the psychology is the same. Telco innovation begins with true self-awareness.

I use the term “Telco Innovation” because, as I will argue, there is a huge misunderstanding that innovation is an elastic set of ingredients that can be copied from company A (say Google) and applied to company B (say Verizon). It’s a bit like drinking Matcha green tea and expecting to become an enlightened Zen master. It doesn’t happen quite like that.

Disconnected Values

As my industry associates at the fantastic VisionMobile point out in their “Toolbox for Re-inventing the Telco,” the very basis of competition for a telco has changed forever. The advice offered is that telcos need to “move their innovation focus from technologies … to ecosystems,” and that operators need to seek ways to “build unique user value atop the platforms.”

Many of the points in VisionMobile’s paper are well argued. I have made similar arguments for some time, including my own attempt to discuss the importance and impact of ecosystems in my most recent book Connected Services – A Guide to the Internet Technologies Shaping the Future of Mobile Services and Operators, which is really a book about telco innovation. I wrote it for those who had already understood that they had to figure out how modern software ecosystems work. The so-called patterns and paradigms are mostly unfamiliar to the majority of folks working for carriers.

But the problem is more widespread than just the telcos. Many of the vendors are equally stuck. To illustrate the problem, I will mention the strategic consulting work I did for the world’s largest supplier of messaging infrastructure. I was asked by the CTO office to facilitate the 5-year strategic planning workshops. I spent most of the time educating the team about ecosystems thinking, platforms and how the mechanics of innovation in a new (unknown, unpredictable) market are totally different to what they were calling innovation. Indeed, their tagline was “Innovation Assured.” As I pointed out, it is anything but. Telco innovation is even less assured.

The lack of assuredness became clearer when I started consulting as “Chief Disruption Officer” for a major UK carrier. It was interesting to see how the messaging team were optimistic that the same messaging supplier I knew well would provide them with new tools for building innovative services. Having just been on the other side of that supplier-customer relationship, I knew the folly of such optimism. The supplier had no innovation to offer.

And the problem was self-perpetuating. The reality was that the supplier was waiting on the customer to fund the innovation by placing an order for a half-baked product idea. There’s nothing wrong with half-baked. That’s what most innovation is initially. Indeed, my new neighbours in Silicon Valley have turned this into a methodology, called the Lean Start-up. More on that later, but let’s finish the current tale of woe first.

I hope that I don’t have to spell out the irony of the above scenario. If the 2-way expectation of innovation support was symbiotic, then it might have worked, but it never works like that with telco-vendor relationships. Suppliers want to be innovative, but not without the guarantee of an order. Telcos want supplier innovation, but not without other guarantees.

I will be blunt about this. When I proposed various “disruptive” technologies, solutions and vendors to my same colleagues in the messaging team, I was ultimately told that the reason they like to use the established vendors had nothing to do with cost, as I often mistakingly assumed, but that “we need someone to blame when it goes wrong.” This returns to the mentality of the underachiever and procrastinator. These guys in their established jobs did not want to take responsibility for innovation. Better to “buy innovation” from a vendor so it’s their fault when it all goes belly up.

As a psychologist would tell us about this situation, there is a disconnect in value systems. What the “innovators” value is their job security and avoiding blame for mistakes. Within an operator’s “99.999% reliability” culture, making mistakes is regarded as a sin. All KPIs and metrics back that up. Ironically, the purgatory for making mistakes is often to be assigned to a so-called “innovation” program, but I won’t bore you with that tangle of thorns. It goes without saying that such job- and face-saving values are incongruent with innovation.

Change The People First

These kinds of issues are at the very heart of the problem and are why any amount of “innovation strategies” liberally applied are going to fail when they don’t take into account value systems and human psychology, as they often don’t . Managers will read endless numbers of innovation books and case studies. They will hold endless numbers of innovation workshops and launch, often to a cry of moans, yet another innovation scheme that internally everyone “knows” is going to fail, and so, unsurprisingly, does.

I talk with some experience. I have spent my entire 23 years on the forefront of innovation. It’s all I do. I have never spent one year working a “regular” job profile, repeating a pattern. I work endlessly with blank sheets of paper to find solutions to unsolved problems. It is exhausting, yet thrilling. I have done this in research labs, engineering labs, start-ups (my own and others), in large companies and small, in “conservative” cultures (e.g. Middle East) and “liberal” cultures (e.g. Silicon Valley). As I write this, I am working on my latest “labs” project, which is setting up an “innovation lab” for art.com as their “Chief Renaissance Officer” (couldn’t resist that title).

Prior to that I did the same for O2 and Telefonica. Prior to that I did the same for Motorola EMEA (their “Mashing Lab”). I have become somewhat a rare commodity and expert in figuring out these problems. Over the years, I have understood that the issues are a combination of psychology and technology, or attitude and execution. Tackling one without the other NEVER WORKS, but is a common mistake.

When I assisted O2, I began with the title of “Open Platforms Evangelist.” Usually an evangelist preaches to external players, but I took it upon myself to preach internally. I knew that mindset change was vital. I lost count of the number of times managers of various grades asked me “So what do we do?” I consistently answered “Change the people.” I meant literally and metaphorically. However, a common response was “OK, but what next?” Which meant that they didn’t want to change, like underachievers and procrastinators avoid changing themselves, some times until it is too late.

If this fundamental aspect of mindset change is missed, no amount of innovation programs, expensive consultants, white-papers and labs projects are going to succeed. Again, I speak from experience. I was granted a 7-figure budget in O2 to run an “open platforms” project, but it failed because it was killed by corporate anti-bodies from a dominant culture with different values.

It is an insidious problem because often those that rally to the innovation cause do so without realizing how deeply their own corporate-cultural biases run.

Whilst the necessity of mindset shift is not particular to a telco environment, the incumbent value system is. Telco value systems are in opposition to those required to orchestrate truly innovative programs and initiatives, especially the kind that underpin so-called ecosystems thinking, software DNA and now, “Big Data” (I will get to that). I think that this topic of “telco mindset shift” is worth studying because the assumption that innovation techniques are universal is wrong and some telcos have been spending hundreds of millions in acquisitions, programs and people, only to fail. It’s also why the glib application of ideas from Silicon Valley, like the Lean Start-up, are often a huge mistake, ending in failures that lead to the wrong conclusions about innovation. I was one of the first to attempt a Lean Start-Up method within a telco behemoth and learned much from the experience(s) (I did it more than once.)

What goes undocumented about many innovation patterns is the unspoken context of values. And this is a very hard problem to crack, mostly because it seems to me that organizations don’t have the tools to become self-aware of their cultural biases. It’s like asking an Englishman what makes him English. It’s not a conscious expression, so it’s hard to pin down.

This cultural confusion is why it’s possible for an organization to “reorganise” itself supposedly around a set of new, more innovative, values, only to find that nothing happens. They spend man-years of effort constructing new mantras, like “Be Bold” and somehow fail to be bold because, in truth, they don’t really want to be, or don’t really believe it.

It’s not that the new values don’t make sense, or are misunderstood. It’s not that people don’t want to change either. Quite the opposite is usually the case. It’s that the REAL values that make the company what it is, are simply misunderstood – they are too implicit, too imbibed, almost to the point of invisibility. They are deeply ingrained habits. They are cultural norms that are so “normal” that adherents don’t even think to question them before layering on new values that are like adding oil to water.

Many corporate managers don’t believe this. They make a fundamental mistake because of their own, usually above average, intelligence. They will say that they KNOW we have to change, or we KNOW we have to take risks, or any other well-reasoned statement, but the problem is they don’t “KNOW” at all. This is because they confuse their intellectual grasp of a problem and solution with real knowledge. In the English language, there is only one word for KNOW. But there are two types of “KNOW” – to know something factually and to know something experientially. Much of the thinking that drives innovation programs in telcos is based on anecdotal knowledge only. It is read in books. It is blindly copied from other companies – “We want to be like Google – let’s have a ‘do your own project’ day.”

This is why I insisted that one senior manager in O2 accompany me to Silicon Valley to participate in the first (and last – shame on them) Twitter developer conference (Chirp), including a 24-hour hack. That’s when we also went to visit the now widely known Twilio in San Francisco, a small bunch of well-funded enthusiasts inventing their own “open telco” world after the frustrations of dealing with the old-school closed one. The *experience* of hanging out with various folks with “software DNA” opened my colleague’s eyes. As I have tried to explain on many occasions, there are “developer cultures” out there that come with their own sets of values. Even many developers don’t understand this.

Ecosystems Can’t be Engineered

Why do I bore you with these details? Because they are fundamental to innovation, which is a human process. That’s why merely thinking of ecosystems as N-sided business models with new rules of engagement will not lead to anything useful. That’s why merely adding an API program to a telco, even if it does align with developer business models, will not succeed. Ecosystems are orchestrated by humans, not business rules and mechanisms documented in lengthy white papers by academics who often don’t understand the real mechanisms underpinning their models because they unwittingly factor out the cognitive elements.

It is still common to hear comments like “Apple don’t have customer workshops” or “Google are an adhocracy” as justifications for aping the same. These are the comments of fools who simply doesn’t understand company culture evolution. Why should they? Most of us go to work to bend metal or build spreadsheets, not figure out the bigger context in which we do those things. The metal-bender doesn’t question his need to achieve high quality. Everyone knows the principles of TQM, Six Sigma and Kaizen. That’s why he’ll go for twenty years doing something that he could’ve done better or differently, because to “disrupt” himself is unthinkable – it’s counter-cultural, it’s counter-intuitive. But intuition is not a sixth sense, it’s guided by a set of cultural norms and deeply embedded assumptions of right and wrong.

Ecosystems can NOT be engineered. They are emergent and they evolve. As those who study real ecosystems (in nature) will tell us, the emergence process is often a mystery. The ecosystem mechanisms are well understood, but the exact sequence and nature of of constructor-mechansisms aren’t. If we consider handset platforms as an example, it is a topic that I know well, including its history. I wrote a book called “Next Generation Wireless Applications” in 2004! When I tell folks who don’t know me about the book, they are often baffled – “Could you build mobile apps back then?”

Yes you could. It was called Java 2 Micro Edition, or Windows CE or Symbian. Later on we had widgets. In fact, there were many ways to build mobile apps, including SMS apps. O2, just after it became O2 (it was previously called Cellnet) had a program to work with developers long before the iPhone existed. I built one of the world’s first SMS apps because Vodafone had a program to offer programmable access to its SMS centers via a cumbersome X.25 radio PAD. My first start-up, possibly the first mobile apps company in Europe, built a wireless connector for Microsoft Exchange using a platform from Unwired Planet accessed via a GPRS modem. We built one of the first Blackberry apps. All these things were possible before REST, AJAX, iPhone, iTunes or app stores. Sun, Vodafone, Nokia, Microsoft, RIM, Unwired Planet and a host of players were busy constructing interactive components of — guess what — an emergent ecosystem. It’s just that it failed.

It’s not like telcos didn’t understand some of the concepts that “apps” folks think they invented, like user experience. Obsession with user experience is, ironically, what made innovation suffer for so long because telcos were unhappy about letting go of control. They wanted to certify apps, handsets, services in order to avoid potentially malign side-effects that would cause a negative user experience.

The ecosystem case if sometimes overstated. It made perfect economic sense for operators to think of making money directly from apps rather than a core-complements model. The reason this now looks outdated is that operators failed in their attempts because they were no good in executing them. The model was right, but the execution was wrong. It is tempting to suggest that the model was wrong because a different one has succeeded in its place. Clearly, to cling to the old model in the face of a new economic reality is foolish.

It is also an oversimplification to think that telcos never “understood” developers. Apple didn’t align their app store model with developer business models. They invented new ones! And it was only possible because they had – quite happenstance to developer interests – already created a marketplace infrastructure ideally suited to distribute apps. In fact, as many developers at the time bemoaned, Apple created a business model that developers hated because it created an expectation for cheap or free apps.

Using today’s criteria for a successful ecosystem (e.g. Android and its constituents), telcos had it all wrong. They were still trying to build an ecosystem, but not an open one. But, let’s face it, this was never going to emerge from telcos, even though some visionaries understood this potential. It was not obvious either that Apple or Google would solve this problem. Apple had a rocky history with developers (via OS X) and Google simply didn’t have one to begin with. Strangely enough, operators were dealing with developers before Google. However, Google’s business from the moment it figured out a business model, was naturally going to be an ecosystem play because of the strong correlation between complementary activity (anything that generates more eyeballs on search-related tasks) and advertising revenue. The correlation was far weaker for telcos because their core product (voice initially, and then data) lacked plausible differentiation (unlike the iPhone) and was driven by a set of economic precedents (level playing-field competition) that had a neutralizing effect on core revenue that far outweighed anything that ecosystem economics could have countered.

Evolution Takes Time

I don’t believe that a telco can merely copy ecosystem economics, not without understanding how such a move fits with their “values DNA” per my previous discussion. For example, customer ownership is deeply ingrained in the telco subconscious. It is a highly valued component of what they do. But let’s say they could overcome some of these inhibitions. The notion of merely “applying” ecosystem economics like a formula is deeply flawed. Ecosystems are emergent and evolutionary. Timing matters, as does time itself. Ecosystem emergence is often a long drawn out process that begins long before its impact is felt.

The innovations involved in iOS and Android ecosystems emerged (and evolved) over a period of many years. Sustained innovation is required, which can only happen with strong cultural values that support it. It is not a paint-by-numbers operation. To achieve innovation, you have to be innovative. That seems obvious, but the question of what it means to be innovative remains largely unexamined, even in the innovation literature. The books usually talk about the tools of innovation, not the values.

This is where telcos consistently fail, even with well intended attempts to reap the benefits of ecosystem economics, some of which I have orchestrated. I have been involved with several sincere attempts to combine ecosystem power with telco power. The problem is the timing. The event horizon for successful “scalable” innovation is always in years, if not decades if we take into account the value systems that precipitate scalable innovation ventures. The event horizon for telco innovation projects is never more than one year. And it’s worse than that. When a telco takes on an innovation project using “cut and paste” innovation tools, it’s usually allowed only one attempt at success, thereby making cultural change through experience (to really “know” something) impossible, which, I argue, is the only way its every going to happen.

Innovation is a Way of Life

I can mention several areas where I think telcos might attempt to benefit from ecosystem economics, but they will do no good without a means to alter values and without the guts to take responsibility for their own failures and successes. Also, I rather suspect that ecosystems thinking might not be the answer.

Either way, while telcos continue to think of innovation as “projects” rather than corporate responsibility to reinvent for a sustained future, senior management can continue to blame anything other than themselves for lack of innovation – they can blame it on the wrong innovation method, project, idea, unfair markets — or Google — forever. The values of innovation must be internalized. Innovation must cease to be an “initiative” or “tool” that can be cookie-cutter applied from elsewhere. Innovation is a way of life and a set of values that take years to evolve. Telcos need new religion.

Ameche enables applications to run “in a call” hence the Ameche moniker: “Apps in your Calls” (a Voxeo trademark). It’s a great addition to the existing Voxeo Labs programmable voice products (e.g. Tropo), but this time aimed at operators to allow them to offer programmable-voice capabilities on existing subscriber number ranges.

I’ll say that bit again – on existing numbers!

I just hope that it comes to an operator near me sometime soon…

I built my first telephony app back in the late 90s when I founded one of Europe’s first mobile apps companies. We hacked a Dialogic telephony card in the back of a Windows server in an attempt to build our own PBX solution connected to an instant messaging app that we built atop of MS Exchange. We also built a crude CRM (ASP app) for logging sales calls. It seemed like “programmable voice” was just around the corner.

For serial inventors, deja vu is a common experience. In Ground-Hog-Day fashion, we often feel like we’ve had the same conversation over and over. When IMS was invented, some of us got excited about “programmable voice” in the network. The IMS standard included an Application Server concept. It has various configurations, including the ability to allow an application to sit “in the middle” of a SIP call.

I wrote a conference paper (sponsored by Wiley) solely about this concept, which later became a chapter in the 2nd edition of my Next Generation Wireless Applications book (2004/6).

My favourite app idea at the time was a taxi-hailing application. The concept allowed a caller to dial a generic “TAXI” number and automatically be routed to the nearest available taxi. Or, as it was supposed to be an IMS app (with it’s associated IM apparatus) the cab could he hailed using an IM client. Again, the message popped up on the nearest cab’s device.

As Motorola’s Chief Apps Architect, I ended up building the taxi app atop of an Asterisk server whilst running the “Mashing Room” lab for their nascent apps vertical. It was part of a variety of use cases that we used for IMS presales, mostly unsuccessfully for all the usual (carrier-myopia) reasons.

Roll on a few years…

I tried again with Telefonica/O2 when I proposed and led a “platform initiative” that included exposing the subscriber’s text message stream in the same “in the middle” fashion, via an experimental service and API called #Blue, about to be closed (as the capabilities are going to become mainstream inside of a more production-ready platform).

I then extended this to a wider platform vision called connFu, aimed at exposing the call stack, messaging stack and associated real-time streams (e.g. Twitter) via a single API set (initially exposed via a Ruby DSL). My understanding (I no longer consult for Telefonica) is that the concept has been re-imagined as part of the Tu Me platform, although not exposed to external developers.

Voxeo Labs has succeeded where Twilio hasn’t in bringing a solution to the gargantuan market of existing mobile subscribers by offering a well thought-out carrier solution. This is to be expected because Voxeo Labs combines the carrier-grade product experience of the parent company (via its high performance Prism SIP product) with the developer-friendly experience of its Tropo platform, which already powers a ton of apps.

Besides the four use cases mentioned on Ameche’s landing site, the possibilities for programmable voice really are endless. The so-called “death of voice” (not profitability)  has been greatly exaggerated. Whilst it is interesting to note that, as an evolutionary adaptation, we have become much better under various circumstances in communicating via our finger tips and thumbs (tapping on keyboards) than we have with our mouths and ears, voice remains a central human experience.

The problem has been that innovation in voice communications has not been possible. Even Apple’s attempts (via Visual Voice) were largely unsuccessful. However, with the right ingredients, innovation is possible. The question remains as to what are the right ingredients.

Clearly, programmability is only one element. Ameche ticks that box.

Next, we need low-friction adoption, which mostly comes from allowing users to use their existing numbers. Ameche ticks that box too.

So, what else?

Well, we still need the right circumstances and environment to attract developers. This is a complex topic. As we’ve learnt over the years, the developer “market” is just as segmented, if not more, as any other market. Ironically, it was a carrier that brought this to the attention of other carriers when Telefonica’s BlueVia project sponsored VisionMobile to produce the “Developer Economics” survey/report.

Different segments behave differently, but across the board, they all reportedly seek the same thing from any platform, which is market reach. Within a carrier configuration, developers usually baulk at the idea of a solution that only works with one carrier (where adoption is asymmetric). So, we must hope that Ameche is adopted by multiple carriers and/or that the API is open and adopted – de facto – by other carriers atop of their own solutions (e.g. Telefonica’s Tu platform, if it ever makes its way into the BlueVia family of APIs).

Again, somewhat ironically, Telefonica has shown initiative in their ability to partner with Telenor to form a single developer-facing co-operative under the BlueVia banner. What we need is a combination of this pragmatic approach (versus the WAC-y way) and wide scale adoption of Ameche or Ameche-like APIs. We might just see a runway effect. Let’s hope so.

Regarding the asymmetric adoption issue, I think there is a difference in this case, although subject to how well carriers promote and execute Ameche as a carrier service. The difference is that developers have never before been given the chance to play with the voice stack that powers their phones. It might just stimulate enough curiosity to provoke the sort of “playful” innovation that often drives early adoption of key platforms. Carrier readers would do well to read my recent book (“Connected Services“) that explores the platform paradigm in some detail, and from a carrier perspective.

In terms of economics, I think that the sweet spot will fall in the SME/Enterprise category where developers ought to be thinking in terms of monthly subscription models. This is where the billing/payment models need to be well thought through by the carriers. We can only hope that they avoid their historical tendencies to think in terms of short-term revenue targets that are out of line with seeding a long-term successful platform play.

I look forward to Ameche being available in my carrier’s network soon.

If you work in a big company, especially a carrier, then you’re used to the treacle-flow pace of progress. If you’re working on a new product idea, especially with a degree of uncertainty, you might want to try the so-called Lean Start-up method EVEN THOUGH YOU ARE NOT A START-UP!

I’ve set-up, run or advised several “start-ups within an established corp,” including Lucent Technologies, O2, Motorola, McLaren Applied Technologies and Art.com.

Applying “Web and start-up” patterns/methodologies to bigger companies is kind of my thing. I wrote a book about it for carriers.

According to Eric Ries, a start-up is:

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.

Embracing Failure

Carriers have been building all kinds of digital products with varying degrees of failure (from 0 to 100%).

You see what I did there?

I used the f-word.

It cropped up in a conversation I was having with the CFO of O2 UK whilst consulting there in 10/11.

Here’s the slide that got him excited:

What I was trying to explain was that for certain types of product development, the so-called “Lean startup” method might be more efficient in figuring out that a product will work, or not, before spending millions on traditional product life cycles.

Carriers have a long history of spending lots of cash to bring various digital services to market that quickly tank, even when based on sound customer insights (more on that later). They key idea to grasp is understanding when your project is a “start-up” in the sense that you DON’T KNOW whether the product idea is the right idea.

What you’re really doing is experimenting. Failure is highly likely, so you need to set the project up to allow rapid iterations of the core idea until something resonates with users, whatever criteria you use to measure that (see, for example, McClure’s AARRR metrics for Web)

The key point of the “Lean startup” method is not to build a product, but to discover a product.

Getting back to the O2 story, I led a project to try the method inside the huge mothership (O2 is a BIG company). Using a small team of software developers in London, we built a service called #Blue (“Hash blue”). It was used again to build another service, called connFu.

Lessons Learned

The #Blue story is a long and exciting one. Honestly, I’ve rarely had so much fun building a product inside of a big company. And O2 isn’t just any company – it’s the UK’s best carrier by far.

Innovators like me don’t get to experiment inside of big brands that often, not unless there are a few visionaries — and renegades — running the shop, plus someone to clear all the usual corporate crap that sticks to your chaps whilst trying to sprint to the finish before keeling over from all the crud. This is my first lesson.

Lesson Number One: “Hire” a “Hurdler”

Stephen Devereux is one of my heroes. He has a long and successful career inside of O2, including helping the launch of the iPhone after O2 won the exclusive with Apple. He was the “hurdler” (sometimes also called “shit umbrella”) whose job was to line up all the green lights for the project, like those small details called money, contracts, resources, etc. He had a foot in two camps: the “mothership” and the “renegades raft.” It is a rare mindset.

Lesson Number Two: Avoid “Prima Donna Syndrome”

What I noticed about Steve’s approach was a very simple observation: it pays to talk to people in advance and to give them a reason for why you want to do things differently. For example, we wanted to “break the rules” when it came to vendor selection, so that I could recruit a small software team in London who weren’t part of the O2 supplier family.

Despite having board-level blessing for the project, Steve didn’t just demand things, like he had a right to them – he went and spoke to the various departments (like purchasing) ahead of time and explained what we were trying to do and why (giving a reason always helps when breaking convention).

If you act like you’re the bees knees with your fancy innovation project, treating everyone else like old-school oafs, then you’ll soon realise how easily the mothership can swallow and suffocate your tiny insignificant attempts to be different. You don’t have to act different to be different – remain nice to people and tell them what you’re trying to do. It’s a lot more productive.

Lesson Number Three: “Stay on Point” (Or, “Ignore the F*ckers”)

Once you head off down the lean start-up pathway inside of a large company, you can expect resistance. There are all kinds of distractions. Of course, there are the usual suspects who don’t like that you’re doing something new and different, in case it proves that the “old way” is wrong. They want to shut you down, or – worse still – make sure that you fail so that the “new way” will forever be tarnished and then banished from the kingdom. Ignore them!

However, these to-be-ignored folks aren’t the real threat. Their objections are usually out in the open. The really dangerous folks are the supporters who default back to type by trying to add in traditional “customer insight” requirements, or any requirements at all. The problem with listening to them is that you start to pivot your project around their feedback rather than real customer feedback, which is the essence of the lean start-up method.

Don’t feel tempted to please your lukewarm supporters by bending to their requests. Stay on point!

Lesson Four: Move fast towards the unexpected

It’s always easy to find an intellectual reason why something shouldn’t work. In fact,  corporate projects suffer this kind of paralysis all the time. You know the routine. Three of you head off down a path that looks fruitful when a 4th guy pops up and says: “Yeah, but that won’t work because of X.” And then a 5th person chimes in.

Before you know it, everything looks doomed. The real problem here is that you end up trying to move forward in a way that caters for all opinions. Many well-intended innovation projects die this way.

In my experience, you need to run as fast as you can to get something in the hands of users as quick as possible and get real data and real experiences to guide your path.

Remember the adventurer’s maxim:

Unintended consequences dominate.

I learned that early on from my management hero Tom Peters.

In other words, you mustn’t only expect the unexpected, but you must run as quickly as possible towards it.

Something will happen that changes your perspective altogether and then the 4th, 5th and Nth person’s opinions become moot.

Lesson Five: “Hire a skeptic”

So I said that you should ignore the skeptics, but I was kind of lying to get you rapidly down the page here (following my own advice to move fast). Thinking ahead to the end-game, if you’re running a “start-up” gig inside a bigger entity, sooner or later you’ll have to go win the hearts and minds of the mothership skeptics who didn’t really want you to succeed.

If you simply turn up and say “da-dah,” presenting the results, it’s going to be difficult for them to say “OK, you were right and we were wrong.” The way to avoid that is to recruit one of the skeptics from the start, asking for them to come along for the ride, slowly positioning them to take the credit if and when you gig becomes a success.

Aim to recruit someone lower down in the organisation, like a product manager (rather than director), who is well respected by his or her superiors and peers. The objective is for your recruit to sell the success and methodology back into the mothership. That’s not your job. Your job is to make the process work. Stay focussed on that.

Lesson Six: “Keep a safe distance”

Other than hiring the skeptic from the mothership, and then managing the other mother-daughter relationships via your “hurdler,” you must keep your team far enough from the mothership that you can push on without hinderance.

The one thing about any large group of people, and companies are no exception, is that there are as many opinions as there are mouths to utter them. Opinions take too much time and energy.

If you’re running the gig, then you must have a strong mind and a good deal of confidence in your product ideas and following the pivoting process to discover the best configuration.

A “safe distance” means keeping the main team away from mothership distractions, but not so far that you’re out of sight. If you disappear from view, that can become a problem. Worse still, if the distance has a whiff of “we’re too good to sit/work with you luddites,” understand that they will shut you down!

Conclusion

Most of the lessons above are related to how to apply the “start-up” mindset inside of a large corp. The so-called “Lean start-up” approach is only one method and it only applies to certain types of digital products, mostly Web-related. Other techniques I’ve tried are internal ideas markets, innovation contests, incubators (e.g. I ran the O2 Incubator experiment), “labs” and various others. There are a lot more lessons to share.

The problems are never with the methods, but with “managing” the mothership. Therefore, you have to understand that your job as an “intrapreneur” is a lot different to the classical founder role. You have to do all the “founder” stuff whilst acting as a change agent inside the mothership. It’s a tough gig, but can be very satisfying, especially when you manage to align the stars of “small company innovation” with “big company power.” The project can be fun and the results awesome.

In the major rewrite of my first book “Next Generation Wireless Applications,” I added “Mobile 2.0″ to the sub-title and described what I thought it meant, which was namely the intersection of open mobile APIs, client and network, plus Web 2.0 “programmable web.” This cocktail allowed for “programmable communications” using developer-friendly APIs and technologies.

I later refreshed the idea with some real-time aspects and details of the various device and browser API possibilities that I expected to emerge. Some of these now have, like the WebRTC work.

Returning to 2005/6, whilst Chief Architect at Motorola’s mobile labs in EMEA, I had my team build various voice mash-ups to demonstrate the new world of “Web/telco convergence.” Naively, I thought that this new world would be propelled by the advent of something called IMS (which telco guys will know well and Web guys will go “huh?”)

For the uninitiated, IMS was a new core technology for mobile networks that would replace older signalling protocols with the spiffy net-friendly SIP, which conceptually has a similar programming model to HTTP.

My “Mobile 2.0″ vision was predicated by the assumption that telcos/carriers would open their IMS networks to allow developers to access the SIP signalling in order to “chain” all kinds of interesting services on the back of telephony and messaging flows in their networks. This never happened. Carriers either didn’t invest in IMS or, those that did, failed to leverage the technology to create an open ecosystem, or, more accurately, a platform.

Roll on quite a few years and the word “platform” had become vogue amongst Web innovators – “build a platform,” many cried. Of course, platform (or N-sided) business models were not new. Commercial TV is a platform business model – the viewers get it for free and the advertisers (the real customers of TV) pay for access (to lucrative commercial slots).

The platform idea was heavily influenced by the success of Google who realised that an N-sided business model was the monetization secret that search had been, well, in search of: users get it for free, advertisers pay. If only Web innovators had been paying attention to the so-called “bricks and mortar” businesses, they would have discovered this sooner. The model is old, but the scalable potential is new because of the so-called “long tail” benefits, which means millions of advertising slots versus only a few on commercial TV.

Later on, the “Telco 2.0″ guys went crazy about N-sided business models, as if they too had just discovered the idea. Fair dues to Torrance et al, as I think that the concept was probably very fresh for most carrier folk used to the single-sided business model that has dominated the carrier world for decades.

When I consulted for O2 UK in 2009, I promoted the theme of open platforms to the board and got the CEO’s blessing and funding to build an open voice and messaging platform, which I called connFu.

Because O2 lacked an IMS infrastructure, the idea was to leverage the software-centric capabilities of Telefonica’s recent Jajah acquisition, a mobile VoIP platform built on SIP. This aligned with my other consulting theme: Software DNA, which I believe is an essential asset for any modern digital company, carriers included.

Meanwhile, on the other side of the world, a little start-up called Twilio had entered the configuration, touting their voice and messaging APIs. Their CEO, Jeff Lawson, had got so sick and tired of trying to add (carrier) voice to his apps, that he decided to do it himself by building a set of APIs to work atop of  wholesale VOIP networks.

Whilst on a trip to Twitter’s Chirp conference, I took an O2 senior executive to visit Twilio and see what they were up to. The anti-telco vibe was palpable, but this may well have changed now that Twilio have probably realised that you can’t quite become a next generation “Web-carrier” without talking to the other old-school carriers who are good are charging lots of business folks for their services.

While all this is going on, the guys at Voxeo, who built Tropo.com, have been quietly building up their presence in the voice API world – and with a solid understanding of carriers (gained from their classic IVR business). I don’t think it’s any secret any more that the connFu project at Telefonica/O2 was built with Voxeo’s help and technology. I think that the partnership has been valuable in helping to think about how to partner with carriers at this interesting intersection of carrier-scale with Web-speed.

Telefonica are a big company. And, like all big companies, there are various currents and counter-currents of energy. The BlueVia platform is one of the best carrier developer programs out there and a great source of platform energy in the carrier world.

I bump into numerous (competing) carrier execs who tell me that BlueVia is number one. Apart from its innovative business models, BlueVia is one of the few programs that managed not only to avoid turning developers off, per usual carrier antagonisms, but to turn some of them into fans – a tall order for a telco.

BlueVia are still the ones to beat, but should try to get ahead of the game with some serious voice-API capabilities. They clearly did something right because Twilio hired away their marketing director (James Parton).

The birth of Telefonica Digital apparently reset objectives a little, away from the BlueVia open platform concept and back towards trying to “compete” head-on with OTT-like services, such as via the recently launched Tu Me. It seems that the part of the business that controls the priorities for Jajah didn’t really grok developers and the open platform thinking. Sadly for me, at least as connFu’s inventor, the connFu idea has stalled.

The interesting and exciting development is that I know of at least four major carriers across the globe who are now getting ready to release voice APIs and essentially copy the connFu concept that Telefonica pioneered.

The whole rationale and story for open platforms takes time to appreciate. The strategy is simple, but the execution is complex. It is not an obvious “quick win” that carriers are used to backing, based on their quarterly numbers mentality.

However, carriers have had time to mull it over and realise that platforms probably do have a role to play in their future. How big and how significant, nobody knows.

And that was always the point. When I consulted for O2 and Telefonica, I was clear that as there were no easy or obvious answers for innovation, the smart approach was to construct an agile organisational capability that would enable the innovation to take root. I argued – and still do – that much of this could be done by the clever application of modern Web paradigms, patterns and technologies – like open platforms and software DNA.

By using the best of Web ingredients — but within the context of being a carrier — telcos can do a lot to reinvent themselves. Of course, this is only one pillar of a wider strategic vision and plan, but a significant one nonetheless and not to be overlooked. It seems that carriers are finally understanding this, which is why my latest book, Connected Services, is so timely. It documents the modern Web specifically for a carrier audience, including platforms thinking in its various forms.

[Paul Golding is a leading expert on carrier innovation, specifically when it comes to applying modern Web paradigms to achieve agility and growth. Unlike various commentators and theorists out there, Paul has dug deep in the trenches to actually execute numerous initiatives at the intersection of Web and Telco worlds. Paul offers various strategic consulting packages to senior carrier executives who are serious about transformation.]

I spent some time with O2 UK promoting various “Big Data” themes within their technical and product teams, including some hands-on product experiments using MongoDB, one of the so-called NoSQL, or document-store, databases.

Using “lean start-up” techniques, modified for a big corp, I led a project to develop a cloud-storage product, called #Blue (see hashblue.com), that could store all of a user’s sent and received text messages in real-time (and also expose them via an API, which was a core part of the experiment). Please watch a video showing how we did it.

Of course, “Big Data” is a much bigger gig than storing data. It’s all about the processing and the ability to extract value-added meaning for users, both external (O2 customers) and internal (business stakeholders).

A common reaction from the CRM-folk was that they already “did Big Data” with their data warehouse projects and so on. Of course, this is true, although we rapidly get lost in semantics if we’re not careful. An overriding feature of the “Big Data” meme in the realm of start-ups, Web ventures and open source software, is how accessible and cost-effective the technology has become, thereby enabling (and causing) various disruptions to bigger businesses.

My intention with O2, and other carriers I’ve consulted for, has always been to search for ways in which they can utilise rapidly-moving Web technologies, paradigms and patterns. I believe that I’ve had a large degree of success, which I will cover in ongoing posts on this blog.

Indeed, O2 now uses “NoSQL” technologies to supplement their CRM and general data-processing needs, and – more importantly – created various initiatives to build new business ventures based on extracting new information from deep within their tremendous data flows and stores, many of which are like untapped oil streams packed with latent value.

My latest book – please see Connected Services – is a “tour guide” for carriers interested in educating themselves in modern Web methods and paradigms, both technological and economical. It contains a detailed discussion of “Big Data,” within the context of the carrier landscape. Thanks to those many who have already read it and given me valuable and encouraging feedback.

For those who want to go a level deeper into the new database technologies that drive various aspects of the “Big Data” trend, I recommend reading Seven Databases in Seven Weeks from Pragmmatic Programmers. It offers a more technical in-depth tour, one level below my explanation of the various underpinning paradigms, covering: Redis, Neo4J, CouchDB, MongoDB, HBase, Riak, and Postgres.

What I like about the book is that it describes the core technologies and how they differ, plus it takes practical examples to explore the applications in more depth. For those readers of Connected Services, wanting to explore the next level of “Big Data” technologies, I thoroughly recommend reading the book.

My whole pitch was about the virtues of (a large corp) adopting and adapting various modern Web patterns and paradigms, biz and tech.

The idea still has legs. For those that want to know how to run, I wrote a book about it.

After a few sessions with senior stakeholders, I was asked to finds ways to “increase innovation” throughout the company.

It was a departure from my previous roles where I did the innovation, not cultivated it amongst others, at least not overtly. I now wore two hats: Innovator and “Innovation Evangelist.”

I discovered and documented a number of possible changes, among them the notion of creating an “ideas market” within the company. The logic was simple: “lots of brains work here – why not use them to create new stuff?”

The general enthusiasm for “crowd sourcing” swept my proposal along. Before long, O2 had engaged a market leader (Bright Idea Inc.) to provide a cloud-based ideas management tool. The same tool was already used by various big “tech” names, including Cisco and HP. That too was encouraging, as the meme of “let’s become a technology company” had started to spread throughout O2.

The meaning of the label “technology company” was subject to a raging debate that probably continues, not just at O2, but at many carriers and companies who similarly invest deeply in technology, but don’t create anything technological. I recently discussed the “software DNA” aspect of this argument in a guest post on Vision Mobile’s blog.

Once launched, the ideas tool was promoted to the O2 staff via various campaigns, managed by an “Innovation Manager,” specifically assigned to oversee the process.

Later on, as an experiment, I used to the tool to run an Innovation Tournament following the methodology documented by Wharton Business School professors Christian Terwiesch and Karl Ulrich in their book and website.

To cut a very long story short, one full of twists and turns and various fascinating insights, the biggest lesson that I’d like to share is in the failure to create an “ideas culture,” which is what I had set out to do.

I should hasten to mention that the project itself was not a failure – quite the opposite. The process produced many ideas, of various sorts. It also had the useful side-effect, one I had hoped for, of increasing employee engagement, although this was aided by a number of associated tools that we promoted concurrently, including Yammer, the enterprise equivalent of Twitter.

It wasn’t until I recently started consulting for a Silicon Valley company – an early dot.com success story – that I realised how hard the goal was that I had set for O2. Again, I found myself in the midsts of a mature company with an established culture.

This time it was a technology company, although that is also being debated (more on that another time). My role is to provide the technology vision for the next 3 years. I know, folks will tell you that you can’t envision that far ahead, which, of course, is nonsense.

Skipping the details, the engagement has involved me working largely independently of the existing technical staff. I have done the usual things, like interviews, observation and so on, but most of my work has involved building on a set of ideas that are “my own.” There are no crowd-sourcing initiatives or ideas markets in sight.

What I’ve learnt from comparing these two engagements is that there’s a time and a place for internal ideas creation versus external stimulus. The ultimate goal is not just to generate new ideas, but to implement some of them. The scope of what you’re trying to achieve with ideation must be considered in relation to the method.

If the scope is to improve employee engagement and motivation, then the ideas market approach can work wonders. My advice for launching an ideas market is to limit the scope to what we might call “incremental innovation” if there isn’t an ideas culture already in place. If you want to find the “next big thing,” which means thinking of a brand new product or service line, radically different to what you have today, then ideas markets will struggle and there will be a danger of implosion as the method fails to deliver any big ideas.

If you’re determined to involve employees in radical innovation, then I suggest a hybrid approach. This is something I tried with an Innovation Tournament inside O2. We gathered ideas from both internal folks and a hand-selected bunch of external folks with key skills and insights. Interestingly, whilst the approach produced some great ideas, it’s most valuable outcome was robust external validation of internal ideas.

For radical innovation, when the internal teams are stuck, using external consultants, advisors and mentors works. Depending upon the existing culture, you should be careful about how you involve existing employees in the ideation process. It is often better to get their inputs, in a controlled fashion, than to involve them in a free-for-all ideation process. Of course, you will need their buy-in later on to build or support the ideas, but there are various ways to achieve that without depending upon them to source the actual ideas.

In summary, it is a good idea to build an “ideas culture,” if your primary goal is to increase employee engagement and to improve incremental innovation. If your primary goal is really to discover big new ideas, then don’t fall for the “crowd sourcing” approach just because it’s become a fashionable meme on the Web. Where an ideas culture doesn’t already exist, it isn’t necessarily such a good idea to try building one.