Book Club: Wikinomics

I just started reading this one and am loving it. It can be dry and redundant, but the examples of commerical entities using mass collaboration are worth wading through a few moments of drudgery.

Pleasing the Customer(s)

When I worked in the mobile devices division at Microsoft we had an ongoing discussion about who our customer was for our mobile device offerings:

• The carrier (e.g. Sprint, Verizon, AT&T, etc.) upon whose network the device would run.


• The OEM who would make the hardware (Dell, HP, Motorola, etc.).


• The kid who would use it.


• The parent who would buy it for the kid.


• The department(s) within Microsoft which might profit from services sold through the device.


• The random executive or product manager who had an opinion of what features should be on the device.


• And of course: ourselves!

So which are the customers? Answer: All.

Customer: Anyone who lays a legitimate claim to directing your software development work.

Imagine how difficult it is to develop requirements for any one of the "customers" listed above. Now imagine creating requirements which balance all of the needs of the competing interests. Ugh.

We face a similar, though not so extreme, challenge in I.T. We have internal customers (typically product managers) who work for the departments we serve. They have their own management chain who have opinions of what work should be done and how. We have our own management chain which has its opinions. And then, of course, we have the end-users for whom we're collectively building the software. Pile on top the fact that "knowing what one wants in the software" is not an inherent skill. It's something most people think they do well, but don't.

So what to do? Here are some suggestions:

• Start with high level requirements. Make sure you understand what the goal of the project is. Stand firm on this point, and don't relent for any amount of begging, threatening or bribery. Get the value proposition documented in plain English and make sure your customers, all up and down their management chain, agree. Treat this with the utmost importance and respect. It will become your rock later on when disconnects occur between product managers and their management. The value isn't so much in having a tool to cover yourself. Rather, documented requirements help you help the customers get on the same page about what is expected.


• Always be an advocate for the end-user. It's your solemn duty. Whomever your customer is, they care about the end-user, even if they don't understand how to delight them. Use whatever tools you choose or have available: focus groups, usability studies, contextual inquiry, intuition, whatever. Just make sure you understand the user(s) of the system and that you champion them at every turn. Your customers will thank you (though maybe later).


• Use functional prototypes to narrow the "gap of misunderstanding" up front and get everyone on the same page about what is to be built.


• Prioritize your customers. Understand which is most important to satisfy and take care of the high priority features for the high priority customers first.


• "Just say no" to executive/management pet features. Executives appreciate those who "speak up." If someone in your management chain tries to get you to add or subtract features and you know in your toes that its the wrong direction, then push back! If you've said your piece with all vigor of heart and the answer is still no, then press forward--you've done the right thing by speaking up. If having done so becomes a "career limiting move" then you may have the wrong management anyway. I speak from experience. The people in our organization typically take great pleasure in pushing back on me.

Having multiple customers can be a great challenge, but when you mostly satisfy most of them (in priority order) you accomplish something which brings great satisfaction.