I think of the product we ship to the customer as “Product 1” — this is all about realizing our hypotheses of what we think the customer wants. But it isn’t practical action until we have actually delivered it and received feedback from the customer. We find Product 1 in the Capability quadrant. Everything we build should be a capability we hypothesise will be valuable to the customer and our organisation. Meanwhile, the internal capabilities we wish to develop — which I call “Product 2” — are our view of what we need to improve while we build. . These capabilities are, therefore, not theoretical in the same way as “Product 1.” We can see their effectiveness, and our effectiveness at building them, the very minute we decide to start improving them. “Product 2” takes hold — is at hand — immediately. But how often though do we release software features that were ‘urgent’ but whose effectiveness is never actually measured in the end? Every feature should be measured. What could we do with the results of our measures? These inform the next cycle (or sprint) where we either build on our success at accurately providing for the customer or decide whether to remediate our mis-calculation. Worked Example A great example of this that will be familiar to software practitioners in banks everywhere will be the ‘budgeting application’ which many banks have built into their online offerings. The hypothesis was that customers needed help budgeting. This is almost certainly true but the means in which this was tested was in most cases by providing a budgeting solution and then measuring its use. This, incidentally, is very low across the board. Measuring the ‘use’ of software is not the same as measuring value. If we do not have an hypothesis about the results this new feature will produce for our company, why are we investing resources in it in the first place? The IOTA model helps us join all of the pieces together. The example below provides an example of what a quick 2 week sprint might look like