The Product Owner Panel session seemed to be a relatively hot topic. We had about 35 engaged attendees. I also had a relatively large number of people email me and let me know that something had come up and they couldn’t attend. Every “I can’t attend” email asked if we could post notes or blog posts. In the past, we haven’t done it because I’m usually simply too busy to be focused on taking notes, and this time was no exception. However, after this meeting, I asked if anyone had taken notes to please send them, and I’d post them on the site. Great News! It’s like having “guest reporters!” I received a couple sets of notes, so I’ve posted them below (if I get more notes later, I’ll post them also).
A special thanks to our “guest reporters” Allan Dean and Dave Woodbury.
From Allan Dean
Q: What’s the hardest thing to do as a Product Owner?
A1: Say no.
A2: Drowning the puppies (i.e. letting your favorite features go).
Q: What about a Product Owner’s AKA (Authority, Knowledge, Availability) – how important are they and can any be learned?
A: Yes – can learn to be more Knowledgeable (about the Customer, about the product/service, about technolology, about methodology and process).
A: Yes – a product owner needs and has authority, but it’s largely informal authority.
A: Yes – availability is critical. As product owner you must be available to the team, and be careful about taking on even little extra jobs in/around product launch (release) dates. Chat and email is not the same as being right there with your team.
Q: Annual release versus continuous release (iterative approaches) – what drives an organization to appreciate and adopt a continuous release approach?
A: Long story short – a burning platform. When faced with customers needing relief right this minute and your product team is faced with a new crisis plus a backlog of 6,000 defects aged over 3 years… delete them all, start fresh with what matters most to your customers in terms of delivering value to them today. Do that… release that feature. Then evaluate again, and do the next most valuable bit. Dig yourself out of “the red zone” (as a team) and with several iterations significant progress is made… and BTW a new process (iterative, continuous release) has begun.
Q: What’s your process (or filter) for moving from an initial ask for “X” to a prototype?
A1: (long and complex)
A2: I ask myself – Is “X” a major change or a minor tweak for us? Is “X” something our customers are doing already (with our product), or something they can’t do yet (i.e. an unmet need)?
A3: Prototyping… 1st start conversation in the simplest, easiest form… “on paper”, then in “low fidelity” …even just clicking thru…, then move it up to “high fidelity” (detail).
Q: What do you do as Product Owner when there is a disconnect between the customer (market) and your company’s product (service) offering?
A: Data! Data! Data! #1 Go talk to the customer and listen. Find the voice of the customer. #2 Get the data. #3 Interpret the data (make meaning). #4 Then tell your “story” that makes the data meaningful and influences your stakeholders (i.e. brings them together, like a Venn Diagram).
Q: What’s your data collection process like?
A: Conversations, lots of them. Some techniques:
i. Try out a “Hello email” to your existing customers that are 2yo…
ii. Have internal stakeholder conversations with other departments… customer/field/product support, help/service desk, sales win/loss analysis (When and why do customers walk away? When and why do we not win new customers?), and marketing (where is the market going; competitive forces; our market’s dynamics).
iii. Use satisfaction surveys and polling with your customers. NPS – net promoter score (identify your attractors and distractors).
Q: What does a Product Owner do? Who would you pick to be a Product Owner? What do you look for in a Product Owner?
A1: They discern “the What” (is to be developed). They define the “Use case” for it. And they establish “the definition of done”.
A2: They play well with others.
A3: They are someone committed to nurturing a culture of empowerment… it’s always about the people… because that’s how you build a high performing team.
Follow up : Yes – organizational change and process factors in too, but cultivating the right culture is the key. And it often sounds like… do more with less… lead by example (hard work but it feels better)… get LEAN… accept failure (and iterate quickly).
Q: Do you actually write the user stories?
A1: Yes – I write the User Stories. Writing them, tweaking them, having meetings with senior stakeholders too. Then I build (groom) the Backlog, and shape the sprint/s.
A2: After we develop the Solution Design, then come User Stories. My technique is to 1st draw out the Epics, and then I do Small Stories that I shop (vett) with my QA and these become our User Stories we review for our Sprint/s, then the Backlog (new stuff and drawing in some defect/bug work too).
A3: I used to write all the User Stories by myself because, “I’m the Product Owner.” Now I share it with the Team as our shared task. I throw a “Backlog Party” (for grooming). I still write the Basic Story (without acceptance criteria), but then the whole team crafts the User Story with acceptance criteria. Whenever I drift into defining “How” to do it, I stop and take it back up a level.
Q: What are 3 tips for Product Owners?
A1: 1st – Don’t be afraid to say, “No.” 2nd – Be a Product Owner, not a Project Manager. 3rd – Have fun.
A2: 1st – Get in bed with the Customer (not literally). Connect with your customer’s story; why does it inspire you? 2nd – Involve the Team early and often. 3rd – Things go much better when you remember these are people (not just a team as a unit – but made of individuals)… so take the time to ask some irrelevant questions and get to know each of them, because your team will become much more capable (builds more trust).
A3: 1st – Live the culture. 2nd – Do “customer development” > leads you to the Data > gives you influence over “unsure stakeholders”. 3rd – If you build the relationship, you can get people to do anything. It’s always about the people – the ones you work with and the ones you serve.
From Dave Woodbury
Topic: Product Owner Panel
Date: March 20, 2014
The meeting opened with a welcome and introduction by Perry Reinert, followed by introductions of and by the panelists. Perry observed that the panelists represent companies whose sizes range from 40 (Jeff Schinella, Axosoft) to 400 (Sarahjane Isom, Infusionsoft) to 40,000 (Josey Borman, Pearson). You can read more about the three panelists Josey, Sarahjane and Jeff here: (http://phxsug.org/meeting/south-meeting-march-20th-product-owner-panel). The Phoenix Scrum User’s Group meetings are always fantastic, and the 30 minutes of food and drink sponsored by Infusionsoft, followed by 90 minutes of panel discussion was just right for this topic.
Perry kicked off the discussion by asking if anyone had heard of the acronym, AKA which stands for some desirable characteristics of a product owner. (Authority, Knowledge, Availability) He asked the panelists their thoughts on the acronym and relative importance of each trait. Sarahjane mentioned that a product owner has to be available to do the things that a product owner must do, otherwise all the knowledge and authority won’t be of much help. The product owner has to show-up and be engaged. Josey answered that its difficult to find a product owner with all three traits, but that authority and availability are essential. A person can always seek out and obtain the necessary knowledge.
After the opening question, the panelists and the audience were warmed up and I noted the following items during each of the panelists’ answers. I was so busy writing down the pearls of wisdom that I didn’t always note the panelist’s name, so my apologies for any lack of attribution.
1. You might be better off pressing the reset button if your backlog of stories or defects gets to be too large to manage. As a product owner, you want to lead the team to deliver working, usable releases within a short period of time, and that requires focusing the team on a small number of important things that must get done. Josey said that she asks people “What is the minimal thing you can do to be successful?”
2. Sarahjane mentioned the importance of the voice of the customer a few times and said that many of Infusionsoft’s customers are looking for the software to help them get a task done as efficiently as possible so that they can move on to other things or go home for the day.
3. I liked Josey’s comment about bringing the big comprehensive product vision down to something really small that the team can deliver into the customer’s hands as soon as possible.
4. Each of the panelists agreed on the importance of data regarding how products are being used to determine priorities. They said that one of the hardest (and most important) duties of the product owner is to say no to things so that the team can work on the highest priority items. Having data from and about the actual users of the product is how the product owner can help guide the team and make decisions about what to prioritize in a sprint. Having good data also enables the product owner to identify benefits associated with new features that can then be shared with executives and other key stakeholders.
5. There was also agreement around the importance of communication. One of the panelists noted that the product owner serves the team well by clearly communicating the status of the project and avoiding minimizing problems or overselling accomplishments. Keeping people in the loop, building relationships and trust, taking interest in team members as individuals, and recognizing that the product owner is a member of the team with specific roles rather than the manager of the team or a project manager.
6. Josey shared that Infusionsoft has many people looking at the entire user experience of their customers from many perspectives. They gather data via surveys, customer support calls and conversations with customers. Customers that cancel their subscriptions get special attention.
7. There were questions from the audience regarding (1) how to move oneself into a product owner role and-or how to encourage management to adopt an agile culture and approach to software development (2) How to best support new product owners – e.g., people who are new to the product owner role but otherwise have experience with the company’s products and business processes. The panelists answers were fantastic but unfortunately I didn’t capture many notes on these!
8. One of the panelists emphasized the importance of following the process on the part of developers, especially when they are asked to work on things in addition to the sprint backlog. The proper response is for the developer to deflect the requests back to the product owner, but it was noted that this can be very hard if not impossible for some developers.
9. Another panelist, when asked about important attributes of the product owner said that it was less important to be a product expert and that it is best to avoid putting an engineer in the product owner role because invariably an engineer cannot avoid specifying how things must be done. Instead, teams need product owners who focus on three things: (1) Use Case (2) Problem to solve (3) Definition of done.
10. Product owners must promote the agile culture of empowerment. Agile is about people and a product owner needs to be someone who plays well with others.
11. The panelists were asked if they write user stories. Jeff said Yes, based on data, voice of the customer, and other feedback. Sarahjane also said yes, but only after detailed design has been completed. Sarahjane hinted at a meta-process in use at Infusionsoft named POV or something like that, but did not elaborate. Josey said that it is very hard for a product owner to write user stories. She treats it as a shared responsibility, writing just the basic structure and then working with the team to flesh out acceptance criteria and so on. This avoids user stories that are essentially “As a product owner I want… “ instead of “As a student I want…” or “As a teacher I want…”
12. Perry asked the last question – “What are a few tips that you would give product owners?” going over a few SUG announcements to give the panelists some time to form their answers. Jeff answered don’t be afraid to say no, and to be a product owner, not a project manager. Sarahjane recommends that product owners form close relationships with customer, and involve everyone on the team early and often, keeping in mind that the product owner is not a dictator. She emphasized that everyone is an individual and that it pays to make the effort to get to know everyone on the team, even some of the more introverted engineers that take extra effort to get to know. Josey said to live the agile culture. Develop your customers and get data about users. If you build relationships with people you can get anyone to do anything.