Your squads are off and doing their thing, but how strong is the team's user insight?
An agile product owner's got a lot going on; things like defining and prioritizing the product backlog, communicating product vision and requirements, adjudicating priority trade-offs, and being a valuable connector of the squad to the organization. At the top of the list though, has to be the product owner's discipline of understanding the user, and reflecting that constantly in the squad. The product owner must represent the user's needs, attitudes and behaviours as it applies to the teams solutions.
I have found however that in many agile teams a clear, continuous, broad and deep understanding of the people who use and benefit from the team's outcomes (be it a product, platform, technology, feature, etc) is often lacking. It's understandable; when an agile team is created there is the primary focus of defining the squad's purpose, assembling a group of skilled individuals who can create outcomes with independence and self-management, and drafting a product backlog with probably a long-overdue set of development activities already waiting. Then before the product owner knows it, the agile team is off and running, and driving at creating solutions.
Why does user understanding matter in agile—doesn't the team know what is important?
Consumer understanding has been part of business since, well, forever. It's been the backbone of marketing for a long time, and became very sophisticated in the '90s when customer databases came to be. It took another leap forward in the digital age with the ability to track every click of an online user's experience. For marketers, the goal's always been to understand your customer better so you can sell them more stuff. In agile, it's to know your user better so that you can innovate the most valuable solutions for them. The trick is to remove bias, and get to truths, so that you really understand what matters to the user, and not what you think matters to a user.
Where should a product owner start, in user understanding?
Ground zero is to try and sketch out some User Personas. These are fictional representations of different user types based on research, data analysis, and feedback from actual users. They help the product owner understand the goals, motivations, behaviours and pain points of their target users. Basically you're trying break out that one amorphous group of 'users' into smaller groups that are more differentiated by how they act and feel. Here's an example:
Years ago I worked for the world's largest ski resort company. We did a massive segmentation exercise to create skier personas, and we ended up with six groups that had significantly different needs, attitudes, and behaviours. We created detailed descriptives of these groups, and each had an illustrative title like "Steep & Deepers", and "Family Value Vacationers." They were packed full of characteristics to help us relate to them more valuably. For the Steep & Deepers, the single most important thing we could do for them was get them up the mountain as early in the morning as possible (we created the 'First Tracks' program.) For the Family Value Vacationers we uncovered the need for ground floor accommodations (terrified their little kids would fall from a hotel balcony) and be close to the kids ski school so the parents weren't lugging gear across the village (we created the kids ski train to pick them up at the lodges.)
As persona development is a long established research discipline, there are a variety of research firms and consultants who can help (I'd be happy to talk with you about it!) There are even online tools that might be valuable, but probably aren't going to get you as far as working with a professional.
With these insightful profiles at hand, what's next?
Personas power up agile User Stories: they give a richness of context and support a better prioritization of the backlog. Agile teams immediately improve their user stories when they have a learned visualization of the user.
User Interviews: Interviews can be a quick way to gauge opinion on the agile team's solutions. Although not 'quantitative' data, it can help point the team in the right direction. And it can be simple: one time I had a team run over to the supermarket, ask the manager for permission, and then approach customers for two minutes on their thoughts about a prototype.
Surveys and Feedback forms: this can be as sophisticated as managing a continual research panel, or as simple as pushing out a SurveyMonkey to emails you have permission to contact. Quick pop-up polling on websites has become a very popular method of gauging user experience improvements.
Analytics Tools: if the agile team creates outcomes online, I feel the product owner should have a good handle on how to use web analytics tools. These tools have been proving answers to what's happening with users for over 20 years, and have become extremely powerful. Google Analytics, mixpanel, and Amplitude are just a few of the products out there.
The bottom line is that knowing how successful the agile team is, strongly depends on understanding the engagement and satisfaction of the users. It can be quite a sophisticated art and science to gain this knowledge, and deserves a focused understanding of how to achieve this insight, before the squad really gets running.
Comments