2019年/04月/01日
Value Is What We Want
We all want value. Value is what we want. Value is—what we want. In software, we generally get value by delivering features. Features that have value. Features that we want.
Often it’s about money, because software can save time or money. Software can help us earn money. There are other kinds of value: software can make lives more convenient. Software can even save lives.
In the end, I think of value as simply what we want. We might like to put a number on value, but it’s not necessary. As we build the software, we’ll make choices. Each choice gives us something we value. We’ll choose information, happy users, or saved lives. We’ll choose what makes sense. We’ll choose what we want.
Working incrementally, we’ll choose the next thing we want. We’ll have our team put it into the software, as quickly and solidly as they can. When they’re done, we’ll look to be sure we got what we want: we’ll check for the value.
We’ll say, “show us the software,” to see the value.
What kinds of value does your project deliver to its users? To your organization? To the team? What value does it deliver to you?
Value starts when we ship the software.
A project delivers value only when we ship the software and put it to use. If we wait until we finish everything, it will be a long time before we get any value. Let’s find a way to deliver value early.
We’d rather have the pony now, not later, but we can’t create everything right now. We have many features in mind, and they’ll take time to build. The more we want, the longer it takes.
What benefits could there be if we could deliver sooner? How might the organization benefit? What about the team? What about you and me?
What if we shipped some valuable part sooner than the rest?
Every product is made up of pieces. Call them features, or minimum marketable features. Call them aspects, functions, or capabilities. Each big piece has smaller pieces. Each is full of details that make that piece more complete, more useful, or just nicer.
Remember, most users of a product don’t use every feature. There’s some kind of 80/20 rule going on. Everyone may want something different, but no one wants everything. Even in the products you know best and use most, you probably use only a fraction of the features.
Does shipping something small make sense?
Since most users don’t use all the features, a smaller set of features can provide real value, and provide it sooner. Sometimes we think we have to have it all. Let’s face it, though: if you’ve done very many software projects, you probably didn’t get everything you wanted by the date you wanted it. We never get it all.
We can stamp our feet and demand a pony, or we can act like managers and steer our software projects to the best possible result. Very likely, there’s a subset of capability that can start providing value sooner than the whole package. Let’s find those features and ship them first. That way, we’ll prosper.
After that first release, we may need to follow up with the rest of the product; otherwise, the final product may be worth less over its lifetime. So we’ll usually plan multiple releases.
But there are times when we might just ship the first bit and then stop. When could that be the best thing to do? How many different reasons can you think of?
Deliver just one part and then stop?
If we ship just once, we’ll get an earlier return, but it will probably be less than if we shipped the whole product, even later on. Or will it?
Information has value as well. Sometimes the most important information we can get is that we’re doing the wrong thing. One very good way to find out if we’re going in the right direction is to ship a small version of the product early. If it flops, we can change direction at low cost.
Usually, though, we do have a good idea. With a good idea, what kind of pieces should we work on? How would our product best be delivered a bit at a time? What should the pieces look like?
We must see and understand the pieces.
It’s not enough for our teams to work on mysterious technical bits that make sense only to them.
We need to guide our teams to build pieces that make sense to us, and to our users. These are often called minimal mar- ketable features (MMFs). In fact, we’ll often benefit from pro- viding business direction at an even finer grain than the usual MMF.
Here, we’ll call those pieces features. When we say “show us the software,” we want to see features that we want and understand.
Looking back at some previous projects, what are some features you wish you could have shipped sooner, and why? What are some features that should have been different? Are there some that shouldn’t have been done at all?
Value, by feature
Each feature that we might build adds some value to the product. And each one takes some amount of time. We can’t know exactly how valuable or exactly how much time. But we can still get an excellent sense of what to do.
Suppose the height of the features is their value, and the width is their cost. Which ones should we build first, and which ones should we defer until later? Pretty clear, isn’t it?
Value growth depends on what we choose to do.
Look at the difference in the growth of value if we choose the higher-value, inexpensive features first and defer lower- value, costly features until later. And these features only vary by about a factor of three to one. In most products the best ideas are tens of times better than the worst—or more. The results would hardly fit on the page!
Some of those later features look pretty boring. What would happen if we did different, more valuable features, even for some other product?
We might even switch our investment to a new product!
When we begin to ship frequently, with highest value first, the time soon comes when the next features aren’t worth the time and money to create them. This is a good thing. We can often do far better by investing in a new product.
What’s the next product we’d like to do? Who might feel negatively impacted by a product shift? How might we make that shift a good thing for everyone? Can we focus on a portfolio rather than separate products with diminishing returns? Can we show more software, with more value?
Best value comes from small, value-focused features, delivered frequently.
OK, we can see that small features could deliver value sooner if we can do them. Let’s think next about managing our project. Will smaller visible results help us manage? How might they get in the way?
What about our teams? Are they organized to work this way? Do they have the people they need, the skills they need, and the help they need? Read on—we’ll talk about all those things.
The main thing to remember is that we get the best results from delivering the software, feature by feature.