The information Product Canvas is divided into 11 areas, each is designed to articulate a subset of the information requirements in a way that we can quickly capture these requirements and we can articulate them using a shared language.
The areas can be grouped into 3 main themes:
- Reasons for the Information Product, what outcomes will be achieved if the Information Product is delivered;
- What needs to be delivered, what are the acceptance criteria for the Information Product;
- What do we need to know to deliver it, what additional details will help the delivery team to understand what is included and excluded in the Information Product and what data tasks do and do not need to be done to deliver it.
The areas can be filled out in any order and do not need to be filled out in one go. We often complete areas such as the Core Business Events after gathering the information in the other areas.
There is a typical flow we use when filling out the canvas so we will use that flow to explain each area. Feel free to experiment with your own flow to find a process that fits your preferred way of working.
Each of the Canvas areas have supporting AgileData patterns you can use to gather the required information. For the purposes of the next section we will focus on a brief overview of each area and link to the AgileData patterns so you can deep dive when required.
<<add links to AgileData patterns to each area>>>
01 – Give it a name and an owner
Information Product Name & Product Owner
In this area we capture the Information Product Name and the Product Owner for the Information Product.
Give the Information Product a name.
This will typically be used to identify the Information Product when talking with stakeholders or the AgileData teams about it.
Try to keep the name short but descriptive, when you have 100 Information Product Canvas in the backlogged well formed names will be very helpful. Some teams have used a numbering system in front, i.e 001, 002 etc, to help with identification.
Identify the Product Owner for the Information product.
This is a single individual who will engage with stakeholders and the AgileData team to make the required trade-off decisions as the Information Product is being developed.
Often we only add the actual Product Owner to the Canvas as we get close to the Information Product being prioritised within the next 3 to 6 month delivery horizon. Any of the Canvas details can be iterated and updated as required, so if a Product Owner is not identified at this stage use the name of the key stakeholder who is asking for the Information Product to be delivered.
02 – What questions will the Information Product answer
Business Questions
In the Business Questions area we gather the business questions the stakeholder hopes the Information Product will answer.
Business questions typically start with “how many”, “how much”, “how long”, “how often”. For example “how many customers do we have”, “how much did we earn last month” or “what was the total revenue last month”, “how long is it between an order being placed and the payment for that order” or “what is the average delay between an order and payment for the order”.
We are looking for the first three to five business questions that come straight to the front of the stakeholders mind. They might have more than five, that is ok let them carry on and add the Business Questions to the Canvas. At some stage the stakeholder will stop to think in more detail, at that stage we stop and move onto another area in the Canvas.
We are gathering these questions at this stage to get a general theme boundary for the Information Product and the Business Questions will help complete some of the adjacent areas. They are not the final set of questions that will be answered, they are not a locked set of requirements that the stakeholder will be unable to change. Let the stakeholder know that we can come back and add or iterate the Business Questions later, throughout the AgileData Way of Working process.
You will find that most stakeholders are able to complete this area very quickly. If they are unable to do that, this is a warning sign that they need to think about their requirements in more detail, or they are acting as a proxy agent for the real stakeholder.
We use these Business questions to help in both the Outcome/Action and Core Business Process areas. We also use them to validate the Persona area.
03 – What value will the Information Product deliver
Outcomes / Actions
In the Outcome/Action area we are looking to gather the business value that the Information Product will deliver. What Outcome will be achieved if this information is delivered?
We use this to help stakeholders prioritise the next most valuable Information Product which should be delivered next or to justify the cost/effort to deliver it.
Some stakeholders struggle to clearly articulate the value of the Information Product they are asking to be delivered. To assist them in this line of thinking we first ask them what Action they will take based on the Business Questions they have just mentioned. We are looking for a response to the question, “if you had this information at your finger tips, what action would you take with it?”
For example if we have a Business Question of “Who are the customers most likely to churn in the next month?”, we might get an Action of “Make a discount offer to customers likely to churn to reduce the number of lost accounts”.
A set of Action can then be used to elicit the Outcomes the stakeholder is expecting to achieve by investing in the Information Product.
For example we might get actions like “Make a discount offer to customers likely to churn to reduce the number of lost accounts” and “Identify potential customers who are less likely to churn and target them with a marketing campaign”. This would be under outcome of “Increasing the Life-Time-Value of our Customers to increase our profitability”
Ideally we would love to be able to quantify the actual dollar value of this outcome to help with the prioritisation and investment decision, but our goal is to elicit good requirements quickly, not boil the ocean. We can deal with the prioritisation challenge using other AgileData patterns.
We might find we have a data consumer not an information consumer as the stakeholder for these requirements. We will know this as the action is typically to use the data to find insights that are provided to somebody else, for example they will be taking the data produced and using another tool to create a dashboard or presentation for another set of consumers. That is ok, we have a choice, we can either create a short form of the Canvas that has the requirements to meet the data consumers needs, for example ignoring the Outcome/Action Area, or we can work with the data consumer to gather these requirements from the final information consumer.
04 – Who will use the Information Product
Persona’s
In the Persona area we are gathering who is going to consume the output of the Information Product, who is the final audience.
We reuse the Persona’s from the AgileData Persona pattern rather than a group of individual’s name. For example Information Consumer, External Consumer, Data Analyst. We may augment this information with the name of roles or the business units the Persona’s are located within if that level of detail has value. For example Finance, Human Resources or Executive Leaders.
The goal is to understand the audience who will consume the Information Product output. We tailor the delivery mechanism and the information output for the identified Persona.
For example if we are delivering an Information Product to a senior leader it will typically provide summary information, perhaps via a mobile app, compared to an operations user who may require detailed transactions, perhaps via a desktop browser.
Cross check the Persona’s identified with the Business Questions and Actions already identified, do they seem to correlate or is there a disconnect. For example, the identified Persona is an Executive Information Consumer, but the Business Questions are “what was the latest order placed and for how much” and the Action is “Contact customer to confirm order”.
The Persona may not be a group of individuals, for example it may also identify a system of capture that the data will be interfaced to, for example a Finance or Customer Relationship Management system.
The Persona area also informs the Type area
05 – How do they want to consume the Information
Type
In the Type area we identify the types of output the Information Product should produce.
It could be a Dashboard, Report, Data feed, Data API, Data Sharing, Visualisation, Analytical model or other output that is specific to your organisation. There could be one or multiple of these output types, for example both a Dashboard to be consumed by Information Consumers and a Dataset to be consumed by Data Analysts.
You could use the AgileData Wireframing pattern to flesh out a quick sketch of the output and attach it to the Information Product Canvas depending on your AgileData Way or Working.
Cross check the Types identified with the Business Questions and Persona’s already identified, do they seem to correlate or is there a disconnect. For example, the identified Persona is an Executive Information Consumer, but the Type is an API.
06 – When do they want the Information refreshed
DataSync
The DataSync area is where we determine how often the information should be refreshed, when new information should turn up in the Information App so it can be consumed.
If you ask the stakeholder when they want the information available they will often think about when they want to access it, not when new data needs to be added. They will say they need access to the Information all the time, they are thinking in terms of when it is available, what is often referred to as a Service Level Agreement (SLA).
At this stage we are more interested in how often we have to sync new data from the System of Capture to the end consumable information. This piece of requirements is important to help the AgileData delivery team to estimate the complexity and amount of effort required to update the information at this frequency. There is a difference in engineering updates once a day, compared to every 2 hours or every 5 minutes.
Cross check it with the persona and delivery type to see if they align. Watchout for the “near real time” requirement. If you are told there is a requirement for near real-time, then ask if they are ok that each time they look at the Information it will have changed from last time they looked at it. What happens if two information consumers look at it 5 minutes apart, will they end up arguing who’s information is correct?
07 – What data is required
Core Business Events
In the Core Business Event area we want to understand what data is required to deliver the Information Product.
We don’t want to deep dive into every field that is needed, we can gather that level of requirements as we get closer to the Information Product being prioritised into a delivery interaction.
But we do want to understand the core of the data we need, which System of Capture it needs to be collected from, have we already collected it, has it already been designed and change rules applied, and therefore it is ready to consume. This helps the team estimate the complexity and effort to deliver the Information Product and also plays a key role in trade-off discussions with the stakeholders. They may agree for the team to deliver a subset of the data early as they will get value from that data, compared to waiting for all the data to arrive.
To help gather the data requirements quickly we use the “who does what” pattern to understand the Core Business Concepts and Core Business Processes that are required and document these. We do not document the detailed data requirements (yet). We find the “Who does What”, Core Business Concepts and Core Business Process patterns provide a shared language between the business subject matter experts and the AgileData team and stops the deep diving into detail we do not need at this stage of the process.
08 – What special features do they need
User Stories
The User Stories is the first of two areas we use to highlight data and product features that are important. The other being the Will/Won’t area.
For the User Stories we use the agile user story format;
For a [persona or audience]
I want [want feature do they want]
So that [why do they want it, what are they going to do with the feature when they get it]
The user story format tends to fit feature requirements whereas the Will/Won’t area tends to suit in and out of scope statements.
If you are using an off the shelf last mile tool, for example a visualisation tool like Looker Studio and you know the features the stakeholders have asked for are available in that tool, then they don’t need to be added here. We are looking for a small number of key features we know we will have to create and which we know are high effort or high risk.
09 – What is in scope and what is out of scope
The Information product Will / Won’t
The Will / Won’t area is the second of the two areas we use to highlight data and product features that are important. The first is the User Stories Area.
The Will / Won’t area has a series of statements that start with Will or Won’t which describe the in and out of scope requirements. They tend to be focussed on data or architecture type requirements.
We don’t want to boil the ocean so we focus on a small number of requirements that are high effort or high risk.
We find it is more important to identify the Won’t rather than the Will’s. Most stakeholders expect that whatever they state as a requirement will automatically be delivered, so when we agree a trade-off decision that something will not be delivered in the first iteration then it is important we add it to the Information Product Canvas so it is visible.
10 – What is the elevator pitch
Vision
The Vision statement area is where we create a quick elevator pitch for the entire Information Product Canvas. Think of it as the pitch you do to a senior leader while riding together for 2 minutes in an elevator. Or in the modern remote world think of it as the 2 minute pitch you do over zoom to get funding to have the Information Product delivered.
The Vision statement uses a fixed format that uses the following construct:
For who – Who will be the primary user or the primary sponsor of this Information Product. We don’t use the Persona’s here, we want a specific person or a specific role identified.
Who needs – What do they need this Information Product to help them achieve, what value will they gain if it is delivered. We grab this from the Outcome/Action area.
The – Names are important, so we combine the Information Product name and its primary delivery mechanism to create this
That – What does this Information Product actually provide. We grab the key business questions from the Business Questions area, or the key features we will deliver from the User Stories & Will/Won’t areas
Unlike – What is the alternative of not having this Information Product available. Often we state the current problem the Information Product is trying to remediate, but the age old automating a manual process is always a good starter for 10.
We create the Vision statement after we have completed most of the Information Product Canvas. We have seen lots of teams start by completing the Vision statement first with the key stakeholders before filling out the rest of the canvas areas. Remember, you craft your own way of working that flows the way that is successful for your team and your organisation.
11 – How long will it take to deliver
T-Shirt Size
The T-Shirt Size area is where the AgileData team provides a guesstimate of how long this Information Product may take to deliver.
We use T-Shirt sizes (Small, Medium, Large etc) as a way of providing relative sizing for delivery across multiple Information Products.
The AgileData team will use a series of ratios to standardise/moderate the T-shirt sizes. They will compare multiple Information Products to use sizing ratios across the Information Products, for example a Medium sized Information Product is twice the effort compared to a Small Information Product. They will also use the number of iterations as a ratio for the Information Product size, for example a Small Information Product is likely to be delivered in a single iteration, compared to a Medium Information Product which is likely to be delivered in three iterations.
The AgileData team is the only group who can size the Information Product, they are the only people with the knowledge and experience to have a reasonable guess. Watch out for an anti-pattern where other people apply sizing to the Information Product and then try to hold the AgileData team to account to deliver the Information Product within the T-Shirt size.
The T-Shirt size assigned by the AgileData team is a guess. Not an estimate, not a promise and not a commitment. Over time the AgileData team will get better at guessing the level of effort to deliver an Information Product based on the information in the Canvas (a bit like how a fine wine gets better over time). But it is still a best guess, the only time we will have certainty on what level of time or effort it will take to deliver is one the team has delivered it.