7 Lessons Learned from an Accidental Product Owner
Receive free IIBA updates and exclusive content!
If you have been hearing a lot about Product Ownership, it’s because the skills, techniques and competencies associated with the Product Owner role have never been more in demand. Product Owner job growth is projected to be 24% in the US alone.
Some professionals start on a direct path to Product Ownership, while others take on product owner-related tasks or wear multiple hats on product teams. Below is a breakdown of my top seven lessons learned from being an accidental Product Owner.
1. It’s hard to be both the BA and PO.
There is a difference between business analysis and the PO role as noted above: authority levels, decision processes, and changing direction by the business if the BA makes the “wrong” decisions. The Product Owner must be focused on quick and continuous delivery of value. The BA role is concerned with getting all the requirements and exceptions. The latter are important but can derail and delay development.
2. Being disengaged doesn’t work.
An engaged PO is an effective one. It’s harder to be an engaged PO by email. A remote PO connected virtually to the team can work, but the PO and team need to meet regularly by Skype, GoToMeeting, or other means. Phone calling in between can clear up issues and roadblocks that emails have a harder time with.
3. Focus on customer-facing features first before internal features.
This lesson was helpful to keep in mind as our chief developer kept wanting to address an internal issue with the product. It had nothing to do with adding system-system interfaces or other important infrastructure items such as security, which of course would warrant higher priority than even some user-facing features.
4. Better to not do testing yourself,
which could more easily happen if a BA is wearing the dual hat of a PO. It is easier to assess priorities and to decide to defer undeveloped features if the PO is not in the thick of testing.
5. It helps to be familiar with design concepts and databases to be able to ask good questions.
You might say, well, BAs need this too so a BA should be the PO, right? No, I don’t think the PO needs to be anywhere near the level of technical knowledge as the rest of the team. A good BA on the team can effectively serve as translator. A PO could make better decisions, for example, by knowing that a many to many relationship can be solved into an associative entity to allow flexibility.
6. Easier to make decisions when you have the right data.
Knowing the frequency that different transactions occurred helped me realize the priority of features. Having the right data reduced the stress of trying to prioritize outstanding features.
7. Need courage.
Agile is unlike Waterfall in which the business is usually anxious to get every last requirement into a solution because they may not get IT’s attention for years. Each sprint or release should be focused on the most value-added features at the moment. There may be features or requirements that are valid but will be dealt with as time and budget allows. There may be workarounds needed in the meantime.
Ready to learn more about Product Ownership techniques and how they intersect with Business Analysis? Find out more in IIBA’s Guide to Product Ownership Analysis.
Note: A full version of this article “Lessons Learned from an Accidental Product Owner” was originally published in the 2020 Q2 issue of BAM! (formerly BA Lens). IIBA Members can view the full article here.
About The Author:
Richard Larson is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on BA and PM topics to over 10,000 participants on five different continents. He has contributed as a lead author to the BA Body of Knowledge version 2.0 and 3.0 and other publications and co-authored five books on business analysis.