As an awesome tester, I find myself very often pairing with a product owner on figuring out how to fix our ways of working so that we could have best chances of success when we discover the features while delivering them. My experience has been that while a lot of the automation-focused people pair testers up with developers, the pairing on risk and feedback with the product owner can be just as (if not more) relevant.
Over the years, I've spent my fair share shaping up my skills of seeing illusions on a business perspective, and dispelling them hopefully before they do too much damage. Learning to write and speak persuasively is part of that. I've read tons of business books and articles, and find that lessons learned from those are a core to what I still do as a tester.
I find that a good high-level outline of the skills areas I've worked on is available with the Complete Product Owner poster. Everything a product owner needs to know is useful in providing testing services.
In preparation of a "No Product Owner" experiment, I made a list of some of my expectations on what a product owner might do (together with the team).
Over the years, I've spent my fair share shaping up my skills of seeing illusions on a business perspective, and dispelling them hopefully before they do too much damage. Learning to write and speak persuasively is part of that. I've read tons of business books and articles, and find that lessons learned from those are a core to what I still do as a tester.
I find that a good high-level outline of the skills areas I've worked on is available with the Complete Product Owner poster. Everything a product owner needs to know is useful in providing testing services.
Being a Product Owner sure is a lot of work! - William Gill
In preparation of a "No Product Owner" experiment, I made a list of some of my expectations on what a product owner might do (together with the team).
What a Product Owner Does?
- has and conveys a product vision
- maintains (creates and refines) a product backlog - the visible (short) and the invisible (all wishes)
- represents a solid understanding of the user, the market, the competition and future trends
- allows finishing things started at least for a preagreed time-box
- splits large stories to smaller value deliveries
- prepares stories to development ready (discovery work)
- communicates the product status and future to other stakeholders
- engages real customers and acts as their proxy
- calculates ROI before and after delivery to learn about business priorities
- accepts or rejects the work done
- maintains conceptual and technical integrity of the product
- defines story acceptance criteria
- does release planning
- shares insights about the product to stakeholders through e.g. demos
- identifies and coordinates pieces to overall customer value from other teams
- ensures delivery of product (software + documentation + services)
- responds to stakeholder feedback on wishes of future improvements and necessary fixes
- explains the product to stakeholders and drives improvement of documentation that enables support to deal with questions
