Driving Toward Better Business Outcomes With Discovery
Every good product manager knows we should be talking to customers early and often, so we can understand their needs, desires, pain points and preferences. When we don’t have these conversations, the results are apparent: features nobody uses, products that don’t meet customer needs, etc. Talking to real or potential users is the way to get a deeper understanding of the real problems your product can solve. But, when does this “talking to the customer” actually occur? When is there time in a product manager’s day to identify the right people to speak with, understand their pain points, share prototypes, and get feedback? Where in the Agile development process is there room for this?
This is a challenge faced by many Agile product teams. While many organizations invest in delivery frameworks through the implementation of Agile, etc., few have made a similar investment in driving toward the right outcomes. The larger the organization, the greater the problem. To overcome this, organizations have to be much more intentional about creating the space to make discovery happen, otherwise things will always get in the way.
Discovery is the creative product management response to this challenge. Make customer conversations part of the development cycle to ensure a balanced investment in both outcomes and outputs.
Making customer conversations a priority
At our company, it was the problem we were facing as we dove into the development of our new platform. We knew the right thing to do was speak to our customers, but we already had a list of features provided by our stakeholders that was 10 miles long. We also had 20+ development teams, eagerly waiting for their backlogs to be filled ahead of our quarterly development planning activities. Organizational inertia was pulling us in the direction of just defining the long list of stakeholder-requested features. But as champions of value delivery, we knew that to get the platform right, we had to create the time and space for discovery conversations with real customers. We decided to make them a priority. We designed a discovery framework that not only laid the groundwork for these customer conversations, but also involved the stakeholders and engaged the rest of the product organization in the process.
Cross-functional collaboration is key
First, we knew that to be truly effective, these discovery conversations needed to be highly cross-functional, driving toward the tightest alignment and feedback loops we could create. We based team membership on our organizational structure, ensuring each critical role was represented on the discovery team. In our first iteration of the discovery framework, we included representatives from our product management, engineering, UX, QA and architecture teams. We also invited key business stakeholders from across the organization to join in. However, we did find that because there were so many interested stakeholders, discovery teams quickly became unwieldy. To overcome this challenge, we iterated, ultimately landing on a defined “core team” and “extended team” model.
We provided our intrepid discovery teams with guidance on when to include or exclude the extended team from working sessions. (Hint: Include extended team members when they can provide critical information and offer feedback from their unique perspectives; exclude them when you’re iterating on design.)
Next, we had to carve out the time and space for these cross-functional teams to get quick feedback from customers. Engaging customers in giving feedback is not a unique concept. Product managers working at organizations that place emphasis on getting customer feedback routinely invite them to participate in UX listening sessions, focus groups, one-way-glass user-testing sessions or design sprints. We knew there was no “one best way” to engage with the customer. We had to consider our organizational structure, the product we were building and how our users interacted with it to define a way that worked for us.
Making discovery part of an Agile development process
Takeshi Yoshida of Lifecycle Management suggests a very simple method of merging Design Thinking with Scrum by creating space for empathy, definition and ideation ahead of work coming to a scrum team, as illustrated here:
This, along with the work of discovery guru Teresea Torres, became the foundation of the framework, which we tweaked and twerked until we got it to appropriately fit our “Scaled Agile” context.
Our discovery process ended up including four stages: understand, ideate, validate, define. Since our team was working on a large platform-replacement project, we had to start not just by empathizing with our customers and their pain points, but also by understanding existing functionality and use cases. Input on the existing functionality and use cases came from existing users and the internal stakeholders who were engaged as part of the extended team.
Insights from the understand stage fed into a series of ideation sessions, where the core discovery team designed potential solutions that achieved the desired functionality, while addressing customer pain points, desires and unmet needs. Because of the complexity and interconnected nature of our solution, validation was critical. Validation was our opportunity to consider any impacts of the decisions and assumptions of the discovery team on the larger solution. Once again, the extended team’s contribution to the validation process became the real key to our success. With added confidence on what needed to be built, the fourth stage had the discovery team defining the desired functionality as epics and features ready for the Agile delivery teams to tackle.
The implementation of our discovery framework, like any good product, was an iterative process: Though we worked fast to get the MVP version from our discovery teams into “market,” we regularly checked in with the teams to identify what worked well and what needed improvement. We did this with an understanding of our goal: to maximize the delivery of value to the end user and delight them in every software release. We did so, even though the hurdles to implementing new systems and processes at our organization were significant. We believed the results would be worth the investment — a belief that hindsight has now confirmed! So, we share this with a new goal in mind: Support other product leaders in overcoming their environmental constraints to maximize the delivery of value to the customer by investing in discovery.
About the Authors
Stephallen is a visionary product leader in the field of education technology. She specializes in the development of product management teams, with a focus on customer-centered, design thinking.
Anjali Leon is founder and principal of PPL Coach - a boutique coaching, training and consulting practice that offers experiential skills development workshops and programs, innovative consulting solutions, and professional leadership coaching in the areas of value-driven product leadership, and values-based people and personal Leadership. She specializes in Design Thinking and Lean and Agile principles and practices.
