It dawned on me recently that there is a radical transformation in our conversation about digital product development as a result of the (admittedly slow) but inevitable shift towards managing to outcomes. For decades the “fixed” component of our product conversations was the product itself. Sure, we may have shifted on deadlines, scope and or design choices but the question of “will we ship it?” was never in doubt. The product was definitely going to happen.
Product deployment is no longer certain
With the shift to continuous deployment, testing and integration systems (aka DevOps) the systems we build have taken on two important new qualities:
- They never end — We work on our products, today, “forever.” There’s no fixed end date for the features we are building. Sound strange? Ask yourself, “When is Netflix done?” Replace “Netflix” with any other modern company and it becomes clear that our products and services live forever. There’s no explicit end date. At some point, we decide they no longer deliver value or the investment necessary to extract more value from them isn’t worth it and we move on to something else. Until that point, we have to maintain and optimise these systems continuously.
- They provide a continuous feedback and learning opportunity — because these systems are always in flight, delivering value (or not), and providing a service to customers, we continuously learn how well they’re performing. We now have an incredible opportunity to determine where to best focus our efforts to continuously improve these systems for our customers.
These qualities force us to consider a different measure of value than in the past. We no longer need to focus on whether or not we’ve delivered a specific feature. Instead, we focus on what our customers are doing in the system. Are they successful? Are they using it in a way that benefits them? Are they doing what we expected? Something else? Our fixation is no longer on whether or not a specific capability has been deployed but rather, “is the system delivering value?” A determination to “just get features out there” no longer makes sense in this new context.
The product is the variable
The modern nature of software focuses on deploying the least amount of code that delivers the highest amount of value. Why? Because we have to live with that code forever. Our new measure of success is customer behavior — or outcomes. The behaviours and changes in those behaviours that we want to see in our customers are our new, fixed, measures of success. The way we achieve those behavior changes become the variable. The product is the variable.
There is an infinite combination of code, copy, design, value proposition and business model that may deliver our desired behavior changes. We mix, match and experiment with various ways to make our offering more valuable to our customers. The goal is fixed as a change in the behavior of our customers. We keep adjusting and (hopefully) improving the product until we reach our desired level of behavior change.
This requires a new mindset to product development
Accepting this change to the way we run our teams and organisations is not going to be easy. It’s a significant mindset shift. It’s easy to think of the product as the goal. We can clearly write down what we believe it should do, design it to do that and deploy it. Sadly, this doesn’t guarantee our success. It only guarantees the deployment of code (and subsequent technical debt). Product variability may scare stakeholders. “What are we building?”, they’ll ask. Ultimately we need to change that question to, “How are we trending towards our desired behavior changes?” This will take time but it’s inevitable. Our modern tech stacks demand it.