Making Better Choices — Modeling over Muddling


When faced with an important and complex decision, effective decision makers use models. Why? Models cut through complexity by identifying key drivers that influence outcomes. Good models provide insights that lead to better decisions, and better decisions lead to better outcomes.

What are models?

To begin, models are not reality. This part is important. Models are never right. We use models because reality is too complex. Models are simpler versions of reality. A modeled version of reality is not reality itself, so it can not be "right." The best we can hope for is that the model be useful in making better decisions.

Model both upside and downside

To be useful in evaluating a choice, a model must give insight into value upside and risk downside. Sometimes people call a model the "value proposition." Calling something a value proposition is inherently optimistic. Not to be overly pessimistic, but to be helpful, the model must also address risk.

Model to reflect changing reality

A model is typically a snapshot of reality, a moment frozen in time. A snapshot of reality can quickly grow stale. The expressions that "change happens" or that "change is the only constant" remind us that a model must be updated if it is to stay relevant.

Model for conversation

The fact that models are not reality can also make them changing them less contentious. If someone challenges that they don't believe your model, you can respond that you don't believe the model either since it is not "real." This openness creates an opportunity to improve the model. I always like to follow up an agreement that the model is not real with an earnest request of the challenger for help with the model. Perhaps the challenger has better data or insights on other drivers. Often we get a better model as a result of this exchange. And a better model produces better decisions.

Model to maximize value

"The Scrum Guide" tells us “the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” Clearly the value of the product is influenced by the Product Owner's decisions. What is the value of a better decision? Consider the decisions on the order of items in the Product Backlog.  Modeling the value of each discrete item in the Product Backlog provides a transparent basis for ranking. Plus, models provide a means for the Product Owner to explain the order of the items based on current understanding of their modeled values. The conversations around the value models and the resulting improved decisioning helps ensure that the Scrum Team is always working on the most valuable work.


The Cone of Uncertainty

I first encountered the phrase “cone of uncertainty” in the mid 1980’s while reading Barry Boehm’s book, Software Engineering Economics  (1981). Using a traditional software project context, the “cone of uncertainty” model showed that the amount of uncertainty in a software project is greatest at the beginning, ultimately converging to zero (0) at project end. In his book, Boehm reveals the magnitude of the uncertainty through research showing that estimates provided at project start are generally off by a factor of four (4). That’s right, a factor of four… and you thought your estimates were bad!


This “cone of uncertainty” made sense in a traditional project context. That is, if you’re assuming that the scope of what is needed can be determined and fixed upfront. But, we have learned that software isn’t actually like that. Let me explain.

How many times have you built exactly what the customer asked for only to hear on delivery that despite the product being what was asked for, it doesn’t meet the customer’s need? The cone of uncertainty described above is premised on the customer being right in their initial ask. Once you deliver what they asked for, you’re done. But what if they’re not right? Pause for a moment and think… in the case of a new product, has the customer ever known exactly what was needed before it was built? Is it even reasonable to expect them to know?

What I’m suggesting is that it is not estimation and our inability to accurately estimate that is the issue. In fact, our focus on estimates and estimation have distracted us from what is more important — that is, building the right thing.

The Cone of Possibilities

If we’ve never built this exact product before, we have no hard data proving that it is the right fit for the customer need. Before something is built, the idea of the thing to be built is simply a value hypothesis. We won’t know if it’s right until the product is built and in use by the customer. The sooner we build something and start generating feedback, the sooner we will have data on whether or not what we are building is right, and, if it’s not, how to change it so that it is more likely to be right.

Building software is analogous to building a new product. Building a new product is a journey from the known to the unknown. Instead of a cone starting wide and narrowing towards a point, building a new product is more like a cone starting at a point and widening out to a myriad of possibilities. A more appropriate model to describe the product evolution is a hurricane forecast cone. In the picture below, “X” marks the spot where the hurricane is now. That spot, plus where the hurricane has been in the past is what is known. Where it is going is uncertain. We can model a likely path based on current information, but our ability to accurately predict beyond the immediate future is limited. And the farther we try to predict the more uncertainty we encounter. Beyond a certain point, it’s not even worth predicting.

For a new product, we always have a current state of the product — what it is currently — even if that state is that it doesn’t yet exist! That current state is what is known. We won’t know what the next iteration of the product will be until it is actually built. Any number of unexpected things might happen in the interim.  For example, the customer changes their mind, the infrastructure on which a new feature depends turns out not to support the feature, a key team member departs, a new law or regulation limits or blocks the deployment of the feature, and so on.

Hurricane forecast models are updated frequently based on new data to improve our ability to react and prepare for the effects of the hurricane. The potential value in saving lives and property and minimizing damage to infrastructure warrants the investment in keeping the model current and useful.

Optimizing for Maximizing Customer Value

A product backlog represents a product’s potential future state. Like a hurricane forecast model, the product backlog represents possibilities. The actual track of the product is known only after the fact. The product owner’s decisions in product backlog content and order influence future product direction. With maximizing customer value as the primary optimization goal, the things that might influence the product owner’s decisions in reordering the product backlog and changing its content can be as complex as the factors influencing a hurricane’s direction. 

Just like the hurricane forecast model,  the product forecast model, the product backlog, must be updated frequently. Interestingly, the myriad possibilities of the future backlog also means that there is no upper bound to customer value creation. The main part of the product owner’s job is to manage the backlog for this purpose. Unlike in a project, the goal is not to be done, but rather to maximize value to the customer. If we are to focus on building the right thing, the more appropriate model then is an open-ended cone, rather than a closed one.

Have you considered your future product potential, what influences its direction, how to effectively forecast, model, and communicate its possibilities?

Did you know?
In 1973, Barry Boehm shocked the computer industry by predicting that software would outrun hardware costs.

Value Hunting with the Product Owner

Value Hunting with the Product Owner

I coach my Product Owners to ruthlessly refine their Product Backlog to prevent onset of an Agile death march. A lack of proper attention to Product Backlog Refinement can lead to product decay, premature end of product life, and demotivation of the Development Team. 

In light of these risks, it's important to get Product Backlog Refinement right...

Read More