What about the guy-on-a-ship?
A long time ago in a company far, far away we had a meeting about a product migration. The concern: how do we get everybody with the old product a small amount of data to unlock an upgrade to the new product.
There was a quick discussion (blink and you’d miss it) of how it would work for 99% of the customers. Then something happened that made a scheduled 30-minute meeting run into 90 minutes with a follow-up scheduled. That something? We got sucked into discussion of edge cases.
It started with a legitimate (if highly unusual) existing case of a user on a ship in the middle of the Pacific for six months having a computer crash and trying to restore. We solved that fairly quickly. The interesting part was what happened next, though. The meeting devolved into a game of “top this”: what if guy-on-a-ship had no data connection? What if he had no voice connection? What if, instead of the hard drive crashing, his whole computer caught fire? You get the point – none of these scenarios had happened or were likely to happen, but much expensive managerial time (in what was supposed to be a review, not a brainstorming, meeting) was spent on thought exercises about what if they DID.
I’m pretty sure a lot of expensive time was wasted there. Guy-on-a-ship is a customer, and no customer wants to be called an edge case or treated as a burden. At the same time, keep in mind the diagram above – it’s the Pareto principle squared. If most of the discussion centers on only a few customers, your need is for a problem-solving session (with the few right and empowered people) for those few customers. Don’t hijack a policy review session (where most of the many attendees will have no input) for that purpose.
What about you? Have you ever hijacked a meeting to deal with guy-on-a-ship? Have you ever been in a meeting that was hijacked to deal with guy-on-a-ship? And have you ever BEEN guy-on-a-ship?