Successful Agile Product Discovery and 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.

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

The simplest way of getting on the bandwagon of successful Agile Product Discovery and Delivery is to take one of our courses at Crisp.

A lot of these principles will be discussed and practiced in the Product Discovery course, which we recommend for everyone who works with product development to get the most out of their current Delivery process. This article talks more about the balanced team approach in Product Discovery.

To cover any holes when it comes to focusing on the user value, which is a real competitive issue these days, we recommend the user experience-focused Lean Design Thinking course. Lean Design thinking is one specific framework for continuous Product Discovery that gives deep knowledge in user-centered methods. Here is an article series showing common misconceptions about UX and Design Thinking.

Best practices for collaboration where all the necessary Discovery roles are working in or together with a Delivery team (and to shrink the space between the areas) are detailed out in the Agile UX course. This article teaches one such practice called Design Studio.

And finally, if you are already proficient in Discovery and the continuous joint work with Delivery, the Lean UX course is recommended for mitigating the risk of not knowing enough about key features, target groups or markets before and during Delivery. This article explains a bit more about the Lean UX process.

Thanks for reading all the way here.

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

This site uses Akismet to reduce spam. Learn how your comment data is processed.