Lessons Learned from an Accidental Product Owner

A key role in Scrum, the most common form of Agile development, 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 “engines” of Scrum development, while the Product Owner could be thought of as the “compass” or “GPS.”

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 “surrogate” PO.

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:

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.
2. The compromise can also be inefficient and costly if the surrogate’s decisions or priorities lead to second guessing by stakeholders and if rework results from reversed decisions.

Lessons Learned

Regardless of your team’s approach to the challenges above, there are many pitfalls you can avoid. I know, because I’ve 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.

One is Watermark’s Online Study Exam (OSE), 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, that led the way to successful outcomes. There were even occasions in which the two roles were in conflict.

Here is a brief summary of some lessons I learned along the way from being what I would term 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. Here’s 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 “BA,” I wanted to add the feature. But, most purchases for the product are single ones, so the “PO” in me decided to delay that functionality and to continue with manual processing of any exceptions.

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. 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.

RELATED BLOGS

• • • The Digital BA Series: 5 Killer Question Types for Digital Transformation
    • Influencing with Authority: Management, You Need Influencing Skills, Too!
    • Business Analysis Career Options
    • How to Become a Certified Scrum Product Owner

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 Study Exam product. It had nothing to do with adding system-to-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.

This 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. Another useful thing for a PO to know is that there are trade-offs between “hard-coding” something (and making maintenance harder) and setting up a code table (which adds short-term overhead but makes long-term maintenance easier).

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. That 95% of our registrations were for individuals registering for single classes made it easier to decide to defer other 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.

I found a useful mantra to keep in mind: “Releasing ‘as is’ but missing features is no worse than what we have today.” For example, with our Online Exam product we were faced with two potentially valuable new features recently. We chose to add the one we thought would be of higher value, which is just another way of saying we prioritized the features. The fact we did not address the other feature left us “no worse off,” and that made it easier to decide.

The Product Owner role is an important and potentially tricky one. Hopefully these lessons will help you if you are thrust into that role or will help you to coach any POs of your own.