To create a shift from project to product thinking, first we have to think about why we would want to do this. 

As discussed in the early chapters, there has been a tendency in the software industry for us to use predictive forms of planning, mainly because we feel like this would give us the best chance of controlling a successful outcome. Up front requirements for gathering and design are needed to ascertain a budget, resources, and a completion date. This helps determine levels of comfort with the project before requesting a budget and moving forward with the implementation of the idea.

However, predictive planning requires Big Design Up Front (BDUF) which, even if using an iterative Agile method such as Scrum, will result in Water-Scrum-Fall. We carry out the initial ideation, requirement gathering, analysis, and design up front. We then implement the plan iteratively, before going through an extensive integration and deployment phase.

Water-Scrum-Fall solves some but not all of the problems Agile was intended to address. In fact, it reduces our agility significantly because we fix scope at the beginning of the work during the planning phase. When changes arise, there is little flexibility and a certain degree of reluctance to modify the plan. I've seen this happen many times, particularly in large projects where there seems to be a reluctance to change course, even when the obvious is staring us in the face. 

If we shift from predictive to adaptive planning, we'll be able to avoid the feeling that we have to keep spending and we'll be able to chase value. To understand why we need first to understand the nature of the problem with which we're dealing. In the next section, we'll look at a framework that helps us make more sense of the situation.