How an Incremental, Small Slice Approach Gives Real Progress

Instead of making fake progress on some phased approach, we started splitting our work so that every few days or weeks, we were making actual progress through small deliverable slices of value and learning.

Typical status reports start out green, go yellow if issues pop up, and only turn red if things get really, really bad. In this episode, Peter and Richard explain why status reports should have to “earn green” and how you can use this mindset to find good places to start on any initiative (even if you’re not actually creating status reports).

Learn More

Finish banner

Learn concepts, techniques, and tools for tackling complex work in small slices with ease in 80/20 Product Backlog Refinement, a self-guided course from Humanizing Work designed for Product Owners, Managers, and anyone steering the direction of a product.

Episode Transcription

Richard Lawrence

Welcome to the Humanizing Work Show. Today we’re talking about a better way to break down work, moving away from phases and easy quick wins, towards an incremental, thin slice, value-focused approach. And this is much bigger than doing better Sprint Planning, backlog refinement or even agile development at all. It’s a fundamental shift in how we think of progress on work in all areas of our life.

Peter Green

When I was a program manager at a big software company, I had to provide regular status reports and updates to lots of stakeholders, and I always felt like it was a bit of a song and dance routine. We needed to submit these reports that gave enough information to the stakeholders to kind of get them to leave us alone, while not being overtly misleading, just in case anything actually did go wrong, and we really ended up needing their help.

Now, I am not anti status report. I understand that they do at least two important jobs, one that’s kind of tactical and one that’s more psychological. Tactically, status reports should help people plan and respond to what our team is doing. Psychologically, status reports should help the people with big bets and investment in our work feel confident that the investments are going to pan out.

But the standard traffic signal approach we were using, with a project being either Green, meaning everything’s on track, Yellow, meaning there are some issues to address, but we’ve got to plan for those, or Red, meaning we’re in big trouble; this process seems to be used by the vast majority of companies, and it does do the psychological job of helping stakeholders feel confident– but only through obfuscation. And almost nobody used the status reports to do the tactical job of coordinating dependencies. We developed better, often less structured ways to do that.

So, at the time, I didn’t have the language to describe why this approach felt so broken to me, or really any solid ideas of how to fix it. In today’s episode, we’re going to share the breakthrough idea that solved the status report song and dance problem at a fundamental level. Instead of making fake progress on some phased approach, we started splitting our work so that every few days or weeks, we were making actual progress through small deliverable slices of value and learning.


But before we get into that, this show is a free resource sponsored by the Humanizing Work company.

Humanizing Work exists to make work more fit for humans and humans more capable of doing great work. To that end, we do training and coaching in three areas:

  1. We help leaders lead empowered teams and individuals more effectively
  2. We help product people turn their ideas into good visions, experiments, and backlogs
  3. We help teams collaborate better to produce meaningful outcomes on complex work


If you or your organization would benefit from better leadership, better product management, or better collaboration, and if you find our vision for human-centric work compelling, visit the contact page on and schedule a conversation with us.


Now, there are some projects you can divide up into tasks, and progress through the tasks really does represent progress towards the larger goal.

But if you’re taking on something new—especially something new that depends on the future preferences and behaviors of other humans—your work has some complexity to it, and it’s necessarily going to change as you go. You’ll learn more about the problem and about the solution as you actually try to solve the problem. Thus, the big plans and the big progress reports represent an illusion of certainty about the future.

If we want better info, we need to structure our work so that every small item we complete gets us real value, real learning, real risk-mitigation or, ideally, all three. And the best way to do that is to organize the work around small increments of value.

In software development, this is the idea behind user stories—small changes in the behavior of the system, new capabilities for users, described from the perspective of the person who’ll use them. User stories are often referred to as vertical slices. This comes from the common practice of representing architectural layers horizontally. So, a user story requires work on multiple architectural layers to create the new behavior in the system that the user can actually use, making it a vertical slice across those horizontal slices.

It turns out, organizing work in small, vertical increments of value is the keystone habit in Agile Software Development. Everything else works as it should if you get this part right. Planning and reviewing work in small cycles makes sense. Prioritizing by value rather than by technical dependency becomes possible. Frequent, even continuous, releases become a way to get faster ROI and better feedback.


And this notion of organizing work around small slices of value works in all sorts of contexts. It’s not just for software development or even just for product development more broadly.

We recently sold our house and we needed to pack up everything before the close date. If you’ve ever moved, you know the pain that comes with this process. There were lots of uncertainties about it– like how many boxes are we going to need; how long is it going to take to pack a given room; how many shipping pods do we need to reserve; will having friends and family help us actually be helpful or not. And we could have taken a pretty old school approach to this, using some of the online moving calculators, where you plug in the number of rooms, the square footage, and it spits out data about how many boxes you should buy, how much tape, how many labels, etc. Then we could have created a schedule of packing the rooms, and then invited friends and family all over on specific days to help. But there would have been lots of guesswork involved.

So we decided, instead, to take a small slice approach and pack one room. We picked one that had lots of stuff in it, which is my wife’s sewing and craft room, and packed that all on the very first Saturday. That gave us lots of data about how many boxes we might need for a given room, how much space the packed items took up, etc. Then we had a few more hours left that Saturday, so we packed one more room, an easier one that was a spare bedroom without as much stuff in it. We figured if we got one hard one and one easy one, we’d have a good average.

Based on that, we were able to reserve shipping pods, estimate how many boxes we’d need, and then decide when and where it would be helpful to have people help us.


In our product management training and coaching, we teach structured methods for identifying small increments of value at different levels. But there’s an intuitive approach that you can use that plays on that stoplight status reporting approach Peter talked about earlier in this episode.

In a typical stoplight status report, the status starts out green. We assume that things are going to go according to plan. Ironically, we have this confidence at the one time in a project where we know as little as we’re ever going to know. Objectively, we’re facing all the risks we’re ever going to face on this effort, whether we know it or not. So, what’s the status, at this riskiest point ever? Why, it’s green, of course!

And then, if we run into trouble, the status goes to yellow. And if things get really bad, the status goes red. But we try everything to avoid that because it’s bad for reputations and careers.

So here’s how to use the stoplights to find good slices of value, learning, and risk-mitigation. Ask, “If we had to start out red on our status report for this thing we’re working on, and we had to earn green, what would we have to do to earn green?” And then ask, on that answer, “How could we make that smaller and faster?”

And if the answer to that is still pretty big, use the same kinds of questions the next level down. If we wanted to earn green on that smaller thing, how would we do it?

This approach uses our intuition to go straight towards the core complexity of whatever it is we’re working on. And I love how it approaches complex work with more humility than the typical “make a big plan and assume it’s all green” approach.

Peter’s moving example is actually a great illustration of this. What’s the status on your packing project when you haven’t started yet? It’s sure not green. You have no idea how it’s going to go. So, if you want to earn green, packing a whole room, especially a tricky one, is a great way to start. Of course, you may not actually earn green from doing that. You may discover that the project is way harder than you imagined, and it’s time to pull out the credit card and hire some movers. But that was actually true before—you just didn’t know it yet. So, you’re in better shape now with real data about what’s involved that you can respond to.


Want to learn more about this approach to work? Sign up for our newest online course, called 80/20 Product Backlog Refinement. It’s full of concepts, techniques, and tools for tackling complex work in small slices with ease. Visit to learn more.  Thanks for tuning in.

Last updated