I remember when my brilliant Nortel colleague, Yuri Shtivelman, coined the phrase, "audio is easy, voice is hard". His point was that all those who thought the hard work with voice was over once it was converted to an IP stream were about to find out how little they understood about voice communications as compared to audio transmission. Sometimes, you don't know what you don't know.
Fast forward to the present, and Andrew Seybold's recent review of Google's Nexus One launch: Google Repeats Wireless Mistakes. Andy makes a number of astute observations about Google's launch of its own phone, especially regarding the need to look at the device as part of an entire "ecosystem" comprising the device, the network which supports the device, and the applications which make the device more personal and valuable.
I won't reprise Andy's excellent article, but it appears that one big shortcoming was a process for sorting out customer support. It's a complicated proposition (as Google has discovered): you have a handset manufacturer (HTC), a retail distributor (Google), a network provider (T-Mobile), a device OS provider (Google), and applications providers (your name here) that are all involved.
News From a Fly On the Wall
So let's pretend we're sitting in on one of the pre-launch project meetings...
[Project Manager] "OK, do we have a support plan in place?"
[Google Support Team Lead] "Yep, no problem. We're going to handle this like our other services. We've got a series of FAQ's being put together that will help users resolve their own problems. And we've got a form people can fill out if they want us to respond directly to them."
[Project Manager] What kind of response time are we promising?"
[Google Support Team Lead] "Same as always, 48 hours." "If ever!" someone interjects.
How Did We Get Here?
If this exchange was close to the truth, it would be easy to say what went wrong. Where was the handset manufacturer? the network provider? If they were there, did they speak up? If they spoke up, why didn't anyone listen to them? It would be easy to think that customer support for this product would be handled like it had been for everything else Google ever offered.
So how could Google have gotten to this point? One possibility is that they didn't involve their partners in the support planning conversation. Maybe it didn't occur to the project team to do so. Maybe (more likely) they figured everyone understood that Google couldn't be expected to provide more or different support than they did for their other services.
Another possibility is that Google's partners were part of the support planning process, but didn't speak up. Anyone who has run a meeting will confirm that some participants are just not going to speak up unless they're encouraged to do so. For whatever reason, they don't feel that it's their place to interject, especially to tell you as project leader that your assumptions are all wrong. In my experience working with Original Design Manufacturers (ODM's), they take a "just tell me what you want" approach to the conversation. You can tell them you want to go to the Moon via Jupiter, and they'll tell you how they can do it... never suggesting that you might want to go directly to the Moon instead.
It could be that the project team anticipated the support issues that would arise, but felt constrained to come up with a solution that conformed to Google's existing support model. Maybe they were instructed to stick within that model. This would be a dangerous thing--someone higher up not listening to the team, or the team censoring itself and not having the leadership to put a plan forward that they knew was right.
We'll never know what really happened. And at this point, what matters is how Google responds. But what are the lessons for those of us charged with making sure customers love our products and services as much as we know (hope) they will?
Keep the Customer in Mind
This is one of those lessons that seems obvious--until you forget to do it. Play out the support process, and examine it from the customer/end user's point of view:
"OK, so the customer has a support problem with their phone... who's responsible for isolating the problem?"
"Well, the customer is. We don't handle that".
"How are they going to figure out what's wrong?"
"We'll provide some tips online."
"If their phone isn't working, how will they get to those tips?" etc.
You don't have to play out all the scenarios to see that things are likely to go wrong.
One of These Things is Not Like the OtherDepartment of Obscure References
This is a common problem, especially as companies move into adjacent markets, and as markets evolve. It's easy to expect that the "recipe" you've followed in the past will continue to serve you... Easy, but also dangerous. We're trained to look for and address issues when we roll out new products; the challenge here is looking for what's not there. The best way to do that is to engage team members who have experience in the areas that are new to the company or project. In Google's case, someone could have asked HTC and T-Mobile how they handle customer support. Another approach would be to see what Google's peers--Apple being a prime example--are doing in this regard.
On this last point, I'm a big believer in emulating the practices of others that I consider good "proxies" for the issues I'm facing. When I was at iPass sorting out how we would provide 3G data cards to our customers and end-users, I knew that (as a services company) we had no "corporate memory" to rely on to determine how to provide customer support. I had to reach back to my days at Nortel managing similar kinds of products, recalling the procedures we had in place for troubleshooting, Return Materials Authorization, advance shipment, and so on. When I outsourced iPass 3G card support, I was able to negotiate from a complete list of "what if" issues to make sure we could provide a positive customer experience.
Is This My Job?
The question of who on the project team is responsible to work out these kinds of issues can seem complicated. After all, there are lots of ways companies organize to bring products out of Engineering and into the market. Some set up dedicated project teams with assigned project managers. Other companies rely on each functional group to develop and work through their task list. In this case, we can assign the task to Google's Customer Support group, right?
Not quite. After all, Google's support team did come up with a support plan; it just didn't work the way people had thought it would. What was missed here was recognizing the interdependencies involved in providing end-to-end customer support.
But there's a simple answer to the "whose job is it?" question: "mine". Raising the question of "how's this going to work?" is the responsibility of everyone and anyone on the team... Precisely because the team might be relying on the wisdom of someone who normally doesn't speak up in team meetings.
Google's experience shows that even successful companies can get it wrong now and then (see: Toyota). Keep asking "what is it that I don't know here?" and you can make sure it won't be your project that gets unintended publicity.