As a Voice of Reason

In compiling some thoughts on product management, I find myself fearful of seeming too critical. Its not my world and makes it seem as though I’m bitter from being assigned too many tickets. But in fact I’ve been lucky enough to evade a lot of the worst of the administrative side of software development. There’s also a natural bias to be avoided in technical writing to default to criticism. Developers love complaining. I, as an individual, am prone to complain. So when writing on something within our industry, its very easy to slip into a mode where you point out only the imperfections. I say this because this is one topic I absolutely do not want to seem like I’m criticising individuals on. Its much worse than that - its advice.

I want to acknowledge one more psychological reflex: we categorize. As humans (doubly-so as developers), our reflex is to put things in boxes. This person carries out X duties, therefore is an X Engineer. This person over here, they’re a Y Specialist, therefore they must carry out Y duties. Every workplace will define roles somewhat differently but the wide umbrella that is product and business management, ownership and analysis is so broadly defined that I rarely have any intuitive idea what that person does until I work directly with them - and even then it can be hard to define.

In my mind, there is a role somewhere out there in the aether, maybe already being unofficially, unintentionally performed, that provides massive value. This figure acts as an intermediary, diplomatically bridging the gap between two sides that we’re told must never directly communicate: business and development. A dignitary that accepts the words of the business, parses their foreign tongue, determines their hidden intents and translates them into the binary data fed into a slot in the back of the developers’ heads. Conversely, this same sentinel can converse with the machine people, relate their experiences to their own, understand what is possible and in turn, relay their concerns to the business. And back and forth this dance continues, until shovels strike earth and life is born. And all this without the use of User Stories.

Product owners are in a position to bring this level of value to a business. But over-reliance on procedure and format diminish the role’s returns.

Be Useless

As a [voice of reason] I want [you to dissolve your ego] so that [you may become better at your job]

Let go. Turn off your mind, relax and float downstream. Relinquish your grip on the requirements gathering template and you might hear what the process expert is telling you. You might be able to hear the words they’re not saying. To suggest one throw away all documentation is lunacy but just make sure what you’re using makes sense for the environment you’re in. Agile teachers will try to tell you that their methodology fits all, but you have to stay nimble (that’s right) and discard what isn’t working over time. If that tired old user story sentence structure isn’t working for you anymore, boot it out the window.

To mention another psychological reflex, which is to justify ones existence. Nobody wants to their role as variable, soft or hard-to-define, but sometimes thats just the case.

Owning Ignorance

In most jobs, you’re expected to have a comprehensive grasp on the mechanism in front of you, and the justification behind it. As a product owner you’re in a position where its actually better if you at least feign ignorance of both. Leave preconceptions at the door enter into any new project as a child witnesses the world. Communication is now your mechanism and improving processes is your justification.

Ask the stupid questions you’re afraid to ask.

I’ve also read about the percieved split between product management and business analysis and would love a world in which the role required enough technical knowledge or experience to be able to provide both perspectives. As long as the individual can remain impartial in their technical analysis, the experience can provide massive insight.