The PO challenge
My experiences as a PO afforded insight into how to connect, analyse and organise for the best outcome. The challenge for any PO is balancing the interests of multiple parties, making the project maximally efficient, conforming as closely to the product vision as possible, while supporting the team and collaborating with the Scrum Master- all without taking on too much stress.
There are several values to focus on- first, what are the financial gains? Usually the customer knows best but there are times- when conducting essential security updates for example- when it's difficult for them to see the business value. I implement a business value numbering system to prioritise tasks; when a small item has a big business value and a big item has a smaller business value, it becomes clear that you should do the small one first.
Sometimes the client requests things that don't make a lot of sense to you but in the end the customer has to make everyone happy: editorial groups, marketing, sales and management. On long-term projects, we make improvements that benefit every one of these groups annually.
Do you have what it takes to be an effective PO?
One day a potential customer approached us with a lot of demands and needs because they had had a negative experience before with a different agency. We had to look into what the problems were and where they originated. Company boards and stakeholders sometimes state obscure needs and requirements that are not immediately obvious from the customer and this requires good relationship building to get close enough to be allowed into areas such as internal politics; the PO has to ascertain why a task has to be undertaken, what is the objective, and how to complete it to the customer's satisfaction. And of course, communicate this to the team; if the task or project is unintelligible to them, the end result is bound to be unsatisfactory.
Being part of the team; getting to know and supporting the developers, being mindful of team dynamics and anticipating and resolving problems as they arise, is critical. This is the key difference between the role of PO and Project Manager.
Sometimes you receive an agitated call from a customer; usually it's because someone is exerting pressure on them- remaining equable and empathetic is the best way to problem solve, leaving both parties content and stress-free.
Customers new to Agile may attempt some brand of power play with a PO, being accustomed to fixed price projects. I think sometimes you should just let them walk away- even if it's a substantial 6 digit project. If it's going to demotivate yourself and your team for 2 years, it will only dampen spirits and productivity.
PO vs. Customer vs. Decision Maker
Often a customer sees a competitor's website and insists on incorporating a similar feature. As PO you have to consider whether this complements the product vision and advise. This is especially important when you work with several people on the customers side and have to get the OK of the customers decision maker, while keeping them in the loop as ultimately they will get all the praise or blame.
PO as trader
A common experience is when the customer announces an urgent task out of the blue. Competing external pressures can be mitigated successfully if you see yourself as more of a trader, reassuring the customer that you can fulfil the task while notifying them of the associated cost: a different backlog task that will not be fulfilled in the current sprint.
The team cannot accept more tasks than were previously assigned- the customer has to think about what their priorities are. On balance, the customer often decides that all current backlog tasks are too important to defer to a future sprint and that this new 'urgent' task can wait after all.
Communicating in this manner ensures fewer misunderstandings and less stress all round. When times get tough, it's worth keeping in mind that an outstanding PO often knows the project better than the customer, which comes with the territory.
Sebastian fell in love with web development when Geocities was hip (~1996). He studied computer science and became a freelance consultant in 2007.
His focus shifted from TYPO3 to Flash, to Java mobile and web applications, back to TYPO3 and in the last years more and more to NEOS CMS, continuous integration and Scrum. In 2014-15 he lead two TYPO3 projects as product owner and technical architect in Cambodia.
Sebastian is a Certified Scrum Master passionate to help teams become more agile and deliver consistent high quality products.
Read more about our efforts pushing Scrum & Agile practices in Cambodia: