If you followed me till now through the seemingly nonsense journey of how and what, well you are in for a surprise. Today I answer the question that has troubled generations of men. And if you wish to know my qualifications for making these esoteric statements, ping me.

How often have you thought about WHY? Why does this always happen to me? Why today? Why couldn’t my boss wait till my anniversary was over to drop this extra shit-load of work? Why don’t women understand us? As the questions probably show, why most often exacerbates problems (for e.g. asking your wife why did she spend 200$ on a new nightgown) or is used to vent our frustration. And here I am, the stubborn, haughty know-it-all claimant who says the Why is the answer to What (which I may remind you will eventually lead you to how). But stick with me and sense will surely ensue.

To make sense out of nonsense is pretty simple in most cases, just put things in perspective. Apply a context. For the sake of this discussion, I’ll apply the context of program management (for those oblivious to this great of art of handling people and technology simultaneously, refer to aMicrosoft College Website or even better What is a Microsoft Program Manager).

As a program manager at Microsoft, it’s my job to figure out WHAT. What are the customer requirements? What scenarios will the user use this feature? What is the schedule for the feature? What milestone of Windows will this feature ship? What do I tell the dev and what should I shield from them? What are my goals and commitments for next year? And how do I go about answering these questions? By asking and answering the question WHY. Why do the customers need this feature tells me the pain they are facing. This allows me to formulate user scenarios that the user will use the feature and drive requirements from them. This aids me in tackling the problem the right way, by having cause drive the effect (you’d be surprised knowing how many times, especially in the software industry, that it happens the other way round). Why do I need to ship this feature in this milestone tells me what features my feature depends on and features that depend on mine. Answering Why do devs need to know this (or not know) helps me tailor my spec (for the uninitiated, it stands for functional specification) in the right level of abstraction so that I don’t make it too high-level (devs hate pure biz talk) or too detailed (I’d be intruding on dev territory then). This is something they don’t teach in a trianing course (the courses are really helpful, I’m not undermining their value, but explaining this simple rationale would do wonders, IMHO).

But this does not imply that WHY applies only to program management. It transcends all human interactions and behaviors. Just think about WHY in a positive connotation. Contemplating why my girlfriend always complain about me not giving her enough attention tells me what I should get her for our imminent monthiversary (n. pl. monthiversaries - the monthly recurring date of a past event, especially one of historical, national, or personal importance). So whenever, you are fazed by a WHAT problem, always give WHY a try. It may be worth your while.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights