Discovery & Delivery

What I’ve strived for in all my jobs and assignments is to combine the best discovery methods with the best delivery methods, of course in the best possible way. I have tried and tested a lot of popular frameworks and ways of working, and the following list of principles is my conclusion.

• Agile Product Delivery frameworks such as Kanban and Scrum does not work well without a Discovery process. You can build a product in the right way, but if it is not the right product (and it rarely is, we as humans have too many biases), that is just colossal waste.
• The Discovery process has to be given some time before the Delivery process starts. If you haven’t understood the problem, starting out on building a solution too soon will make it very hard to steer away from that path when you’ve realised it is the wrong one. It is not necessary with a lot of time (such as in traditional Waterfall models), the amount of time varies with the product, but significantly more time is needed than only one Design Sprint.
• The Discovery process has to be continuous. If you only do Discovery in the beginning, you might build a slightly better product than if you are not doing it at all, but important product decisions are spread out throughout the lifecycle of the product.
• Understanding what you actually do not know and having a way of finding that out is needed to mitigate product risk. This is a task done on-demand, not continuously as the other tasks mentioned in this list.
• Discovery and Delivery combined and interlaced is needed to continuously steer towards the right product. This requires frequent real collaboration. Better yet, Discovery and Delivery are done by the exact same people and that team is balanced (i.e. incorporates the necessary competencies/roles and using a weighted decision process) when it comes to focusing on user value vs. business value vs. technical/practical feasibility.
• Discovery and Delivery need to be both iterative and incremental. Discovery is by tradition iterative and Delivery is normally mainly incremental. If you are making good use of (short) feedback loops and only doing what is necessary right now in both processes, we can start calling it Agile Discovery and Delivery.
• Getting the ideas into delivery quickly is required to get actual live feedback on your product and that is the only way to know for sure that your product is a success. Don’t wait too long with delivery. But remember, if you just build something without thinking, it will be the wrong thing and you will need to throw it all away and start over from scratch. Do you have the courage and means to work like that? If not, do enough Discovery first and during Delivery.

And in the words of Jeff Gothelf (from the book Lean vs. Agile vs. Design thinking):

• Product discovery work must become a first-class citizen of the backlog.
• It must be visualized along with the delivery tasks.
• It must be prioritized against them and assigned to specific members of the team.
• It must be tracked like delivery tasks.
• The implications of discovery work have to be taken seriously. Changing your plans in reaction to these learnings is agility.

I have created a simple model to help you see the different areas necessary to master based on the principles above.

Read more about how this can work in my Product Discovery book.