When practicing Agile, the product owner (PO) role is designed to represent the client business in the development team. From a technical standpoint, the product owner lends focus to the team. From the customer standpoint, the product owner adds an increasing degree of accountability to the day-by-day and to the project as a whole. The product owner is more than critical to the outcome of the project.
In Behaviour Driven Development (BDD) the product owner becomes the lifeblood of the project. They help feed information between client and development team and decisions on both sides are made and actioned based on what they say and do. The project and the project outcomes can only be measured by the values they communicate. With insufficient input or a complete lack of product owner altogether, the risk of scope creep, un-prioritised work, poorly defined requirements, and the project running over budget increases exponentially and ultimately results in a final product which adds no business value. Unless the development team supports the product owner, and steps are taken to harness their valuable position, the project is doomed to fail. However, by understanding the pressures of the PO role and offering guidance, a technical team can gain more from their product owner.
Unless you are the inventor of a product, the product owner is not a traditional role within an organisation and is likely to only be held by the individual during the project lifecycle. Upon completion/ business adaption/ deployment/ go live; the product owner will likely go back to their normal job as a marketing exec, CEO, CTO, or whatever it is that they do. The product owner role is often on top of their day-to-day responsibilities and they often have much more responsibility than time. What is more damaging, albeit through no fault of their own, is their lack of experience in product ownership. The point is that the product owner isn’t actually a product owner. And yes, while the product owner is ultimately responsible for the product, a poorly delivered product (no matter the owner) should be viewed as unacceptable from every member of the team.
Now, there is something first of all, which I believe needs to be understood by the entire development team. A magic all-knowing, all-doing product owner is something of a unicorn. Nevertheless, as the development team we can build one!
What I mean by this is that we, as the development team, can craft and teach the client business representative how to be an effective product owner. Each product is different with different needs; and so to adapt for each scenario we need to empower empathy. For a perfect development cycle to exist, I believe, there must be empathy between the project, the product owner and the development team. Empathy is at the heart of BDD. At the start of a project, the technical team will learn more about the product owner and client business’ performance, their strategy, the market, their stakeholders and their individual needs. Empathising with the client business allows us to understand their motivations and requirements. It allows us to put on their shoes and get inside their mind. This is the only way to truly understand a business, its wants, and its needs, so why should it be any different with a product owner?
We must understand and empathise with the fact that product ownership is not the PO’s only job, that this may be their first experience as a product owner, and that they may not have a technical background. Before development begins we must introduce them to our company practices, our company tools, and the day-to-day style in which we work. We must tailor conversations at meetings where they are present to their level of technical knowledge. Sometimes delving into technical detail is possible, but it is a fast way to lose the concentration of a non-technical product owner in a meeting.
We must accommodate their daily work schedule and understand that we all carry the burden of increasing co-location. We must also understand that while Friday 3pm may be the perfect time for a end of sprint demo in our office, the product owner may feel otherwise due to travel commitments or personal plans.
These are just guidelines towards empathising with and building a relationship with your product owner. There is no absolute rule as to how you must structure your approach and your processes with a product owner entering your project. There is, however, a definitive need to acknowledge the benefits of a dedicated product owner. It is partly the development teams’ responsibility to ensure that the project is most efficient, proactive and effective so as to be able to realise software products that add value to the client business.
About the author
Ben joined The Inviqa Group in 2013 at as QA analyst before migrating to the Business Analysis team in May 2015. Since joining the BA team, Ben has worked on some of Inviqa's largest projects for some of the UK's most influential brands. A qualified Google Analytics expert, he has a keen specialism in eCommerce as well as a strong interest in start-ups, mobile payments, gaming, security and infrastructure. You can find Ben on Twitter at @b_is_coys.