Value and Learning - How to Prioritize

I teach a class called "Agile Fundamentals" where I work. Among other things, we spend some time looking at different mindsets, types of work, and approaches to delivering value. We go into some detail looking at when value is achieved in strict plan-driven vs value-driven approaches. There's a slide in there that always bothers me a little because of how optimistic it is. It's for training purposes so keeping it simple makes sense, but it still bugs me just a bit. For illustration, I'll sketch the slide out a bit.

OK, so on the left you have the classical project management style. People often build buildings this way (or anything requiring mostly 'task' work). Plan everything out first, then assemble your materials and put everything together following the plan. The 'product' does not begin producing value until every step is done. The building is complete, people move in and start using it.

On the right you have the iterative, incremental approach. This is typically a much better way to build software (or anything requiring a lot of 'knowledge' work). The idea is you focus on delivering a small but complete piece of value, focusing on the highest value bits first. This allows value to be delivered well before the deadline, even if it isn't all of the value. When developing products with a lot of features, this can be a huge benefit to your audience.

Conceptually, this is all well and good, and I am a huge proponent of the model on the right. I believe that we tend to know less than we think we do and we tend to require creativity more often than we think we will. Ever had someone tell you, "We know what we need to do, we just need to go do it." only to later hit a change in customer need or environment or even what the purpose of doing the work is? Now we have to redo a lot of something that was all planned out under the assumption that we 'knew' exactly what we needed to do. I can hardly think of a product I've worked on where that has not happened. So for most work involving any uncertainty or human creativity and expertise, the model on the right tends to operate better.

The Problem

But I said earlier I also have a problem with these slides, even though I agree with the concept they are teaching. My problem: the slide misses the need for learning. The slide about the value-driven approach makes an assumption that is at best questionable, at worst completely contradictory to the value-driven approach itself. It makes the assumption that at the beginning of the project we already know what the most valuable work is and will be able to do it immediately.

This poor assumption is one of the most common mistakes organizations make, even for teams operating within 'agile' frameworks. We like the iterative thing, but we hate the uncertainty of not knowing exactly what value our product is going to add. We want to know up front, so that we can do the most valuable work first. What this can create is a weird overdone planning round where you try to figure out exactly what is going to provide how much value before you've begun the work or anyone has interacted with it. Or maybe it creates a really strong confirmation bias that what we believe to be the most valuable work IS the most valuable work and we become closed to discovery.

"Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal." - Nietzsche

We get stuck on our path, and we stop worrying about the goal because we 'know' the path will get us there. But the path is twisting, and before you know it we're not even moving towards the goal.

This idea undermines much of what makes agility agility, what makes iterative development more effective than 'grand reveal' project planning. It isn't just about working iteratively and incrementally. You must recognize that at a very basic level when you start you don't actually know what you want. Agile, as we say in the course, is a way of working grounded in a culture of learning (yes, the course does later address learning, it's just not on that slide!). If you have not made learning safe, normal and encouraged, you will start regressing back into doing many of the 'agile' practices without actually getting the benefits of being agile in your values and principles.

In any empirical process attempting to manage knowledge work, you need to acknowledge all that you don't know when you begin. You have an idea, sure. You have a vision and a customer/audience need you are trying to meet, and presumably some goal behind that about making the world a better place or making money or whatever it is. But you don't know what meeting that need looks like yet. So the thing you think (before you begin) is going to meet that need may or may not do it. Your audience is always changing, the technology is always changing, and the circumstances are always changing. Even if you recently built a similar system that you think you just need to recreate, odds are a slightly different context means that you are going to hit some important discoveries between starting work and reaching the value.

The Importance of Learning

To come back to the slide, I don't believe in the idea that we understand the value up front, therefore we can't do the most valuable work first. But if I don't know what is valuable up front, how do I prioritize? I'm super glad you asked. You could randomly start doing work (or doing them in some arbitrary order like alphabetically or by ticket number). You'll eventually get through the backlog you started with. You could make your best guess at what would add the most value based on what you believe to be true before you start. I'd personally take the latter over the former, but I think there is a third option that does better than both. You should prioritize based on what teaches you the most about what is actually valuable to reaching your goal.

I'll give a generic examples. Let's say that some complex backend calculation system is believed to be the most valuable piece of a product you are building. But rather than prioritizing that work and some basic command line method to interact with it, you realize that the biggest unknowns lay in how your eventual customer is going to interact with your product, or in how two distinct tech stacks need to talk to each other. Rather than doing the work that is considered most valuable, I might recommend that you instead prioritize learning what you don't know early on. Otherwise you might do a bunch of work on a fairly well known space, only to later discover that it doesn't connect to either your customer or some other technology in the way you'd expect and you have to redo part or all of it.

Quick tip: One of the best ways to prioritize learning is to get something functional in front of real customers of the product and then to watch how they behave (not what they say).

OK, so to come back to our time/value graph, here's a stab at what I think an idealized learning line probably looks like. Early on, you prioritize a lot of learning because it will enable better value prioritization later. But you do eventually start running out of relevant and important things to learn. While you never stop learning, you do start shifting your focus to to be less about learning, and more about delivering the value you've learned about. So how you prioritize may actually shift from the start of your project to the end, and that is totally ok.

Here's a quick look at what will happen when people take the approach of using whatever they thought was most valuable when they started and ignore learning.

Now here's something important to note. All other things being equal, effort remains constant. Doing work does not equal generating value. This is another common and intuitive mistake from a task-based work frame. There is this basic idea that if I apply one unit of effort I get one unit of value out of it. Because if it takes me an hour to make a spoon, in two hours I can make two spoons, right? But this doesn't even work in factory environments, because value is not created when you make the spoon, it is created either when you sell it or perhaps when someone uses it depending on what your goal is as an organization (by the way, this does mean that value is subjective, but I suppose we knew that already).

Prioritizing Learning and Value

So in all of our models, effort remains constant throughout. In order to maximize our value, we must prioritize learning if there is meaningful uncertainty or change occurring within our system. We do this so we can maximize our value delivery. I want to reiterate the point, because this is where we can trip. It can feel really counter-intuitive to pause and go, "What don't we know?" rather than, "Do what we believe is most useful right now!" Especially in a world moving so fast with harsh deadlines and money being tight and pressure coming from everywhere to get stuff done. Focusing on anything but the urgent short-term needs can seem like madness.

If I combine my learning and value graphs, here's what I think you want to see when you are developing a product.

I will assume effort remains constant throughout, your team is working hard and consistently. You focus that effort on learning early, and as that pays off, you start getting a better idea of what value you deliver. Over the course of product development, you focus your effort less and less on learning and more and more on value.

If you are a key part of your team's prioritization processes, and especially for product people/owners/leads/managers, this can function as a guide for what to prioritize and when. Don't ignore learning, don't ignore other members of the team that have unanswered concerns. Avoid focusing on what you know and what you thought up front would be valuable unless you have some incredibly good reason to believe you are right. Experienced and talented professionals get these things wrong constantly in the business world, and you are no exception!

Closing Thoughts

Before I close this, I want to call out what I still don't like about the sketches I've made for this article, and also how you can fall into a ditch in the other direction.

What I still don't like about the slides is the 'deadline'. Ideally, in a value-based system where you are appropriately using learning and value to prioritize and deliver what an audience needs, there isn't as much of a need for a deadline. You are done when you achieve 'enough' value. You probably don't know what the line for 'enough' is early on. How many times have we seen "Musts" become "shoulds" become "won'ts" as we realize what truly matters? Sure, sometimes that is just reaction to a deadline, but it reveals that what we thought we needed at the start (a "must") is not actually critical to achieve the value we want. You may discover well before some date on the calendar that all the most important value has been achieved. We've hit diminishing returns with adding more value, and we're better off moving on to something else new right now. Or you may realize that even though you got done what you wanted there is actually even more value possible and it is worth it to go past that date on the calendar to make things even better. Decisions like these are why we have roles like 'product owner' on teams, ideally to use the craft of product management and strong judgment to stop effort on the product at a good point.

Lastly, the ditch on the other side. If there is a ditch involving not prioritizing learning, there is also a ditch involving prioritizing it too much. When you stop prioritizing purely on value for ANY reason (in this case, I'm advocating prioritizing 'learning' even more than 'value' early on in products with meaningful uncertainty), you run the risk of not coming back to value fast enough. For each product, what 'enough' learning is is unknown. It could be just a couple of days, it could be months. It may actually never stop being a focus because you're operating in a live service environment. The 'too much learning' ditch you fall into is when you focus so much on the learning that you never actually deliver anything useful. You get so busy discovering and unlocking and testing and exploring that you forget to apply those lessons through customer-facing value delivery. The point is not to learn, the point is to create a valuable thing for someone. Learning is a catalyst, a mechanism that moves you in the right direction. It is necessary but not sufficient for most efforts. Keep that in mind, or you'll end up feeling like you're in a science lab, just theorizing and testing and never having an impact.

I think that about wraps it up. When you are developing products, think about what you know and most importantly what you do not know. Recognize that there is probably a lot more in that 'unknown' bucket than you tend to think. Build learning into your prioritization model early on. But don't lose sight of value along the path. If you do this well, you'll be equipped to deliver the valuable products/experiences that your audience is looking for, and that will help you achieve the goals of your organization or yourself. Hope this was helpful!

Benjamin Carcich