As a Product Owner, I often ask myself “why” to the simplest of responses, processes, and assumptions to ensure that my understanding is well-rounded. My thinking is, if I can’t answer why something is/will be done in a certain why, then I need to do more digging and re-aligning.
I’ve often found that we, as a species, believe we want something without always understanding the full reason as to why. For example, a desire to do something may be motived on the surface with one obvious factor but driven by a totally different factor at a deeper level. This is usually because we are pre-disposed to various ways of thinking, like the classic “we’ve always done it this way” or “I haven’t seen work any other way”. My answer to both of those statements is always “okay, but why?”.
An example I encountered years ago happened when an end-user was unhappy with the functionality of an aspect of the software I was working on at the time. I spoke to them at length about the issues they faced and the reasons they gave were: “I have too much work to do something this manual” and “I have to be able to quality check every aspect of the work”, as well as “there are far too many clicks”.
My initial reaction to the statement of “I have too much work to do something this manual” was to introduce more automated functionality, to give the end-user more time. However, I decided to dig down into the root of each statement (one example is below):
- End-user: “I have too much work to do something this manual.”
- Product Owner: “Can you show me what your day to day looks like?”
- End-user: [Demonstrates a lengthy list of to-dos and paperwork]
- Product Owner: “Why does your day have to run like this?”
- End-user: “Time restrictions and deadlines.”
- Product Owner: “Why do you have such tight timelines?”
- End-user: “Set at a higher level, by an external company.”
- Product Owner: “Why do you start doing the time-pressured tasks when you do?”
End-user: “No access earlier on.”
- Product Owner: “Why?”
- End-user: “The external company does not provide it early enough.”
- Product Owner: “Could you start preparing earlier, knowing that it will happen eventually?”
- End-user: “Yes.”
- Product Owner: “Why would this help you?”
- End-user: “Always feel like I’m behind, which is stressful”
- Product Owner: “So is the main issue less about everything being manual and more about the lack of control of when you do it?”
- End-user: “Yes, I do need a lot of manual control, just dictated by my own timeline so it’s less stressful.”
The outcome of this conversation was really interesting because, without it, we could have built something that didn’t actually solve the deep-rooted problem; which was the lack of flexibility for preparation, meaning more stress and pressure down the line. Instead, we were able to come up with an easy solution, both for the end-user and developmentally, so that they could start managing their time better and do more of the setup up-front. Automation isn’t the answer to everything, especially something that has to be keenly analysed and scrutinised.
Personally, I know that there is usually a root cause to any thoughts, opinions, requirements or problems that come up in my day to day life and asking myself “why does this bother me?”, “why am I doing it this way?”, “why would doing it this way be better?”, etc. As an end-user of other Platforms and products, I also ask myself “why did they do it this way?”, “why wasn’t my use case considered for this?”, etc.
So the moral of the story is, asking why is a powerful way to really understand someone’s perspective and sometimes it’s worth going back to the root of our child-like curiosity; hopefully without our end-users feeling like a parent going in circles!