Building a Product Owner – New Product

Many of the complaints that I hear often about Agile implementations concern the product owner.  Either the business is not engaged appropriately, or the product owner is indecisive or unavailable, or the quality of the requirements/user stories is poor. Whatever the situation, the product owner is often “at fault.”

person4Instead of lamenting why we do not have good product owners, I would like to shift our thinking to: How can we build a Product Owner?  These are challenging jobs and often the people put in them have little background on what is expected of them.  This is the first in a series of three blogs to help us build better product owners, which will lead to better products.  First, let’s examine a new product offering.  Where would a new product owner start?

For this effort, I recommend a three step process and I have to give credit to David Hussman who provided some of the inspiration for this topic.

1. Create personas

Who is going to use this new product?  Who is your buyer?  Will you have power users and casual users?  Do you need to consider administrative users?

Personas first came into the conversation with Alan Cooper’s book “The Inmates are Running the Asylum” in 1999.  Personas are fictitious people who are going to use the system so the Product Owner can think about user interactions and how best to optimize the experience.  Let’s map out a few personas.

We have a busy executive who will access our app to determine the weather in their travel destination.  They will always be on a mobile device (could be smartphone or tablet) and they are looking for quick response times and an easy to navigate site with the ability to remember commonly accessed cities to minimize keystrokes (required input.)  This executive lives in San Diego, CA and travels  mostly along the West Coast.  He has a wife, four children and an MBA.  We will call him Dave.

Our second user is a weather enthusiast who is interested in developing storms across the US.  He does not travel but is fascinated by storms and their paths.  He will access our site from a laptop so that he can view the satellite information on a large monitor.  He is intrigued by the depth of the information and is more concerned with comprehensive data than page load times.  He is inclined to purchase add-ons and visits the site at least once a day.  He lives St. Louis, MO, he is not married and he has a software engineering degree.  We will call him Mike.

You can see from these two personas that we have quite different users of our system with very diverse needs.  As we reflect on priorities and functionality, it is important to know if we are targeting Dave or Mike or someone else.

2. Happy Path

Once the personas are identified, the next step for our new product owner is to identify the most likely user interaction.  We call this the happy path because it is direct and without exception.  For Dave, the happy path might include accessing the app from the tablet and remembering his user credentials so he does not have to log in every time.  Dave can then go to the search and type in the first letter of his destination.  The system will remember his previous searches and provide options from him to choose from or enter a new destination.  For example, when Dave types in S, the system prompts him for Seattle which he can choose or keep typing.  When he adds a P, the system prompts him for Spokane, and so on.  Once Dave chooses the city of his destination, the weather information appears, defaulted to weather for the next 24 hours.

Understanding and articulating the happy path is essential.  There are always lots of exceptions (see below) but a Product Owner’s first responsibility is to understand the most likely transaction.

3. The What-Abouts

I first heard this term from a David Hussman webinar and I absolutely love it.  The ‘what abouts’ are all of the instances that could possibly occur.  The best bet for a product owner is to gather and document all of the ‘what abouts’ even if they ultimately decide not to code for them.  What about different tablet formats?  What about different browsers? What about different data networks?  What about international locations? What about people who forget their password?  What about people with hundreds of previous searches?  The list of ‘what abouts’ can go on for miles.  When developing a new product owner, help them to understand which ‘what abouts’ are relevant and worthwhile and which ones can be put aside for later.


Being assigned as a new Product Owner can be a scary prospect, especially if you do not know what to expect from your role.  This first blog in our series addresses how to get started with a new product.  By developing personas, charting the Happy Path and considering the ‘what abouts,’  the new product owner is on the road to success.  Stay tuned for future blogs on helping new product owners with a system migration or taking over an existing product with a healthy backlog.  We hope this series will help new product owners feel more comfortable and secure in their new role.


2 Responses to Building a Product Owner – New Product

  1. […] the training and tools that they need to be successful.  Just like we introduced with developing New Products, here are some tips and tricks to managing system […]

Leave a Reply to Building a Product Owner – New Product - The Agile Product Report Cancel reply

Your email address will not be published.