Why Patriots coach tossed Microsoft’s Surface

If there was ever a better argument for focusing more on the deployment of a technology than on the technology itself it was when Bill Belichick tossed out his tablet and went back to using hard copy pictures. Boy can I relate. I’ve been there myself. I don’t care how good the technology is, if the deployment is bad it doesn’t matter what the hardware is, your experience will suck. While moving back to paper is perhaps a tad extreme, sometimes you just want to slap the related IT folks around but it often isn’t their fault either.

[ Related: Patriots coach Bill Belichick benches Microsoft's Surface, says it's undependable ]

If you read Bill’s comments it appears clear some nimrods (technical term) got involved in the process and damn near destroyed the quality of the effort. If I were him, I’d have either gone back to pictures myself or gone looking for those nimrods and found them new jobs hopefully working for someone I really didn’t like.

I think there is an excellent lesson here, so let’s explore it.

Don’t forget the user

I can’t tell you how often I run into situations where the technology gets tossed under a bus even though the real problem is that, somehow, the needs of the user were forgotten. Bill Belichick is a coach and he is a successful one. Any tool that he uses during a game affects how he and his team performs and, if he loses, even if his technology lets him down, he’ll be blamed for the loss. This means that the technology can’t fail, whatever else needs to be done is secondary to making sure his tablet is at least as reliable as the paper solution he was forced to replace.

Now let’s stop there for a moment and point out that this solution wasn’t created with Bill in mind, and it is clear he didn’t request it and that this technology was forced on him. Any user you do that to will likely be looking for reasons for it to fail. That raises the risk for the technology provider to make sure that folks like Bill need are sold on the solution or eventually they’ll find a reason to reject it. The goal isn’t to just get Bill to use the technology, but get him to prefer it and, in this instance, that goal not only wasn’t met it isn’t clear that anyone thought it was actually a goal.

Now I’ve seen tablets deployed by the military in incredibly hostile environments that performed better than this deployment did.  

Promotional deployments

I was involved with one of these years ago and I swore I’d never do it again. The problem is that it is easy to lose track of the user because the user isn’t central to the development process, but they are absolutely critical to the result. Given the funding generally comes from the technology company, not the firm deploying it (because it is promotional), the folks driving the result on both sides are more interested in getting it done than in getting it done right.  

In my own case, the team supplied by the vendor wasn’t very good, our CEO who apparently didn’t have a clear or stable idea what he wanted drove the specification, and the end result moved from what I’d envisioned as simple and easy to a cluster of ever-changing SFO, CRM, communications, and increasingly insane specifications resulting in a huge mess. The people that were to use the project were outside of the loop and after a massive amount of wasted money we eventually just deployed a generic solution, which the vendor couldn’t effectively market as a success.

Page Break

It not only was personally embarrassing, because I’d pitched the idea in the first place, it was an incredibly unfortunate learning experience. Let me share with you the three rules I now recommend when doing a deployment like this.

Enderle’s rules for a marketing driven customer deployment

1. Don’t lose track of why you are doing this.   This means that the result has to be something both you and the user can be proud of. This isn’t about doing it as cheaply as you can, it is about creating a reference that will stand up to analysts and press asking the users whether they actually like what has resulted. If you end up with a user like Bill Belichick, publically throwing it out, you are worse off than if you’d never done it in the first place. Other customers will conclude that if it doesn’t work when you, as the vendor are paying for it, it sure won’t work if they are paying for it.

2. If you can’t set a solid specification and control the entire deployment, walk away.   My experience is that these things typically have too many people that aren’t users defining the solution. Bill’s objections appear largely connected to failures resulting from too little testing before each game and too little use between games. Any enterprise vendor knows better than to allow something like this to occur, suggesting someone in the NFL, who isn’t a coach and doesn’t understand the technology, set a requirement for testing and before-game implementation that was unreasonably short. And, given it was a stadium, which would typically have overloaded wireless networks, didn’t use an adequate wireless component to work reliably where and/or when it was used in a game.

3. Measure and own customer satisfaction and own customer advocacy. This is the payoff for any vendor driven deployment like this one. This is like saying for a typical sale “own accounts receivable” because, in this case, it is that customer loyalty and advocacy that is your payment for the deployment.   If this doesn’t result you can’t hire a collection agency to get it, which means this outcome needs to be assured from start to finish and even after the deployment is done because an unhappy reference account can do a ton of damage. In effect these accounts, because they are known to be funded, are far more powerful negatively than positively and it is easy to forget to keep funding them.

Bill’s problem with tablets could have happened to any vendor and, sadly, it isn’t uncommon with vendor-funded deployments. That goes core to my belief that is it is far easier and safer to take an already successful deployment and raise it up than to fund one, because if the customer is funding it there is less chance the user will be forgotten and the self-funding customer is vastly more credible.