In this interview, Ellen Gottesdiener talks about her presentation at Agile Development Conference and Better Software Conference West 2014, the importance of having context for requirements, good ways to set value considerations for requirements, and the common mistakes of product owners.
Ellen Gottesdiener will be presenting a presentation titled "The Essential Product Owner: Championing Successful Products" at the Agile Development Conference and Better Software Conference West 2014, which will take place June 1–6, 2014.
Cameron Philipp-Edmonds: All right. Today we have Ellen Gottesdiener and she will be speaking at the Agile Development Conference and Better Software Conference West 2014 which is June 1st through June 6th and she is giving a presentation titled The Essential Product Owner: Championing Successful Products.
Ellen Gottesdiener, founder and principal with EBG Consulting, is an internationally recognized leader in the collaborative convergence of requirements plus product management plus project management. Ellen coaches and trains individuals and teams and facilitates discovery and planning workshops across diverse industries. She writes widely and speaks to conferences worldwide. Ellen co-authored, with Mary Gorman, their 2012 book, Discovery to Deliver: Agile Product Planning and Analysis.
Ellen Gottesdiener: Discover to Deliver. Yep.
Cameron: Ellen is author of two other acclaimed books, Requirements by Collaboration and The Software Requirements Memory Jogger. Anything else to add?
Ellen: No. That's great. Thank you, Cameron.
Cameron: Okay. All right. Fantastic, and because you're doing a session titled The Essential Product Owner: Championing Successful Products, I would like to ask you about balancing strategic and tactical activities to insure that the product is built correctly.
My first question is, in your presentation you talk about techniques to set context and share understanding of requirements. Why is it important to have context for requirements?
Ellen: Well, it's vastly important. I think we could draw on Lewis Carroll's quote from Alice in Wonderland when he said, "If you don't know where you're going, any road will get you there." Everyone on the team really needs to have a shared understanding of the long game and having that context. Context really counts. It gives everyone focus and energy. Not only that, when you're looking at what your potential options for building the product, those requirements, are, actually constraints is a way to unleash creativity.
The other piece of that context is that people are going to do their best work when they can contribute to defining the outcomes and building that shared understanding of the requirements, of the product needs, which basically are the requirements. That's what context setting is all about.
Cameron: What is a good way to set value considerations for requirements?
Ellen: You know, that's a great question. Let me first define value considerations. When we use that term, and Mary Gorman and I use that in our book Discover to Deliver, what we're talking about are attributes that help you assess the value of potential product options. Options are alternative ways or alternative requirements that you might have and not all options are created equal.
The first thing to do to figure out what the value considerations for your requirements or your product options are is to know the stakeholders. That's really essential. It's always been true. We like to think of stakeholders, cast the idea of stakeholders, a little bit differently. We like to think of them as partners or product partners. You want to look holistically at these people from three basic constituents. One is, obviously, the customer. The next would be the business and the third would be the technology. What you want to do is explore what might be valuable to all three of those partners at any given point in time and they could be competing. You may not be able to satisfy some business need for having protection from regulatory compliance while at the same time giving the customer great design, instant gratification and time saving. You have to balance these kind of things.
Ellen: Having an explicit conversation about those partners and their value considerations we find to be really, really powerful.
Cameron: Okay. In talking about a balance a little bit here, why should product owners really care about long term goals when many projects are asked to find success right away and to find success in the short term?
Ellen: Yeah, that's a really tough problem that all product owners, that all product managers have. The long game, the long term goals are about the sustainability of the product which feeds the health of the business and the organization. There's always this balancing act of delivering value now as an investment for the future. Some times you have lots of start-ups that are trying to get short term gains, but a lot of start-ups stop and then start because they don't have the long game or they're not able to sustain that, or as they grow, the feasibility of the product becomes a product because they can't satisfy quality attributes for a larger, for scaling the product.
This going to always be a struggle that product owners have, is the sustainability and long term goals of the product, the end game, the vision, the goals, the objectives, with some immediate return, which ideally will provide investment for ongoing development of the product.
Cameron: Okay. Since we have such an instant gratification mindset in today's society, what are some ways that they can kind of at least keep it in mind that they have to have sustainability and success in the future?
Ellen: Yeah. Well,, what we've been finding over the years in working with Agile teams is that everybody likes to have conversations and to balance the long game with the short game or the big view with the now view or the preview, we find that having structured conversations are really helpful. The structured conversation follows a Meta pattern that I learned many, many years ago as I was growing in my profession as a professional facilitator, which is to explore the open-ended divergent and then evaluate, or the convergent conversations. We want to explore in an open-ended way and then use value, value considerations and potentially some prioritization schema that the product owner in conjunction with the team will discuss using, that explored "stuff". Those options will be evaluated and narrowed and thinned down and then the team has conversations to confirm, that is, so they can verify and validate the options.
During that open-ended time, if your context is the preview, say, release view or the future view of the product, the product read mapping which we call the big view, then they're going to have options at a high level that are thinking about that long game. Eventually, although a team may start, an Agile team may start with the now view and going sort of from iteration or release to release, once they get a pattern of delivery and engineering, that engineering muscle gets going, we need to strengthen the discovery muscle for the long game and have the ability to do this on an ongoing basis. There's a constant conversation going on of discover, deliver, discover, deliver.
Cameron: All right. Now, you talked a little bit about being value focused and having the right context, but what type of attitudes should a successful product owner have? How does that attitude overshadow a product owners personal attributes?
Ellen: Ah, well, I like to think of a difference between attitude and aptitude. Attitude is your mental state, your beliefs, your feelings and your values, so that's kind of the question you have. The aptitude is someone's ability to do certain things or get things or get things done. In terms of attitudes of a successful product owner, I think that there are some really key ones including curiosity. Curiosity for the customer, curiosity to understand the deliver and engineering practices and the technologies and curiosity to try to balance how the business, customer and technology needs can be solved. I also think empathy, in particular empathy obviously for the customer and the end user, but also empathy for the team because we're all working, you know, this is our family at work, is our teams at work.
I think another attitude that's really important is a tolerance for ambiguity along with a concrete drive for specificity. This becomes very important. When you were asking the question, Cameron, before about balancing the long view, the big view, if you will, with the now view and that preview in the middle. If you're tolerant, if you allow some ambiguity of what exactly the features are that are going to really satisfy the market and the customer while at the same time as you're going from iteration to iteration or release to release, you're providing specific details to verify the stories, if that's what you're using, to specify requirements, very, very clearly and unambiguously. That's a really cool kind of balancing, that tolerance for ambiguity with drive for specificity.
I think the other thing, probably the last thing, would be the desire for collaboration, to build that shared understanding amongst all those product partners and throughout all those many, many cycles of discovery and delivery. Those would be attitudes that I think are really valuable in a product owner.
Cameron: Okay. Other than not having those attitudes or not focusing enough on the long game, what are some common mistakes that product owners make?
Ellen: I'd like to cast that question in two parts, tactical mistakes and strategic mistakes. Tactically is about the day to day, the now view work that the product owner needs to do in working with the team. Probably the biggest thing is not having the stories or requirements or features or MMX or whatever you want to call those chunks of functionality, not having them ready for the team to do estimating and planning. That's one big thing and in addition, making sure that those, let's say they're stories, are sliced strategically based on value and using those value considerations at that point in time. Having a thorough look at what the options are and slicing based on value.
The other thing that we see a lot is there's a lot of frantic product owners that are having trouble being available to the team and answering questions quickly, as well as having the ready requirements, really thwarts the team's ability to deliver. Those are some of the big things tactically.
Then when it comes to strategically, you know, not a lot of people talk about that. They're classic product owner. People are thinking of going from iteration to iteration but this person, like we said before, needs to have the long view in mind. They need to get out, visit customers or observe the customers, use practices to understand and empathize with the customers in proactive way. Also, a product owner from a strategic point of view needs to manage up at the executive level and over with other constituents, like sales, marketing, support, operations and so forth. Strategically, a lot of product owners are more heads down day to day and not doing this work looking to the outside world. Understanding the market, conducting competitive intelligence and organizing for greater involvement across the organization.
Cameron: Okay. Now some more general questions, more about you. You've written several books. We covered some earlier. You speak at conferences across the world, including ours. Which activity, speaking or writing, have you found the most rewarding and why?
Ellen: Rewarding. Oh boy. This is difficult to be a binary kind of a thing, Cameron. I find different benefits from different things. You've mentioned speaking and writing and a third thing that we do is actually working with clients on product discovery, so we're really doing this work because that feeds the writing and the writing feeds the work and the speaking and so forth. I think there's different types of energy and learning that I get from them. When it comes to the writing, that feeds my internal energy. When it comes to speaking and, of course, working directly with clients doing product discovery work, that feeds external energy. They're rewarding in different types of ways.
Cameron: Okay. Okay. Now, if you can make the attendees of your presentation walk away with one tidbit of wisdom and one prevailing concept, what would that be?
Ellen: I think that would be that discovery is just as important as delivery and it's built on strong community and collaboration.
Cameron: Okay. Is there anything else you'd like to say to the delegates of Agile Development Conference and Better Software Conference West 2014 before they attend?
Ellen: Well, this is a great event. It really is. Really high quality speakers and a wonderful networking opportunity, so I guess maybe I would suggest, and this is what I do in preparing to go is, I come with one puzzle or one conundrum that I'd like to get some ideas or solve. I make a personal assignment for myself to try to get answers to that.
The second thing I would do, I would do and suggest doing, is to come with one pay forward. One thing that in your work you found works, that you want to share, that you want to give back to the community, whether it's at lunch and during the networking breaks or whenever. Just spread the word about that to other people.
Cameron: Okay. Thank you so much. Once again this is Ellen Gottesdiener and she will be speaking at Agile Development Conference and Better Software Conference West 2014 which is June 1st through June 6th and make sure to attend her presentation which is titled The Essential Product Owner: Championing Successful Products. Thank you so much Ellen.
Ellen: Thanks. Look forward to seeing you there. Bye-bye.
About "The Essential Product Owner: Championing Successful Products":
Engaged and passionate product owners balance strategic and tactical activities to ensure that the right product is built—and built right. Yet how do these product owners guide planning toward longer-term goals while also ensuring that requirements are sufficiently understood for development and delivery? Join Ellen Gottesdiener as she shares techniques for setting context and collaboratively establishing a shared understanding of requirements. Discover methods to envision the product and identify the stakeholders and their value considerations. Experience a simulated agile discovery workshop—slicing requirements based on value and allocating features, minimum marketable features, and stories to planning horizons. Learn how iteration, release, and product roadmaps plans are interwoven and aligned to the product’s strategy. Take away proven techniques to identify and allocate requirements to plans, to make difficult and effective value-based planning decisions, and to refine a lean product backlog. Leave with a new appreciation for the attitudes and aptitudes of a successful product owner.
Ellen Gottesdiener, founder and principal with EBG Consulting, is an internationally recognized leader in the collaborative convergence of requirements + product management + project management. Ellen coaches and trains individuals and teams, and facilitates discovery and planning workshops across diverse industries. She writes widely and speaks at conferences worldwide. Ellen coauthored (with Mary Gorman) their 2012 book, Discover to Deliver: Agile Product Planning and Analysis. Ellen is author of two other acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.