Process vs. Model
There’s an old saying which comes from the world of statistics: “All models are wrong, but some are useful.” This has always resonated with me. While conceptual models are never perfect, I find them to be an especially powerful tool for explaining important concepts. But there is always the risk that someone will take the conceptual model too literally, or project too much into it, and interpret it as a prescriptive process.
This occasionally happens when explaining the concepts of continuous discovery and delivery.
I have long used the conceptual model showing these two activities happening in parallel:
This conceptual model actually goes by many names. In fact, I think it’s an indication of the underlying truth of the model that so many people refer to this model using different terms.
I’ve seen it referred to as “build the right product / build the product right,” “fake it before you make it,” “build things that don’t scale / build things that do scale,” and “move fast / don’t break things.” And many people now refer to the model as “dual track agile” or more generally as “dual track product development.”
Jeff Patton published a good article recently covering the origin of the “dual track” phrase. But even in his article, you can see how Jeff struggles with trying to capture more of the actual processes of discovery and delivery in the conceptual model. It’s easy for me to see how this simple conceptual model could morph into a complicated process flow chart.
Lots of people over the years have encouraged me to augment the simple conceptual model, to highlight things like:
- the baseline product vision and/or user research work that is often done in advance of more tactical discovery work
- the activities to describe the work to be done in delivery
- the differences when the delivery process in scrum vs. kanban
- the feedback loop between learnings in production and discovery
I’ve resisted all of these suggestions not because any of them are wrong, but because hopefully you can see that this is a slippery slope as it moves from a simple conceptual model to an illustration of a much more detailed specific product development process.
More importantly, what I like about the simple model is that it is process agnostic. There are many different discovery processes and techniques, just as there are many different delivery processes and techniques.
The higher order points to me are:
- the activities of discovery and delivery are happening in parallel, ongoing – they are not “phases”
- in discovery the team is tackling head-on the big risks – value, usability, feasibility and viability
- in discovery the product team is working collaboratively to solve problems – product management, product design and engineering
- the product team measures itself against business results and not just shipping features
- it is one product team responsible for both discovery and delivery (obviously product managers and designers spend most of their time on discovery activities while engineers spend most of their time on delivery activities).
I emphasize to product people all the time that there is no single product discovery process just as there is no single product development/delivery process. There are many different discovery processes, all for different situations. For example, a discovery sprint looks very different from customer discovery, but you should be skilled at both.
Moreover, it’s important to realize that it’s not about process. It’s much more about putting in place the necessary culture, and training your team on the critical techniques.
In his recent (must read) shareholder update, Jeff Bezos spoke to some of these same issues: “Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.”
As long as you’re tackling the risks up front; truly collaborating with engineering and design on coming up with good solutions; and making sure you are solving the underlying business and customer problem, and not just shipping features, then you’re focused on what you need to be doing.
