I often get asked about writing Agile Marketing user stories and how they differ from developer user stories. I’ve written about it before in a two-part post on User Stories here and here. But I don’t think I’ve provided enough detail or examples, and I’d like to fix that.
I’m going to use Microsoft SQL Server as an example of a business-to-business (B2B) product. It’s a product that I’m somewhat familiar with, as I ran SQL Server marketing back in the late nineties. I’ll then walk through, step by step, the process of generating Agile Marketing User Stories for SQL Server to illustrate the process.
Any attempt to write user stories for marketing needs to begin by identifying your target market in the form of personas. Much has been written about personas. Karen Holtzblatt devotes a chapter of her book Rapid Contextual Design to personas. I use a modified version of Karen Holtzblatt’s form; this template was developed by Todd Warren for his Nuvention Web course at Northwestern. See below for an example; you can download it here.
First, I’m going to identify all of the personas that are involved in the decision to purchase SQL Server. I’m going to do this for large and medium size businesses; small business is another animal altogether, and I’ll not attempt to create personas or a buying process for small business. In large to medium size businesses, I’m going to assume that the purchase is generally made by a group of people, perhaps a formal committee or perhaps an informal group whose needs, wants and prejudices need to be addressed.
|Evaluation Lead||Leads the evaluation; does all the initial research; works with the groupto make a recommendation to the decision maker|
|Decision Maker||Makes the final decision|
|Financial decision maker||Owns the budget and makes the final decision on the financial terms.May be the same person as the decision maker.|
|SQL admin||Responsible for the administration of the SQL database.|
|Developer||Develops applications that use the SQL database|
|User||The eventual end user of the application using the SQL database|
A persona needs to be written for each one of these roles. Here is an example persona for the evaluation lead role.
Once you have detailed personas for each role, start thinking about how each role will progress from need recognition to purchase. This is known as the Buyer’s Journey.
I find the easiest way to visualize the Buyer’s Journey is to map it out with mind mapping software like that of MindJet. To the left is an example buyer’s journey for Michael, the evaluation lead, as he evaluates databases.
Once you have the buyer’s journey mapped out, you can start writing user stories for most steps in the buyer’s journey. I say most steps, not all, because some steps are internal, and it is neither possible nor desirable for the vendor to participate in those steps. However, you may be able to arm your supporters and internal champions with materials that will help them get through these internal steps, and “sell” on your behalf.
Here is an example Agile Marketing user story for Michael’s buyer’s journey:
As an Evaluation lead, I want to be able to see within 5 seconds what differentiates your product from the competition so that I can determine if you’re a fit for my preliminary list of candidates.
Once you have the Buyer’s journey mapped out and you’ve written Agile Marketing user stories for as many steps in the buyer’s journey as it appropriate for you as a vendor to participate in, the next step is to create the content that is going to satisfy those user stories. Just as developers write code to satisfy their user stories, marketers write content. And just as developers specify acceptance criteria for their code, Agile Marketers need to specify the “acceptance criteria” for their content.
In addition to writing the user story in the form of “As a [role], I want to [task], so that I can [goal or benefit]”, writers of user stories need to provide context and information that the writer of the content will need, as well as the acceptance criteria. Context in this case may be something like a list of the typical initial criteria a buyer like Michael may have, as well as the company’s unique differentiation.
Acceptance criteria are the conditions that must be satisfied, from the user’s point of view, before the code is considered done. As marketers, we should also write out acceptance criteria. Too often, we think we’re done when we write some content that addresses in some way our understanding of the user’s need.
In this case, I may want to use something like fivesecondtest.com to test my content – do viewers receive my intended message within five seconds? Can they recall the main message and some of the acceptance criteria?
Some acceptance criteria may require releasing the content. Does the content have a positive impact on the number of evaluations that we’re getting? Is it influencing the criteria by which evaluators evaluate our product against the competition? Is it increasing sales? These are acceptance criteria for agile marketing, and they should be measured.
Once you’ve put all this together onto a card (similar to the one above), you are now ready to begin your sprint planning. You should have multiple user stories going in to the Sprint planning session. You will almost certainly add additional user stories during the Sprint planning due to the input of the business and sales people that you invite to the session.
I’d love to hear from those of you practicing agile marketing; how do you write your user stories? Do you link them to the buyer’s journey? Are you specifying acceptance criteria?