Learning About Our Customers (Part 8 of the Agile Engagement Leadership Series)

If a product has been flagged as “invest” during planning, the product owner and team should be in a continuous flow of discovering valuable features to deliver for that product. They should be learning everything about who is (or could be) using their product.

The output of learning and discovering our users is captured in a product vision. The product vision should simply be identifying who they are, what needs they have, and what features should be created to satisfy those needs. The features generated with the product vision will feed the product backlog created in Part 7 of this series.

Product discovery should not be done in a vacuum and ideally, not be done in isolation by only the product owner.

An earlier post of mine discussed this concept of performing user discovery as a partnership between the roles of product owner, architect, and user experience designer. Each role brings a unique perspective to the vast array of possible features and provides a balance and filter for the product owner. If possible, I would leverage this approach.

Creating a product vision is not easy and will take a considerable amount of time and energy and should be constantly evolving. I would not consider myself an expert in product visioning but there are awesome resources available from real thought-leaders in this space such as Mind the Product and Marty Cagan to help.

I have however, interacted with many product owners and coached product teams through product discovery activities. From what I have seen and experienced, here are couple simple tips to remember:

Become them. This is nothing new to most of you but the use of personas and customer immersion techniques are useful in discovery. Depending on your product, you may also need to get out of the office to hear what your users are saying. Whatever techniques you use, it’s crucial to have real customers speak to you and for you to listen.

Let them try things out. There are times in discovery when you may develop theories about how a product or feature would meet needs the user or customer. In this case, use small experiments to confirm your theories. Obtaining answers in discovery is cheaper than in delivery.

Stay in discovery. As much as realistically possible, product owners should spend most of their time in discovery. There is a temptation for product owners to get heavily involved with the delivery cycles of the team. While we love to see product owners being interactive with their team, solving day-to-day impediments someone else should be solving detracts from valuable time with our customers. Scrum Masters play a key role here.

Inform leaders. When you learn new things about the customer, let your leaders know. Share your theories on user behavior with them as your discovery should continuously feed into the evolution of the overall organizational vision. We’ll cover this in our last post in the series called Building Partnership.

Note: I know there is debate to whether one should use “user” or “customer” when referring to the people interacting with our products. I fall under this camp.

Join over 2,200 subscribers!

Get the book Becoming a Catalyst for free when you subscribe and be the first to know when a new post is published.

SUBSCRIBE!

You have successfully subscribed! Check your inbox for download instructions.