Envisioning done right
When you start a new product development you have to do something before the first Sprint: shaping a product vision, creating an initial product backlog, forming the team etc. There are a lot of names for these activities: envisioning, ideation, customer discovery, pre game etc. Envisioning seems to be the most common name.
While I think that Envisioning is often necessary I am often shocked when I see what companies do during “Envisioning”:
- The Envisioning lasts weeks or months when hours or days would have been sufficient.
- Comprehensive fine grained product backlogs are created.
- Detailed designs are created.
That is not Envisioning. That are the early phases of a waterfall project. Therefore some people consider the Envisioning an anti pattern in Scrum.
Before I join these people I want to try to explain better what Envisioning should be and what not.
During Envisioning I value
- learning important things over designing things
- having business and technical people in the Envisioning team over having only the Product Owner doing the Envisioning
- Product Owner and Team listening to and working together with real customers and users over giving research orders to marketing
- checking assumptions about the market, customers, users over dealing with corporate stage gate processes
- checking technical assumptions with prototypes over having long design discussions within the team
- sketching things on flip charts over creating power point slides