Building a marketing technology stack (also referred to as customer data infrastructure) can be daunting. It’s tempting to start compiling your stack using flashy and popular technologies rather than looking at actual use cases. Then again, unclear use cases make unclear requirements, which could lead to wrong choices anyways. That’s why we work with the user story canvas.
Introducing the user story canvas
Kidlin’s law – “If you write the problem down clearly, then the matter is half solved.”
What the User Story Canvas is doing is helping you achieve exactly that - writing down the problem clearly by breaking it down into several components.
1. Use case
Use cases are in general very broad and represent the first stab at articulating a challenge or problem the organisation is dealing with and trying to resolve. These can be vague, opaque and may contain multiple challenges at once.
2. User story
The objective of a user story is to transform a large and potentially ambiguous use case into specific and precise questions.
User stories follow a templated buildup that allows us to transform use cases into something:
specific
actionable
measurable
“As a {{role}} I would like to {{what you would like to know, understand, access, etc}} so that I can {{do a very specific action}} in order to {{the expected outcome}}.”
An example is – “As an acquisition manager I would like to track the onboarding steps in an efficient way so that I can understand which users did not finish their payment so I can send them an automated abandon basket email or push notification in order to increase”.
3. User story walkthrough
The user story walkthrough is a detailed, step-by-step, overview of the user story. It literally describes the different steps or screens we need to go through in order to be able to deliver on the user story. A detailed example can be found in the filled-in user story canvas.
4. User identifiers involved
User identifiers refers to the different identities under which as user can be known to the organisation. Examples are anonymous id, email, user id, device id, CRM id, etc.
It’s important to list these as (mar)tech stacks assemble data from different devices, sources and systems which means that users might have different identities depending on where the data is being sourced from. If this is the case a listing of identities is required in order to be able to cater for identity resolution.
5. Systems & tools involved
This section identifies which systems and tools are required to make this user story a reality. Are we ingesting data from the web in order to then blend it with data from a CRM? If so, then we need to instrument an SDK and ingest data from the CRM itself.
6. Blockers & restrictions
Listing all the potential blockers we might be facing. Is it a different team that has control over a specific system? Are we having problems with one of our applications? Is there a code freeze? etc.
7. Blueprint sketch
A schematic representation of what the blueprint could/would look like for reference purposes.
8. Data points captured
An overview of the actual data points that are required in order to turn this user story into a reality.
Analytics is the side of the business where everything has been reduced to data points while the business questions we’re trying to answer are usually “big”, “opaque” or “vague”.
Writing down these questions clearly forces you to specify different pieces of the problem and refine them. As a result, it helps everyone to understand which assumptions, hypotheses and data points are required to compose an answer to the questions.
An example of a filled out user story canvas can look like this.
Why you should use the user story canvas
Iterating through the canvas and breaking down your use case in individual user stories helps to achieve 2 important things:
It allows you to build “a book of user stories” which will allow you to determine which requirements your stack should be able to deliver on. “Your stack should be the sum of all user stories you want to put into production”
The user story canvas serves as a rollout plan as soon as you start building your stack. As you’ve defined your user stories in detail upfront your go-to-market speed which each of the use cases will be significantly shorter.
If you would like to explore the details of our work with other clients, please feel free to reach out. We are always eager to engage in insightful discussions.
Comments