Published 2017.08.22
In the process of earning my MBA I was presented with countless business models, techniques, and frameworks. Many of these were quite valuable, many more of these were simply slight variations of each other. All of them had names, often fancy ones, and some had corresponding courses, lectures, worksheets, and training around them. What I present next warrants none of this. After trying dozens of different things over 20+ years, here’s how I tend to map Product related responsibilities in an organization. I’m sure there are other techniques that work, and I doubt any of this is uniquely my idea or process. It’s simply what I’ve learned to do, and my attempt to share this with others.
I like to start this exercise with identifying roles, responsibilities, and user stories. For those unfamiliar with Agile development methodologies, the key thing to know in advance is the Agile concept of a “User Story.” Wikipedia’s definition is very good (https://en.wikipedia.org/wiki/User_story), but I suggest broadening the thinking beyond “software system” such that one is thinking generically about “people trying to do business-related things.” Many other terms have been used in this regard, use cases, solutions, workflows and many others. In this broad sense, I think of a user story as a business person with a specific business goal or outcome. A typical User Story would be quite detailed, but for our purposes we can keep them pretty high level for now. Another way to think of this: the “roles & responsibilities” section of a job description often contains the most important user stories for an employee.
While there are many good frameworks for thinking about product marketing roles & responsibilities, I tend to use the pragmatic marketing framework (parent page) as it’s relatively well known and a good balance of clear and concise. As a reminder, for our purposes, this list of 37 items is a great starting point, but is not necessarily exhaustive. When I use this within an organization, I add, merge, rename and delete items freely. I also focus heavily on the topics themselves, generally disregarding both the vertical and horizontal axes. (To be clear I’m not saying this additional information doesn’t have value, simply that I typically find myself in roles where I’m responsible for items in all four quadrants.) The key is to track and manage items in a way that makes sense for you and your organization.
After completing such an exercise I’m typically left with most of the boxes in the framework plus some extras. These extras might include some of the below. You may also wish to look at any existing processes or checklists to see if you missed anything – product lifecycle deliverables can be especially good sources of data.
- Ecosystem development
- Case studies
- Marketplace enablement
- User Stories – core value Prop
- User Stories – advanced features
- Support escalations
- Marketing strategy
- Media buys & direct marketing
- Customer engagement
- Product lifecycle management
- Program lifecycle management
From here I might have 50 or so boxes. Next I write my list of possible owners: typically roles, groups, or (most commonly at smaller companies), employee names. By now you’ve probably figured out the next step – assigning boxes to owners. When assigning these, keep three things in mind:
- Focus on the owner of a task. If you’re familiar with the RACI model or one of its many derivatives, this is the R (Responsible). With rare exception, there should be one group or name with ownership of a task. Others may support, approve, review, get updated, etc. – but track these separately.
- Focus first on the broader assignments, then the details. Once the broad strokes are right it’s easier to make refinements or catch exceptions. For example, maybe the “Launch Plan” actually consists of three stages – each owned by a different group.
- Focus efforts on the ambiguity. This approach is most valuable for figuring out where to home tasks. For this reason, focus on tasks that are either unhomed or are at high risk of low quality or failure. If, for example, your company is already has a very reliable way of producing great press releases, you can probably just assign this (or this part) to Marketing and leave it at that
Depending upon the size and structure of your company, you may find the above output look the same for all your products. Or you may find that you have two common mappings, or five, or even one for each product. There is no inherent requirement for conformity (sorry process police), nor is there necessarily great value in having a unique split for each product. Different organizations have different needs, and may require different approaches to achieve their desired results. This process is about better understanding how you do things today and how you want to do them going forward, it is not necessarily about how to standardize or not.