Purposeful Quick Wins: How to Get Momentum without Avoiding the Hard Stuff


The core value of any new initiative tends to be associated with the most complex part of the work. But it’s hard to imagine getting a small, quick win in the complex stuff. So, we go for quick…and miss the win.

In this episode, Richard and Peter talk about quick wins, how they often emphasize the quick part but miss the win, and what to do instead at the start of a big initiative.

Additional Resources

Learn More

Episode Transcription

Richard Lawrence

Welcome to the Humanizing Work Show! In this episode, we’re going to look at why going for quick wins is tempting, but maybe not always a good idea.

Before we get into that, though, a few quick reminders:

Peter Green

Number 1, if you have a question or challenge you’d like to hear us address on the Humanizing Work Show, send us an email at mailbag@humanizingwork.com. We read every message we get there, and they help us ensure the show talks about what you care about when it comes to your work.

Richard

Number 2, you hear this on all the shows you watch or listen to, I’m sure, but it really does matter. If you find our content useful, liking episodes, subscribing to the show, leaving a review on iTunes, sharing it with your colleagues—all those things help the right audience find and benefit from the show, and we really appreciate it.

Peter

Finally, Number 3, the show isn’t the only free content we produce. We also send out a newsletter with one key idea every week. Want to get on that list? Sign up at humanizingwork.com/hwnews. Now, onto the show.

Richard

After our July Humanizing Work community meetup (which you can attend, by the way), where I’d mentioned in passing a concern with ill-considered quick wins—long-time community member Michael O’Neill sent us a sort of tongue in cheek but thought provoking mailbag email. I enjoyed how he posed the question, so rather than summarizing it, I’m going to just read Michael’s email. Here’s what he writes:

What’s the deal with quick wins?

From time to time (ahem) I hear esteemed coaches and visionaries in this space express concerns around investing in “quick win” stories.

What’s the source of the concern?

Doesn’t this term “quick win” describe important attributes of a well-groomed story? “Quick” suggests that it is sized appropriately to be completed expeditiously by the team.  Granted, “quick” is a relative term, but generally speaking, it suggests the “win” can be delivered within the confines of a sprint (with a bias towards smaller increments of time within the sprint).

Furthermore, the term “win” suggests it delivers value.

Small fast stories focused on delivering value…What am I missing?

There seems to be an assumption in the terminology that I’d like to understand better.

Pedantically yours,

Michael

Peter

When we’re at the start of a big challenging effort, getting started and making early progress is motivating. In Teresa Amabile’s fantastic book “The Progress Principle,” which we’ll [tk] link to in the show notes, she describes her research on 100s of teams that showed that making some small progress on something that mattered to someone was more motivating than any other factor, by a large margin.

Quick wins are definitely powerful. But too often, in the quest to show progress early in an initiative, we overemphasize getting something done quickly and miss how the nature of what gets done really matters. For example, when we work with agile teams and look at actual product backlogs for their new initiatives, we often see early work that is small but avoids the core reason why the initiative is happening in the first place. It’s infrastructure work. Or laying the groundwork. Or it’s minor features that are easy to do quickly but not connected to the core value of that initiative.

This reveals a tension that’s hard to break: The core value of any initiative tends to be associated with the most complex part of the work. But it’s hard to imagine getting a small, quick win in that complex stuff. So, we go for quick…and miss the win. It’s often quick vs win, and not quick + win.

Richard, you’ve shared an example of breaking that tension with a team you were working with. How did you do that?

Richard

Ya, I was working with a software team responsible for developing a system to help wastewater engineers optimize wastewater plants to handle more waste without capital investments. Basically, cities are growing faster than their infrastructure grows, and so you need to find capacity to keep up.

The typical “quick win” approach would be something like this: “Let’s build the first table in the data warehouse and get some data coming in from various wastewater 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 this initiative—helping the engineers make better, faster recommendations for their clients. It’s just a technical task that, we hope, will eventually contribute to that larger business outcome.

Instead of taking that approach, on our team, we talked with some of the engineers and leaders who were just starting a new optimization project and we 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 get an answer to?”

As a result of that discussion, we 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; and shipped it a couple of weeks into the project. And those engineers used it to get real value right away.

Peter

One of the things I love about that example is that it was a true quick win. You got all of the motivation and momentum benefits we’re trying to get from a quick win, while simultaneously going right after that tricky stuff that often gets pushed later in a project. The team learned a lot about the core complexity of the initiative right away. The delivery risk was lowered right away because the team had a chance to explore several parts of the solution in a short time. And, two weeks in, they were getting real customer benefit.

Richard

Right, so we’ve discovered that this is a repeatable approach. The way out of the quick-vs-win tension is to identify a thin slice through the core complexity, something that’s small but also meaningful, which is exactly what our Feature Mining technique is used for.

Peter

Yeah, I was just thinking that Feature Mining is a great tool to do this. For people listening that might not be familiar with Feature Mining, Richard, will you give us a high level overview?

Richard

Sure.  In a Feature Mining session, which is a 60 to 90 minute conversation with a cross-functional group–people who understand the problem side of things;  the business side of things, people who understand the solution or technical side of things– that cross-functional group brainstorms on four 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?

So, we brainstorm on impact, bigness, risk and uncertainty. Then, the group goes through a structured process to identify first steps that could provide some impact, some risk-mitigation, and some learning without all that bigness. It has become a way to reliably find true quick wins.

Peter

We’ve added a Feature Mining template to Miro’s “Miroverse” template library, so anyone using Miro can download it and use it for free. We’ll drop a link to that in the notes. That template also has step-by-step instructions so you can try it out right away.

Richard

People can also get a video walkthrough and facilitation guide for Feature Mining in our self-guided 80/20 Product Ownership online course. Or if you want to talk through it live, sign-up for one of our Certified Scrum Product Owner or Advanced Certified Scrum Product Owner classes, where I cover it in those classes. 

Peter

I’m sure many of you listening have run into this challenge before, and you’ve probably come up with some cool examples of breaking that tension. Drop a comment if you’re watching the show on YouTube or on our socials and share your example. I think the more examples we have, the more it will help inspire cool ideas for anyone struggling to figure this out. Thanks for checking out today’s episode, and thanks, Michael, for the great question.

Last updated