The Information Product Canvas is made up of 12 distinct areas.
Each area holds a set of information that is captured to provide context and that context should drive a future action by the data team.
Each of these areas have been added and iterated over the last decade working with multiple teams across multiple organisations.
You can complete the areas of the canvas in any order that works best for you.
I have a typical order I use when Pattern Storming the canvas with stakeholders, one that I have experimented with, iterated on, and refined over the last decade.
I start with Business Questions first, as I find this is the easiest area to elicit initial answers from stakeholders. Next, I move to Actions and Outcomes, asking “if I provide you the information to answer those questions, what action would you take, and what outcome would that action deliver”
If the stakeholder cannot describe the Actions and Outcomes, I may stop capturing requirements. Without a clear statement of value, the Information Product is unlikely to be prioritised for delivery, making further effort in capturing requirements wasted effort.
The second-to-last area I complete is the Vision area, as I need content from the other areas to complete the Vision Statement.
I typically add the T-Shirt Sizing after the workshop, collaborating with the data team to create a guesstimate. This also provides an opportunity to socialise the canvas with the team.
I have worked with people who fill out the Information Product Canvas in two iterations.
First they fill out the Action/Outcome, Persona, Information Product Name and Vision Statement areas.
This version of the Canvas then gets put into the backlog for prioritisation.
Once it is prioritised to be worked on they then patternstorm with the Stakeholders to complete the rest of the Canvas areas.
Fill out the Canvas in any order that works for you.
Iterate the process it as often as you want/need to.
After all the Information Product Canvas is a pattern template that can help your data teams way of working.
It is NOT a “Framework”, it is NOT a “Methodology” it is NOT a dogmatic doctrine.
So use it the way it suits you and your data team best.