February 28, 2012

Should your UX person act as Product Owner in Agile?

One of the key strengths of Agile development is that it brings customer feedback into the product management and development lifecycle. However, many teams are trying to figure out how User Experience (UX) influences Agile. A key question teams I work with are asking is: Should the Product Owner role be held by the UX person or not?

In many teams, Product Owners are not user experience professionals. The role is either held by business or product management people and even by engineering. Since the Product Owner aggregates customer input, he or she is forced to do user advocacy, a traditional UX activity. It only makes sense then, that the Product Owner role sit with or be shared with the user experience team.

Why UX and Product Owner are complimentary roles: 3 insights

First, let's define the Agile Product Owner role...The Product Owner represents the voice of the customer and is accountable for ensuring that the Group delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. (hat-tip to Wikipedia).

Insight #1: Product Owners are listeners, yet many Product Owners spend more time with "internal customers" than with the real end-users. This leaves them at a disadvantage and this is precisely where UX professionals can fill a gap.

UX people understand customers by regularly (I hope) conducting day in the life visits, contextual interviews (read: field studies) and translating customer (persona) needs into design requirements. If not field studies, usability testing is more common. (If you are a UX and don't do either of those you probably need to redefine your role so you don't confuse your team, because UX necessitates heavy contact with the customer).

The team and product owner learned to defer to him (UX) on thorny questions of emotion, aesthetic and interaction particularly where the product owner had no clear sense of how the decision impacted tangible customer value.

The team had to learn how to deliver constructive feedback on UX. They had to learn how to express personal opinion in that context.

The UX director needed incredible patience taking in well and poorly delivered feedback. He had to understand his own process well enough to use day to day input to enable his own creativity rather than shut it down.

Take-away: Dev teams should defer to UX leads on issues beyond their awareness. Include regular sprint-friendly usability reviews, usability test data, persona insights or just tap the UX for a qualified opinion on a design issue.

Insight #2: Product Owners typically have their hands full and doing UX is one more burden. Since Product Owners are busy validating and verifying requirements, feasability and prioritiy and UX people spend their time gathering usability requirements--the two can support each other to guide important user interface design decisions. This is where I favor a shared PO role or "two-in-a-box" leadership model we use at Experience Dynamics.

Many teams forget to including usability activities in sprint planning. This again I believe is largely due to lack of familiarity with usability and UCD methodology. It is important to remember that usability and UX can be conducted quickly and informally (e.g. Google's cafeteria user testing). The team should be informed of what UCD deliverables and usability requirements will be coming and at what point (so they can react to change). This will also help the UX prioritize and champion user needs.

Take-away: PO's as well as the UX person on your project need to be honest about their usability short-comings. I've found a tendency in some Agile groups of presuming we're all on the same page about what UX should do, when clearly we were not. Setting clear expectations, adequate project planning for UX activities to occur and inform key points in a sprint are vital steps that are often overlooked.

Insight #3: Product Owners can leverage the authority of a UX to deliver useful deliverables to engineering teams. Typical PO's: Business analysts, product managers, software architects-- typically do not have access to the world of tools, techniques and methods of getting user validation and usability data. Usability professionals have resources that can be quickly leveraged. UX can provide rapid support and tangible deliverables to both developers and PO's alike.

The UX designer, working in parallel with the rest of the team, is constantly providing assets, answers, and feedback. The PO is looking ahead to the next iteration, as well as the next theme. The challenge has been focusing on the present and the future at the same time. The way I’ve handled this is by splitting my time in the iteration. Early in the cycle I work on the immediate needs of the team. What I’ve also found effective is, as you’re deciding where to focus in the near-term, bringing in the team for quick brainstorms, affinity mapping exercises and design studios* offers perspective, insight and a welcome (short) break for them from the monotony of long coding days.

Take-away: Dev teams can use more UX direction if they have an immediate injection of useful direction (eg. persona priorities) followed by just-in-time deliverables (eg. wireframes; expert reviews) throughout the sprints.

*Including the dev team in collaborative wireframing sessions, called 'design studios' above, can also help bridge the gap.

Conclusion: The Agile development Product Owner role is strategically suited to be owned by the User Experience team or person supporting the project. Since a PO carries a great deal of responsibility, it may be more prudent to share the role with the UX, thereby offering shared control and collaboration- a key feature of Agile team organizations.