Discovery differs from delivery

Discovery and delivery are not just different phases in the product design process, they also differ from each other in significant ways in terms of what they can do.

This Twitter thread describes Karl Popper’s ‘Clouds and Clocks’ theory. Basically, there are two types of problems:

• Clock problems: the end state is definable, as the steps get there. In sense these are complicated problems - might be difficult to do, but we can get to the end of it with deliberate practices.
• Cloud problems: the end state is unclear, as when the problem is solved. It’s messy, rather than solving such problems, it’s more likely we are influencing them. These are complex problems. People problems and design questions are mostly cloud problems.

Design is great at working with cloud problems, and engineering is great to work with clock problems. Real-world issues and our solutions to them often contain both types of problems.

Having a product design process with discovery and delivery mirrors this duality of problems. First, we do discovery to tackle cloud problems and once we have a workable solution proposal that can be broken down into clock problems, we can execute in delivery.

Not every problem we have needs discovery (clock problems can be delivered without much discovery) and often discovery results in ideas or learning that cannot be easily translated to delivery and might be reused in future discovery rounds.

Also, cloud problems will never get solved in a single discovery-delivery iteration. Often they would need multiple iterations to have an effect without a clear solution.