One of the over used terms, and may be rightly so in a professional sense, is “end-to-end”. Think end-to-end, understand how to deliver an end-to-end experience, work towards meeting end-to-end expectations and so on…While skills in actually delivering a work package/think package (when one works on a delivering a plan) are paramount, what is more important is perhaps to understand what is the problem being solved – 1. As it is stated/heard or 2. As it exists and as per who? As long as 1 and 2 match, one is in a relatively safe zone of landing the work package in a way that it meets with expectations, but more often than not, it is seldom the case. And if one does not put an explicit effort to understand if 1 and 2 match (even when they do, there is a lost opportunity in gaining experience of discovery).
And what if 1 and 2 do not match, as it is most commonly the case with most problems?
While there are frameworks in place and are constantly evolving to ensure that the gap between the stated obvious and the real problem is kept to a minimum(by sharing context, collaborative development, rapid feedback loops raising questions on “is this what we really wanted?”), it is not easy to apply this in the multitude of decisions that get taken during the course of day to day activities and gently introduce gaps along the way.
Unless, it is made as a practice in the way one approaches ones “response” to an external stimuli (fundamentally speaking). Let’s take a look at the picture below that describes a very simplistic use case of a requestor, requesting a report. Now, note that this requestor himself/herself is raising this question outside the zone of context (or in plain words, is not clear on why this request is being made!).
What if the request is responded with “a report” as asked by the requestor where 1 and 2 don’t match! A healthy disaster ensues much to the irritation of the responder.
While it is not always as simple as this, but most times, all it takes is asking (applause! applause!) a set of questions that will gently push the requestor back into the zone of context.
Discovering the background/context before a work/think package is delivered goes a long way not just in meeting expectations but also in gaining more trust with the requestor.
And sometimes, the journey in discovering context to a situation is not adjacent to be pulled out with a few fishhooks of questions, but takes deeper and more persistent efforts.