The consultants of Crisp often produce awesome articles, products and ideas to improve software development. The most famous one probably is the video ‘Product Ownership in a Nutshell’ by Henrik Kniberg. Based on this video I recently stumbled upon a visualisation that describes the related product discovery and delivery process.
I really like the way they visualised the product- and delivery process. I will definitely use the poster to clarify the process to everyone involved in product development and especially the stakeholders.
In this blog post I’ll just share some of my thoughts I had when reading this article. Not a unique post, just some of my findings. See below for the picture in low resolution, the version with high resolution can be downloaded via the original article.
My thoughts & observations:
- The process begins and ends with the stakeholder. This is quite logical, but the importance of involving the stakeholder can’t be empathized enough. The eventual product success depends on it.
- The term ‘Product Discovery’ is a powerful way of describing the phase of brainstorming around new ideas. Some ideas may have already been thought through in detail, but when discussing it with members of the development team you will always discover new features, requirements and insights.
- Doing the product discovery with members of the actual development team is very important because it minimizes the amount of handovers and encourages collaboration and ownership. This way the idea of ‘from concept to cash’ becomes reality.
- Within the Scrum framework the Product Backlog is a given fact. The Scrum Guide doesn’t describe the process that occurs to actually create the backlog. Because of this, the description of the product discovery and delivery process is a valuable addition.
- Scrum uses backlog refinement as an activity to improve and clarify the Product Backlog. The term ‘backlog workshops’ probably have the same purpose but emphasize the fact that it’s not another ‘meeting’ but really an activity.
- You will only know what the impact of the build features are when the stakeholders are actually using it. Therefore releasing early and often is crucial.
- “Let go of the roadmap and fixed feature releases. Let it just be prioritised assumptions – assumptions that can be verified by the team just in time and delivered so much sooner!” Can’t agree more!
So far some of my thoughts and observations, I can only recommend reading the full article and hope you find it useful as well!