Enhancing Product Discovery to Avoid Scrum Failures
Written on
Products succeed or fail based on two critical aspects: “what to build” and “how to build.”
There is a common misconception that Scrum is merely a framework for delivery, focusing primarily on the “how to build” aspect, neglecting the “what to build.” This misunderstanding leads to significant challenges.
In a previous role at a large organization, I observed that product discovery was entirely detached from the delivery process. Discovery efforts were often led by individuals outside the Scrum team, leaving the Scrum team solely responsible for execution. This siloed approach made it impossible for me to succeed.
Product discovery, which defines “what to build,” is much more than just design, backlog refinement, and sizing.
Let’s dive into what product discovery really involves, the frequent mistakes made in the process, and the mindset needed for effective discovery. We will also analyze how Scrum facilitates discovery through an empirical approach.
Understanding Product Discovery
Product discovery focuses on determining "what to build."
Our product backlog often becomes cluttered with requests such as:
- Features demanded by the CEO
- Promises made to customers by the VP of Sales
- Security compliance mandates from the Chief Security Officer
- Demands from significant customers
- External pressures to adopt trending technologies like Blockchain or AI
This creates a significant challenge for teams as they struggle to prioritize effectively amidst these high-stakes demands.
To clarify what to build, we need to explore two main areas:
- Problem Space: Identifying the right problems by understanding customer pain points and needs.
- Solution Space: Once we grasp what customers seek, we can identify optimal solutions to address those needs.
Where Do We Go Wrong in Product Discovery?
Insufficient Time for Problem Space
Teams often rush to solutions without thoroughly analyzing the underlying issues. For instance, when users struggle to search for items on our platform, our instinct is to brainstorm fixes instead of asking essential questions like:
- What are the reasons for these search difficulties?
- How long have these problems been occurring?
- How many users are affected?
Effective product discovery is about exploration and understanding, not merely planning. A plan is only meaningful when it’s informed by thorough exploration.
Discovery Focused on Estimation
For many, product discovery is synonymous with breaking down epics into user stories and estimating them for stakeholder timelines. This often shifts focus away from understanding the problems in favor of solutions and predictions, especially when high-fidelity designs are already available.
Estimation should be a minor aspect of discovery, emphasizing our understanding of the problem and whether our planned solution will achieve the intended results.
> “Scrum recognizes a single criterion for estimation: do we believe it can be accomplished in the Sprint or not?”
> — Sjoerd Nijland
Discovery Without Historical Evidence
Evaluating the impact of previous releases is significantly more challenging than measuring output metrics like velocity or cycle time. Important metrics often go overlooked, as internal meetings consume valuable time.
Ignoring the lessons learned from past projects prevents us from identifying genuine customer pain points. Personal experiences have shown me that seeking user feedback based on prototypes often results in responses colored by cognitive biases.
Instead of asking if a solution will solve a problem, we should let users engage with the product and then inquire if it truly addressed their issues.
Prolonged Discovery Phases
Limited ability to measure the impact of deliverables often leads teams to rely on planning, which can stall discovery for extended periods. Issues like unclear roadmaps, customer attrition, and declining metrics often result in further planning rather than discovering.
Rigid, assumption-based roadmapping is not true discovery. The more detailed our plans become, the less adaptable we are to change. In today's fast-paced environment, flexibility is key.
> “The most significant barriers to effective Scrum are ingrained habits from decades of waterfall methodologies, leading to command-and-control management and a belief that simply demanding results will yield them.”
> — Ken Schwaber
Separation of Discovery and Delivery Responsibilities
I once witnessed a scenario where a product manager included developers in discovery discussions, only to have a senior product manager question their involvement. This reflects a common issue in velocity-driven organizations.
Transitioning from a feature-centric mindset to a value-focused approach across the organization is a considerable challenge today. Although the concept of a Product Trio, consisting of a product manager, senior designer, and senior software engineer, has gained traction, many organizations misinterpret its application, isolating the trio from the core delivery team.
What I Have Seen That Can Help?
Define Product Vision
A well-articulated Product Vision provides a clear direction for the future of your product, serving as a benchmark for measuring progress and alignment.
An example of a Product Vision could be: “Establish a digital platform to facilitate at least 1 million hours of premium pair programming between software engineers and industry experts.” This statement conveys a distinct goal, customer value, and business impact.
> The Product Goal in Scrum aligns closely with this vision, often seen as a stepping stone toward the ultimate Product Vision.
Invest Time in the Problem Space
Avoid the temptation to jump into solutions too quickly. Instead, focus on comprehending how customers interact with the product, the challenges they face, and what features they value. Traditional interview questions may not yield valuable insights.
For example, if asked what I want more from LinkedIn, I may struggle to provide a precise answer. However, analyzing my user journey with both quantitative and qualitative data would reveal features I love and would pay for.
Additionally, develop the ability to distinguish core needs from superficial desires.
My young son once insisted on making fruit ice cream, yet showed little enthusiasm for eating it. I eventually recognized that his true desire was the shared experience of preparation rather than the ice cream itself.
Encourage Team Autonomy
To cultivate a sense of ownership in creating customer value, a fully cross-functional product team is essential. This team should handle all aspects of discovery and delivery, making collaborative decisions.
While interaction with departments like sales and marketing is crucial, the team must be empowered to make its own decisions. If decisions are made for them, it stifles learning and hinders the product's success.
Adopt Continuous Discovery Practices
Customer needs and desires are constantly evolving in a competitive market. Engage with customers regularly to gauge their changing expectations and frustrations. Each interaction can provide meaningful insights.
Before deciding on the next steps, reflect on the impact of past decisions and incorporate those lessons into your discovery process.
Scrum and Product Discovery
Product discovery is a prevalent topic in the Product Management sphere. While the term "discovery" isn't explicitly mentioned in the Scrum guide, "inspection" is highlighted frequently, relating closely to the discovery process. Regardless of terminology, Scrum addresses the critical question of what to build.
> “Scrum is built on empiricism and lean thinking. Empiricism posits that knowledge is derived from experience and decision-making based on observations.”
> — Scrum Guide 2020
Scrum creates a closed-loop system where we continually decide what to build based on previous insights. The rationale behind Scrum's recommendation for Sprint lengths of one month or shorter is that if you can reliably predict user needs beyond that timeframe, the domain is likely uncomplicated, rendering Scrum unnecessary.
Sprint Increments enhance transparency. Once released, these increments allow us to analyze user journeys, identifying needs and pain points that inform our next steps.
During the Sprint Review, we assess whether the value generated from the Sprint Increment resonates with key stakeholders. Their feedback guides us in exploring new avenues for delivering business and customer value.
Frameworks like Evidence Based Management (EBM) and Objectives and Key Results (OKR) assist in quantifying our observations, enhancing our decision-making process.
After exploring the problem space, Sprint Planning transitions us into the solution space, enabling us to identify the most effective solutions for the upcoming sprint.
In summary, I resonate with Willem-Jan Ageling's insight:
> “Scrum is about discovery through delivery.”
Assuming that discovery will inherently lead to future value is a narrow perspective, just as delivering without evaluating previous efforts is neglectful. Discovery and delivery are fundamentally intertwined.
What experiences do you have regarding Product Discovery? I am eager to learn from your stories.