The easiest way to address the risk of people not knowing what they want until they see it is to deliver usable increments of working software to them as soon as possible. A crucial aspect of this early-and-often approach is that we will get meaningful feedback that we can incorporate back into the ongoing build and delivery. 

Using this approach to software delivery means that everyone, including our customer, has to understand the caveats. They won't be seeing or using software that is either necessarily complete or has the final polish applied. In fact, they will see software as it evolves in both function and form. User experience, which includes user interactions, process flow, and graphic design, will also be iteratively applied as we learn more.

How we break down the requirements into small manageable chunks is the first step to achieving this. It's vital that we first deliver the parts of our product that we most want feedback about. These are often our core business processes, the things that directly or indirectly make us money, and therefore involve the most risk.

To achieve this approach, we should stop thinking of building up functionality in layers, as shown in the following diagram:

This method may seem sensible because by starting at the backend and developing the data store with its associated business logic, we are creating a foundation to build upon. However, it's somewhat of a construction industry analogy that doesn't apply to how we make software.

Instead, to deliver incrementally, we have to think of each increment as end-to-end functionality that provides some business value to our customer. We often refer to this as vertical slices of software, because every small slice carves through each application layer, delivering aspects of each. The concept of vertical slicing is shown in the following diagram:

We include the User Interface layer so that we provide our client with some way of interacting with our software so that they can make real use of it. If we think of each vertical slice as a feature, we can carve up our features in a way that will make sense as we build out the product incrementally.

For instance, if we are building an online shop, the first vertical slice could be the display of items we have for sale. As well as showing items for sale, we'll probably need some way of managing their details. Again, we can build something rudimentary to start with and then incrementally deliver enhancements as required.

The next vertical slice could be either the checkout process or the search facility. Any of these features can be completed independently of each other, but it probably makes sense to build them in a particular order. For instance, without items for sale the search facility won't work, nor will the checkout process. 

If we build up our feature set in a way that makes sense, we get valuable feedback from our customer that we're building the right thing. And as we deliver further increments of working software, they can use these to determine if the software we're developing will meet their needs. 

We also get to validate our technical approach by asserting whether or not we're building the thing right. Once we have an end-to-end delivery taking place, we can start to iron out problems in our integration and deployment processes. We will also get to learn sooner how we will configure and manage our production environment.

When building any product, we take the Goldilocks approach—not developing too much, or too little, but getting it just right. This, in particular, should influence our decisions in terms of architecture and DevOps; we do just enough to get our current feature or feature slice working. Architecture and infrastructure have to be built incrementally too. 

We'll talk more about how to prioritize features later in this chapter, in the Build, Measure, Learn - Adopting Lean Startup and learning to validate ideas section.