{"id":9573,"date":"2019-05-30T10:34:54","date_gmt":"2019-05-30T15:34:54","guid":{"rendered":"http:\/\/www.watermarklearning.com\/blog\/?p=9573"},"modified":"2024-09-06T09:42:38","modified_gmt":"2024-09-06T14:42:38","slug":"lessons-learned-from-accidental-product-owner","status":"publish","type":"post","link":"https:\/\/www.watermarklearning.com\/blog\/lessons-learned-from-accidental-product-owner\/","title":{"rendered":"Lessons Learned from an Accidental Product Owner"},"content":{"rendered":"

\"LessonsA key role in Scrum, the most common form of Agile development<\/a>, is the Product Owner (PO) role. Some experts say it is the most challenging role. Besides the PO, the only other defined roles in Scrum are the Scrum Master and Team. The latter two are what we might call the \u201cengines\u201d of Scrum development, while the Product Owner could be thought of as the \u201ccompass\u201d or \u201cGPS.\u201d<\/p>\n

Complicating the picture is the Scrum prescription for a full-time PO on Agile\/Scrum teams. While Scrum Masters and team members are more often assigned full-time to Scrum efforts, Product Owners are arguably the least common full-time role due in large part to business demands for their time. A common although not universal way of solving this dilemma is to substitute a Business Analyst (BA) as a \u201csurrogate\u201d PO.<\/p>\n

There are practical advantages to the compromise of using a substitute Product Owner to be sure. If the business cannot or will not appoint a full-time person to the role, a BA can provide a needed business perspective, especially as it relates to requirements. However, I see two main pitfalls to this approach:<\/p>\n

    \n
  1. Product Owners make decisions and set priorities – how often do stand-in POs have the necessary authority to do that? Decision-making for a product runs counter to the optimal role of a business analyst, which is to make recommendations.<\/li>\n
  2. The compromise can also be inefficient and costly if the surrogate\u2019s decisions or priorities lead to second guessing by stakeholders and if rework results from reversed decisions.<\/li>\n<\/ol>\n

    Lessons Learned<\/strong><\/h2>\n

    Regardless of your team\u2019s approach to the challenges above, there are many pitfalls you can avoid. I know, because I\u2019ve played both roles at the same time on projects and it is difficult. The dual roles were for two major products and countless releases of them.<\/p>\n

    One is Watermark\u2019s Online Study Exam (OSE)<\/a>, which has housed seven different certification exams used by over 14,000 people in over 100 countries. The other is the Training Management System (TMS) that we use for managing the calendar, registrations, and student records. Because the BA role on both was more time-consuming, it tended to dominate my time with these products. The analysis was important to be sure, and both systems have robust data models to support them. However, I feel it was the overall product management and during development, the product ownership<\/em>, that led the way to successful outcomes. There were even occasions in which the two roles were in conflict.<\/p>\n

    Here is a brief summary of some lessons I learned along the way from being what I would term an \u201cAccidental Product Owner.\u201d<\/p>\n

    1. It\u2019s hard to be both the BA and PO.<\/strong><\/h3>\n

    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 \u201cwrong\u201d decisions.<\/p>\n

    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. Here\u2019s just one example: as we were adding functionality to our TMS, the topic of providing discounts on purchases of certain classes arose. In my role as \u201cBA,\u201d I wanted to add the feature. But, most purchases for the product are single ones, so the \u201cPO\u201d in me decided to delay that functionality and to continue with manual processing of any exceptions.<\/p>\n

    2. Being disengaged doesn\u2019t work<\/strong>.<\/h3>\n

    An engaged PO is an effective one. It\u2019s 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. In another example, our exam development team was getting hung up over how to provide more flexibility for users. After numerous unhelpful emails we resolved what to do with one phone call.<\/p>\n

    RELATED BLOGS<\/h4>\n