Linking the left brain and the right brain

Don’t Give Product Owners More Credit Than They Deserve

Are Product Owners (PO) all-knowing and all-powerful when it comes to software features and functions? I think they’re sometimes given more authority than they can handle. There needs to be a balance between business needs and technology constraints.

Here’s a specific example to illustrate my point.

Let’s say the agile development team is asked to build a software application to extract new insights from an existing ecommerce website and database. For example, the business wants to know which referral websites send the most buyers, not just browsers — they want to know how the buyers arrived at the website. Armed with this information, they can develop a better strategy for leveraging the referral sites.

The existing website contains information on referrals. Any good web analytics software package tracks these. Also, every time someone buys something, the customer database captures information about them — what they bought, when they bought it, how much they spent, etc.

Unfortunately, in the current website implementation the web analytics aren’t linked to the buyers database. The information repositories are completely separate and independent. They are housed in different places and serve different needs. The development team doesn’t know if it can align buyers and referral sites in order to extract anything useful from the existing data.

Time to write stories and define sprints?

The PO begins to lay out a collection of epics for the project and enters them into the product backlog. He and the team begin the process of breaking down epics into stories and defining the sprint backlog.

The PO wants to start with a software framework based on basic UX elements and lay the groundwork for the search and sort features that will be needed. Sounds good, right? There’s just one problem. The team may not be able to deliver anything of value if it can’t align the underlying web analytics with the buyers data.

Should the team get right to work and hope they can align the data in a later sprint? Should they spend an entire sprint doing data analysis and algorithm refinement before starting to build the application? Should they create two teams to operate in parallel on the algorithm and the application?

Any reasonable approach can work.

There are no obvious or simple answers to these questions. The complexity surrounding the data represents risk. The PO and the development team need to work together to assess the risk and determine how they want to handle it.

The safest approach is to first define a set of stories that will help in analyzing the data and defining an algorithm. The team would only commit to building the application once they find an algorithm that works. The drawback is time. The business will not see any working software until the algorithm and the first post-analysis sprint are complete.

The fastest approach is to form two teams and overlap their activities. The drawback is cost. This approach will cost more but result in faster delivery if it turns out that the problem can be solved using the existing data sets. If the data can’t solve the business problem, new data will need to be collected.

It has to be a team effort.

Without getting too wrapped up in the particulars of this example, the point is that the PO cannot define all the stories nor prioritize the work in isolation. These activities need to be undertaken by the entire team. Risk will be manifested in many ways. Only a coordinated team effort can mange it effectively.

So the next time someone tries to tell you that only the PO can make product decisions, remind him not to give the Product Owner more credit than he deserves.

Updated: March 18, 2012 — 10:16 pm
© Damicon 2014 Frontier Theme