Product Discovery enhances the Outcome with Scrum
Good discovery is continuous
A short time ago, I was presented with an open-ended question in an interview.
Q Our current product is built on legacy technology and we would like to migrate it over to the latest technology stack. How would you approach it using an Agile mindset for software development?
In my answer, I jumped straight from product vision (technology migration) to the Sprint Planning, completely missing Product Discovery. A better approach would have been to discover why they want to migrate to the latest technology.
Product discovery refers to the activities required to determine if and why a product should be developed. Carrying out this work makes it more likely to create product users actually want and need.
— Roman Pichler, Product Discovery Tips
Why Scrum?
I want to talk about why Agile mindset before delving into Product Discovery. We can categorize this project as “Complex” (More about the project is unknown than is known) based on the Cynefin framework (created by Dave Snowden) for decision-making. For complex projects, empirical process control, or empiricism, is the best-suited approach.
Identifying Outcomes
Which problems or challenges with legacy software are we trying to solve? What outcomes are we looking to achieve? Migrate it over to the latest technology is more of an output than an outcome. What is an “outcome”? It’s a consequence or the end-result of an action. For instance, keeping a child safe in a car on a high-speed motorway is the outcome and car-seat is the output.
Note: There are plenty of articles explaining the difference between outcome and output. I recently read Output Vs. Outcome by Marisa Morby
Bring the Right People together
Product Discovery is a team sport. You should, therefore, involve the right people in the discovery work and secure enough of their time.
— Roman Pichler
Creating outcomes may seem simple in theory, putting into practice is a little trickier. We need to identify the Customers, Users, the Stakeholders (internal/external who can influence or possess knowledge) and the Development team. Some questions one can ask the right people identified can help construct the outcomes
- What are the challenges with current legacy software?
- Why are we building (or re-building) the product?
- Whose life do we improve?
- Is the product still relevant and valued by customers?
Capturing and visualizing outcomes
Where do we capture these outcomes? Product Backlog. The Product Backlog is comprised of an ordered list of outcomes to be achieved by the team.
Note: In practice, the Product Backlog does contain additional work that needs to be done by the team. For this article, I am simplifying and only considering the Outcomes.
While Product Backlog captures outcomes, a Roadmap best describes how the product is likely to evolve in the longer term. There are lots of techniques to create Roadmaps e.g., Kano Model, Now-Next-Later, MoSCoW
Product Roadmap, a time horizon way of planning for product evolution. Visualisation enhances the impact.
Product Backlog Refinement
The Product Owner and the Development Team collaborate regularly to break down the outcome into functionality to be built, commonly described in terms of User Stories.
This could be to validate ideas, add more details, estimates, and order to each Product Backlog Item.
Product Backlog Items (PBI) are essentially reminders of conversations that we will need to have in the future (Sprints)
Sprint Planning
Crafting a Sprint Goal, an objective that will be met within the Sprint, the development team forecasts the functionality that will be developed during the Sprint to achieve Sprint Goal. The functionality is commonly described through User Stories and sits on top of the Sprint “Ready” backlog
Sprint, Increment and Adaptation
The diagram above describes the entire process from Roadmap through to Potentially Shippable Increment of Done Stories.
Note: I have considerably simplified the Product Discovery and Development learning loops
Conclusion
For most of the projects, there are too many unknowns for the Product and Development Teams to jump straight into a Spring Planning event. Product Discovery and validating hypothesis help create high-value refined Product Backlog Items to be delivered in Sprints.
Moreover, since Product Discovery is performed by the collaboration of the Product and Development Team and not by some separated design team, more innovative solutions are likely to emerge over time.
