Software Delivery: Product Owner
Hello reader.
So you have stumbled across my post because maybe you have a desire to understand the role of a Product Owner (PO). It could be you want a deeper knowledge of how a PO can assist with Software Delivery. Just of note, I must clearly state that I am definitely not a master of this role - this post is more centred around musings based upon my own experience as a PO.
Here is the TL;DR summary of my experience as a PO and what one could expect dealing with them:
I did not necessarily know what I wanted, but in most cases I could tell what I didn’t want
I will need help in expressing my Acceptance Criteria (AC) in a clear and succinct manner
I don’t have all the answers, so don’t be shocked when I request some time to think
Some of my ideas will definitely not work, don’t be upset if we abandon work midway
As a more technical PO, I did find it hard to balance my role and not step on the toes of the Technical Lead (TL)
What does a Product Owner do?
Firstly, I must assume that you have some familiarity with the many Agile Methods of delivering software. If the following terms seem alien to you than I suggest you go ahead with some pre-reading before continuing: User Stories, Backlog, Features, Acceptance Criteria.
I always liked to describe the role of a PO as someone who has the vision and authority to drive the build and delivery of a product. They straddle the divides of Business Stakeholder, Architect, Lead developer and everything in between. Ideally they articulate their Acceptance Criteria in terms of Business Requirements and allow the build team to deliver. In performing this role they should be prepared to answer technical questions like: “What Disaster Recovery plan did you want?”, “In terms of Non Functional Requirements, how many transactions per second should our application scale too?” and “How fault tolerant and available does the system need to be?”
In a high functioning team they can even help shape the backlog and create user stories that are documented in a Behaviour Driven Development (BDD) fashion. Further extending upon this, they may even delve into Specification By Example (SbE) to ensure there is a common language shared between Business and Developer - ensuring a crisp understanding of the requirement and ultimately driving Automated Testing.
What do you want?
This is typically a tough question. One of the projects I led was to build out an Automated Testing Framework. How does one articulate this? More importantly, how does one define the Definition of Done for this product? What does complete look like? How do I measure success? A skilled engineer will begin interviewing the PO to breakdown the vision into smaller deliverables, that can further be dissected into smaller users stories/tasks and ultimately prioritised. Using the example above, some questions to trigger discussion could be:
What technologies did you want to test? RDBMS? Cloud? Web/Mobile/Desktop Application?
Is the aim to build a system for Unit Testing? System Integration Testing? what about Performance and Volume testing?
Do the tests live the codebase or is this a standalone SaaS? library? container?
Hopefully, this allows the team to begin theming the work into Epics/Features and a backlog can begin evolving.
Fail Fast
This is probably one of the most important lessons I learnt in my role. Spending weeks or months on a codebase, only to realise you made some wrong decisions early can be quite galling. But consider the alternative - wasting time and effort on a codebase that over time will become harder to maintain or even worse, not meet the original requirements!
This is where I would encourage a PO to entrust the team to invest time into prototyping. This can be in the form of wire-frames (for UI/UX), spikes and proof of concepts and even a simple paper based assessment. Hopefully the process will tease out a few issues not even thought about, cement the requirements with the development team and ideally lead to some innovative and better design overall.
Step away from the Code
One of the main areas I struggled with as role of PO was to understand that my task was to lead the team with my vision, not with my design and architecture. It was my responsibility to prioritise the backlog, provide clear goals, work with my business stakeholders and ultimately accept the product on their behalf. Having a technical background and knowledge was definitely a benefit to the build team, but I continually had to stop myself from overstepping my role and overriding the Technical Lead. The danger here is that although it is tempting to jump into an IDE and bang out some code, you will ultimately be letting the team down as a PO has many more tasks that interfere with deliverables - your velocity fluctuates wildly and in the end you will become a burden to the team. Do yourself a favour, invest your time in creating clear AC, backlog grooming and (if inclined) helping with showcases to the wider business audience.
Out of bounds
As a professional engineer, there will be some important tasks that is almost non-negotiable. Take for instance testing and environment management. A typical PO would not consider the benefits of investing time in Automated Testing, Test Coverage, Continuous Integrations and Deployments, IaC, Documentation etc. I feel that it is up to the Technical Lead to educate a PO on the benefits of undertaking these tasks and have a strong stand on what to compromise. Obviously this depends on the project at hand, you potentially would not enforce strict Test Coverage or IaC on a throw away (temporary) project - although be mindful that these type of projects typically have a very long sunset and end up being in production far longer than could be imagined.
Conclusions
Ultimately, being a PO can be quite exciting - I like to imagine the team as an extension of myself but scaled and optimised to enable rapid delivery. Giving the team autonomy to make decisions, push back on weak requirements and have direct access to question me at any time can lead to a fulfilling and cohesive team.
