The Information Product Canvas and the Information Product Brief are templates we use to document and share the definition of an Information Product.
They are designed to provide a common and shared language which enables the Information Product boundaries to be shared, understood and agreed with:
- stakeholders / customers
- delivery team members
- consumers of the information
When we first started iterating on the Information Product pattern we used a word document to define the boundaries. But as they say a picture is worth a thousand words so over time we iterated the process and adapted the Business Canvas pattern to create the Information Product Canvas.
Here is an example of the Information Product Canvas template.
Here is an example of a completed Information Product Canvas.
You can download the Information Product Canvas Template in a variety of formats here.
The purpose of the Information Product Canvas is to give an Information Product a unique name and provide a way to understand and agree what is included and excluded. We need to understand who is the owner of the Information Product and is empowered to make trade-off decisions as it is developed. We need to understand the action that will be undertaken with the information and the outcome that will be achieved from that action. We need to understand the audience that the Information Product aims to serve, the business questions they expect to have answered with the information, the way they prefer the information to be delivered and when they expect the information to be current. We need to understand the core business events which produce the data we need to deliver the information. We need to understand the assumptions and trade-offs we are willing to make to deliver the information, what features will be delivered and what other things will and won’t be included. Lastly we need to include an elevator pitch which provides an understanding of the Information Products boundaries at a glance.
The Information Product Canvas and Brief templates are ways of lightly documenting:
- The Information Product name;
- The business outcome or benefit that will be achieved by using the Information Product;
- The action that will be taken as a result of the Information Product;
- The business questions that will be answered by using the information;
- The data-driven business processes that create the data required to deliver the Information Product;
- The audience (persona’s) that will use it;
- The visualisations or other ways it might be delivered;
- The features the users will require when accessing the Information Product;
- What will not be delivered in this Information Product.
Each of these are defined by leveraging other AgileData patterns such as Event Modeling, StoryBoards and Wireframing.