“We gotta get a quick win here.”
Progress is motivating. But the nature of the progress matters.
Too often, in the quest to show progress early in an initiative, leaders overemphasize getting something done quickly and miss how the nature of what gets done matters. When we look at actual product backlogs for new initiatives, we often see early work that is small but that avoids the core reason why the initiative is happening. It’s infrastructure work. Or it’s minor features that are easy to do quickly but not connected to the core value.
This reveals a tension many leaders don’t know how to break: The core value of any new initiative tends to be associated with the most complex part of the work. And it’s hard to imagine getting a small, quick win in the complex stuff. So, they go for quick…and miss the win. It’s quick vs win, not quick + win.
What’s the Difference?
Here’s an example of moving from an easy, but illusory, quick win to an actual quick win…
Some years ago, Richard led a software team responsible for developing a system to help wastewater engineers optimize wastewater plants to handle more waste without capital investments.
The typical “quick win” approach would be something like: “Let’s build the first table in the data warehouse and get data coming in from various plants.” That looks like progress. But no matter how much data gets collected in the data warehouse, it doesn’t do anything to achieve the core purpose of the initiative—helping wastewater engineers make better, faster recommendations for their clients. It’s just a technical task that, hopefully, will eventually contribute to that outcome.
Instead of taking that approach, Richard and his team looked for a true quick win. They talked with engineers who were just starting a new optimization project and asked them, “What’s an important question for you to answer from the data in this plant that’s normally time-consuming or otherwise painful to answer?” As a result of that discussion, the team built the world’s simplest data warehouse—a flat file with data from that one plant to answer that one question, updated nightly—with just enough reporting on top of it to help answer the question. They shipped it two weeks into the project. And those engineers used it to get real value right away.
This was a true quick win. Customers experienced real value. The team learned a lot about the core complexity of the initiative. And the delivery risk was lowered right away because the team had a chance to explore several parts of the solution in a short time.
Feature Mining FTW
The way out of this quick-vs-win tension is to identify a thin slice through the core complexity, something that’s small but also meaningful. This is what our Feature Mining technique is designed for.
In a Feature Mining session, a cross-functional group brainstorms on the following questions:
- What impact are we trying to create with this initiative?
- What makes it a big effort in terms of time, expense, other resources, etc.?
- Where’s the risk? What could go wrong that would cause us to fail to achieve the desired impact?
- Where’s the uncertainty? What do we need to learn in order to succeed?
Then, the group goes through a structured process to identify first steps that could provide some impact, risk-mitigation, and learning with all the bigness. These are true quick wins.
Want to learn more about Feature Mining? You can try it on your own right away with our Feature Mining Miro template, which includes step-by-step instructions. You can also get a video walkthrough in our self-guided 80/20 Product Ownership online course. Or sign-up for a live Certified Scrum Product Owner or Advanced Certified Scrum Product Owner class to learn the technique with Richard.
Last updated