We caught up with Ellen Gottesdiener, who is a Product Management Festival tutorial and session presenter as well as USA Ambassador. Ellen will present a tutorial on 17th, “The Essential Product Owner: Championing Successful Products”, a conference session on the 18th “Product Roadmaps: Collaborating to Discover and Deliver Value” and facilitate the Lean Café.
Ellen and her colleague Mary Gorman have written a book titled Discover to Deliver: Agile Product Planning and Analysis. The book is described as providing a “toolkit of Agile/Lean practices for evolving products through the ongoing, interwoven activities of product development”. It contains six sections, beginning with a case study narrative of three discovery work sessions. It then goes on to present each of the important concepts, how to use the structured conversation, and ways to adapt your discovery practices. The final section explains the usefulness of thirty-five planning and analysis tools and techniques.
Why did you write this book – what is the problem you are addressing with this book?
Ellen: In our client work, we see teams struggling with many similar issues – no matter where they’re located, no matter what kind of products they’re dealing with. If we had a Top 5 “Missed Opportunities” list, number 1 would be missing the chance to base your delivery decisions on value – determining, in a disciplined way, what you expect any given bit of work to return in value to the organization.
Mary: Another missed opportunity we often see is when teams don’t collaborate efficiently as a team. It’s also a challenge to “right-size” stories, to clearly define a product’s scope, and to quickly adapt to changing conditions.
Ellen: In the book, we wanted to share essential, practical techniques that people can use in their daily work to address these and many other problems.
Who is the target audience for this book?
Ellen: Well, you know what they say: eat our own dog food (or as we prefer, drink your own prosecco). So we applied agile practices to writing the book, and the first area we looked at was our audience (the “User” dimension, as we’ll discuss). We created personas and an empathy map of target readers — Barry the Business Analyst and Polly the Product Manager. We had other readers in mind, but we focused on these two to start.
Mary: As we wrote chapters and then analyzed feedback from our wonderful reviewers, we realized the book would serve as a shared resource by anyone involved in planning and analyzing software-intensive products using agile/lean principles. That includes people who collaborate across disciplines — architecture, business analysis, coaching, product management, project management, software development, testing and quality assurance, user experience.
Ellen: So our target audience became the team as a whole. Our goal is to show teams how to collaborate continually to discover and deliver an evolving product. It’s been gratifying to hear from our readers that indeed, they find the book is a shared resource in their teams.
A strong message in the book is the concept of VALUE – why is this so important, isn’t the purpose of product development to understand business needs and address those?
Ellen: Oh, value is absolutely key – it’s a mantra in agile/lean practice. The question is, Whose value? After all, value is in the eyes of the beholder. Different stakeholders have different perspectives of value.
Mary: So we like to use the term “product partners” to indicate a healthy stakeholder community acting in partnership. The partners include people from the customer, business and technology communities. Together, they collaborate to reach a shared understanding of the product, and they decide what will be delivered at any given time.
Ellen: Each partner’s perspective of value is different. The organization doesn’t always have the same perspective on value as, say, the customer. And vice versa. Same for technology and business, technology and customer. So, for example, customers may value convenience, the business may value complying with regulations, and technology may value readiness or alignment with the existing architecture.
Mary: A crucial part of the process is for the partners to understand each other’s value considerations. Then they quantify the anticipated value. Then after each delivery, as soon as possible, they validate their anticipated value against actual value. Any gap gives them a start on deciding how to adjust their plans for what to deliver next.
So acting as product partners, the stakeholders can make timely, fast, yet informed decisions about what to build next.
Please share the background on the 7 Product Dimensions – what was the genesis for it, how do you use it?
Ellen: Everyone talks about requirements, but there’s often lots of confusion when it’s time to plan and analyze them. The classical breakdown of requirements into functional and nonfunctional helps, but it isn’t clear enough. It doesn’t specify what’s included. So we defined the 7 Product Dimensions, which break down all the aspects of a product into categories. Product partners can use the 7 Product Dimensions to ensure that they get a holistic, comprehensive understanding of the product.
Mary: For functional requirements, the dimensions are User (who or what interacts with the product), Action (the capabilities of the product), Data (the product’s repository of data), and Control (how the product enforces constraints like business policies and rules).
Ellen: Then the nonfunctional dimensions are Interface (the mechanism for connecting with users and systems), Environment (the product’s physical properties and technology platforms) and Quality Attributes (for example, performance, usability, security of of operation and efficiency, portability, testability of development).
Mary: In our client work, and for the book, we designed unique symbols and colors for each dimension. You can see the dimensions here and download the Options Board kit to use them in your product discovery sessions.
You present the idea of Structured Conversations – how are these different from normal elicitation conversations that are used in product development today?
Mary: Well, as many of us can testify, not all product conversations are effective! To help teams make the most of their product conversations, we realized our most efficient and effective conversations were, at their core, a meta process we call the “Structured Conversation” It’s not hard to learn, and it’s empowering.
Ellen: The conversation is structured around three activities. First, you explore product options—potential requirements. You expand your thinking, and you consider possibilities for each of the 7 Product Dimensions that’s relevant to the product option at hand. Next, you evaluate the options within and across the dimensions. Using value considerations defined beforehand, you identify which options you believe will provide high value and assemble them into cohesive sets. Depending on your planning horizon—how far ahead you’re planning at the moment—each set of product options could be a candidate solution, a minimum viable product, a minimum viable feature, or a story. And the third step is, the conversation isn’t complete until you confirm the team’s understanding by verifying and validating the results by using acceptance criteria. Validation happens after the delivery cycle.
Mary: In our practice, we find that the structured conversation is a great framework for collaborative decision making across disciplines. And it works at all planning horizons.
Ellen: That’s because it combines divergent and convergent thinking, analysis and planning. We find it levels the playing field by helping partners from all three areas (customer, business, and technology) to equally participate and learn from each other.
We encourage teams to “work the walls”—post the 7 Product Dimensions, explore the options, sketch models. (Check out these samples.) It’s impressive to watch how holistically visualizing the options can quickly facilitate the conversation!