Communication is the single most important thing whenever and wherever people interact. Communication is the key to great relationships both in business and also in personal life, however it seems like it’s also the hardest thing to get right.
When a software product evolves, between the birth of a good idea, the formalization of a change request, the analysis of the impact, possible solutions and the eventual addition of a new, meaningful feature that adds real value, many things can go wrong. Loads of different people are involved in this process, every single one with their own desires and expectations, which do not necessarily align with the ones of other people in the process. So how can we make sure that we get things right in the end?
Why?
‘Why?’ is the single most important question throughout the development cycle of a feature. For sure there’s a reason why ‘why’ is at the center of the golden circle, why the five whys are such a powerful technique for root cause analysis. But… why?
Whenever we get a new feature request, the first question inevitably is “Why do you need this?”. People that request new features usually just want to get their work done, but they don’t really care about maintainability or extensibility of a piece of software they use. Sometimes this first “Why?” already leads to a solution that doesn’t even require any implementation effort, surprisingly often due to the XY Problem. The rest of the time it brings us closer to what the person posing the request really wants, and often it also improves the final outcome.
Use Cases
The goal of this initial cycle of “Why?”s is to discover their real use case. A real world scenario with a desired outcome. A dumbed down and condensed example with roots in the real world between a User(U) and me (M) could be:
U: I would like to have the
foodatapoints displayed to nanosecond precision.
M: Why do you need them to nanosecond precision?
U: There are very important situations when I need to comparefoos among themselves.
M: There are over twenty of them visible at all times, even more if the user increased the amount. In the UI it will be impossible to compare them in a meaningful way. Why do you need to compare them?
U: Yes, but in this specific instance I need to calculate the deviation between each point and the one before plus a constant.
M: Why would you need to do this?
U: There are situations where a delay is unavoidable, but it is crucial to identify allfoothat are outsideprevious fooplusconstantrange, as this will require manual intervention by a technician on site, otherwise$companiesusing our product will explode if not handled within 3 hours.
M: Oh, so you need to reliably manage the situation whenfooin theXYtimeseries exceeds a threshold based on the previous foo that requires attention by an actual human.
What if we set up an integration with our automated notifications service monitoringfooaccording to your criteria, such that the right people will be immediately notified?
Also – if still required – we can ask the designer about a nice visualization of the delta values if we’re really interested in the actual values.
U: *surprised Pikachu face*
What the user asked in this example was a thing that he sincerely thought would be the best solution in his situation, but solutions are always a bad place to start. When starting from a solution, we are usually biased and often miss the big picture.
The most important thing in this phase is to discover the use case, which we reached after the third “why” in our example. It may be formalized similar to:
To avoid $company exploding, whenever force majeure causes
foo>previous foo+constant, a service employee needs to be dispatched on site and execute a manual intervention.
No mention of UI, Technology, or proposed solutions. Starting from this, in this instance, an outside, high-level view on the entire ecosystem, paired with a few well placed “Why?”s elevated the feature request from a possible UX disaster into a feature that can save entire companies from spontaneous combustion – with minimal effort.
Both for the asker, and also the askee to go through a seemingly endless cycle of “But why?”s, can be frustrating and exhausting. Misunderstanding each other is also a real risk, as there are many ways, to take turns in speaking, but not understanding each other. Reasons can be different viewpoints, different levels of experience, or simply different information available to each one. However, in my experience, pushing through the “why?”s until I’m sure to be on the same page as the asker always leads to the best result possible.
All in all, as you can see, features may even become a little bit more expensive implementation wise, but in the end we
- managed to be on the same page
- figured out the use case without prescribing or proposing a solution
- leveraged the combined knowledge and experience to come up with the best possible solution
Entirely by just asking more often, “Why?”.
Thus, my advice to you, is simply to ask yourself and others more often: “Why?”
Benjamin Gröber
Author
