In the early 2000s, the kinds of problems faced by email marketers and the kinds of problems faced by SaaS product teams (not even an ungainly acronym in the early 2000s) seemed very far apart.
However, over the last few years, I have started to see a shift in the problems faced by email marketers. Building email programs is becoming more and more like building software, as email marketers move from a world driven by campaigns toward a more programmatic approach characterized by:
-- Contextual messaging based on observed behavior on websites, in apps, and other locations.
-- Programs that can be entered at several locations and exited at multiple locations.
-- Multiple channels.
-- A focus on helping a subscriber/customer do a job.
This focus on supporting clients in “doing a job” with complex process flows feels a lot (to me) like building a software product. So what are some of the tools that product managers use to build software that could be useful to marketers? A few come to mind — some of which are already in use by many marketers:
Customer journey mapping and service blueprints: Building a “map” of full customer experience and support activities, both those visible to clients (“front of house”) and those not visible to clients (“back of house”), is a great way to understand the role that email plays in the getting the client’s job done. This book is one that I’ve used several time when building maps over the last few years.
User personas and user stories: User personas are one way of codifying the context and needs of the person you are building your program for. User stories summarize what exactly the customer is trying to do. Understanding the client’s objectives in a concise manner is useful when building a complex communication flow. This article gives a good overview of how to build user personas and user stories for email marketing.
Experiment boards: Most product teams spend a lot of time tweaking their applications to optimize the metrics that matter for their business. Many teams will keep track of of all the experiments they have run, are running, and plan to run with an “experiments board.” This article gives you an overview of how to create an experiments board for marketing.
Design Sprints: One of the more common problems when building a complex software product is the endless “debate cycles” that take time but don’t help you build a product. Design sprints are a way to get good data from a prototype quickly. This post gives you a good overview of the design sprint approach.
I hope you find these tools useful.