As professional football gets back in the swing of things, I’m reminded of one of the iconic plays from the sport: the Hail Mary. You have to score, but you have no time left and you’re on the wrong side of the field. So, what do you do? You throw the ball way up and way far and say a prayer. Do or die; it’s all or nothing.
When I hear the phrase, “it’s all or nothing”, the risk-averse part of me just cringes. There are few things in life that are that absolute. I understand that some scenarios exist that are black and white and I can accept those. But my nature is to find the right shade of grey for the situation, especially in software projects.
I approach software projects as my nature: finding the grey matter.
grey matter: structures which process information originating in the sensory organs or in other grey matter regions. This information is conveyed via specialized nerve cell extensions, which form the bulk of the cerebral, cerebellar, and spinal white matter.
So, in non-techno-babble:
grey matter: part of the brain used to transport information from sensory and motor stimuli.
I find this a fitting description of the role I play as Product Owner on my projects. In the points that follow, when I mention the user of a product, this can mean your client, your client’s customer, or the end user of what you’re building. (By the way, there are debates on which of these is the right answer. Perhaps we can talk on that later.)
“Part of the brain…”
As the brain directs the body, the leadership team directs the project team. But the product owner is still simply one part of the team. They can’t do it alone.
“…used to transport information…”
The product owner is often the avenue in which information gets from the team to the user or vice-versa. All this information will help the product owner make sound decisions and allow for appropriate changes to be recommended. Along the way, there will also need to be some translation, either from marketing/user-speak to development or from developer techno-jargon to the user. The quality of this translation can make or break a project, thus why an experienced product owner is key.
“…from sensory [stimuli]…”
Sensory input in this context is what a user sees and feels. The product owner needs to be empathetic to the needs of the user. Where technical leaders sometimes just see the black and white, the product owner needs to inject the shades of grey needed to bridge the gap for the user.
“…and motor stimuli.”
Motor function alludes to what the developers are working on or doing for the project. The product owner has to ensure that the output from the developers meets the need of the user. Usually, acceptance criteria can be agreed upon before work gets under way. However, a technical limitation of the system may require a product owner to revisit the acceptance criteria slightly. Or perhaps a new design pattern emerges that can provide new value to the user. A product owner needs to be able to adapt for the situation.
As a product owner, I want to find just the right shade of grey so that my users can have the best product that is suited for them and their needs. By keeping the communication flowing, there doesn’t have to be an all-or-nothing effort to save a project. We’ll leave those heroics for the football field.
