Product Marketing

Unless you’re both the Product Manager and the Product Marketer, chances are you depend on another person performing a product management role at your company to help you create the marketing messaging for your product. And most new messaging is created as part of a new product launch or an existing product release… you know, when your product manager has a bunch of free time to answer all your questions (sarcasm).

But in order to write accurate and compelling messaging for a new product launch or a new release of an existing product, you need some basic (but important) information from your product manager like:

• What are the features coming out in the release?
• What do they do at a functional level?
• Who are the intended users of these features?
• How do these features benefit those users?
• Which features are “minimally marketable” features and which are table stakes?

To the uninitiated, this list of requests might appear simple enough. However, for anyone who has lived the life of a Product Marketer, you know it’s anything but. For most companies I’ve seen, there are a number of key challenges that must be overcome in order to get this information in a way that is useful.

 

Challenges with Getting Information Needed to Create Messaging

1. Getting the information

In some organizations (too many) there are no structured processes for giving Product Marketing the information it needs to support releases. The key to getting the right information is first to get organizational buy-in that the information sharing is important and must be done in the first place.

Ideally this would be done at the top level of each of the respective departments so, for example, the VP of Marketing or CMO is getting agreement from the head of Product that Product Management will provide the information in support of each release. Otherwise how will you be able to develop the product launch messaging?!

Once buy-in is obtained at the high level, it’s fairly easy to get the specific tasks defined and assigned down at the right level for you to get what you need.

 

2. Getting it in a consistent format

This one takes a bit of finesse as some Product Managers don’t like to compromise their way of thinking about features in order to be easier to comprehend. But if you let them just give you the info in whatever way they want, it can create a lot of pain for you as the Product Marketer because parsing each feature description from the PM can sometimes feel like translating a different language for each one.

This is why many companies use a structured approach for the PM to PMM handoff. Some call it a “Messaging Brief”, “Message Map”, “Core Messaging Document”, “Messaging Bible”, “Rosetta Stone”, the list goes on. Regardless of what they call it, the goal is to drive some uniformity in the structure for things without creating any inaccuracies.

One thing to note is that many of these companies use a new messaging document for each release. I suggest using something that is persistent over multiple releases and is changed to meet the needs of each one while maintaining a single, centralized location for the messaging. A message map is a good tool to help guide the PM as to what you need and how you will use it while also enabling you to update it as new product releases are rolled out.

Whatever tool you choose, you should start the process of getting information by providing a structured template to your Product Manager that defines what information you want to get and how you’d like to see that information presented. This can include everything from specifications on character lengths to sentence structure. You’ll need to calibrate on how prescriptive you want to be here and it might take a few iterations before you have it completely down. What you don’t want is just a .ppt thrown over the wall with a blurb on features with each articulated in a different way from one another.

And while consistency would be nice, don’t get overly hung up on forcing the PM to give you the information exactly as you’d ideally like to see it. The key here is for you to understand the inputs so you’re able to turn them into the messaging that you want to use with prospects and customers.

 

3. Getting the messaging checked for accuracy and approved quickly

Once you’ve taken the initial inputs and passed them through your product marketing brain to generate the messaging, it’s time for the review phase.

First up is a technical review by the PM to ensure the changes you made to the wording doesn’t create any issues with technical accuracy (make sure you tell your PM that it’s just for accuracy, not grammar or phrasing choices). Have them review right in the same message map that you updated after getting the initial PM inputs. This way they can see the exact changes you made and provide transparency on the entire process.

The key driver to getting it in a timely manner is planning. Start conservative and give plenty of time for each round of edits and be consistent in communicating to the various contributors when you need what and why (in order to support the release timing). Pad the schedule at first until you know better about how people work and where the potential bottlenecks will be (and won’t be).

 

4. Creating deadlines for your PM

The key here is to give your PM a deadline for providing you with the information you need about the upcoming release. The tricky part is figuring out when that deadline should be. You’ll probably need to run through a few iterations before you get it right, but for your first time through you can estimate the deadline. Just add the expected time for each of the dependencies and count backwards from the anticipated launch date.

Downstream dependencies to consider:

• Content creation and updates
• Web pages
• Datasheets
• Sales deck
• Blog posts
• Demo videos
• PR and communications
• Press release(s)
• Social media posts
• Announcement emails
• In-product notifications
• Enablement
• Sales enablement
• Marketing enablement
• Customer success/support enablement
• Channel/partner enablement

Of course, many of these activities can be done in parallel if your team has the bandwidth, and you can easily map all that out in a gantt chart to determine when you need to have the new messaging ready. I like TeamGantt, but there are plenty of other tools out there like MSProject, Workzone, Easy Projects among others. Whatever the tool, remember the first task on the “critical path” before any of the downstream dependencies get done is the new messaging that you’re creating.

If you don’t give yourself enough time to take the inputs from the PM and turn them into messaging that’s ready to use, you’re not doing anyone any favors. Just be honest with your PM about how much time you need. Ideally you start early and give everyone more time than they need and then whittle it down from there as you iterate to smooth out the process.

 

5. Adapting for Agile and Continuous Delivery

The good news in this kind of situation is that the product changes are few since the releases are more bite-sized; the bad news is that they’re happening all the time.

You’ve got a big choice to make as an organization here:

1. Condense your messaging update and release process to become more agile

OR

2. Decouple your marketing releases from your product releases

If you choose Option 1, you’re going to want to be included in a lot more development meetings (sprint planning, sprint reviews, etc.) to make sure you know what’s coming and what that will affect. One potential risk of doing this is that product launch can quickly become all you do.

If you choose Option 2, you can plan for a little more of a traditional launch, but your organization has to be ok with not immediately marketing features that are in the hands customers. HINT: It’s often not too hard to sell this as a good thing if you think of it as an opportunity to get some customer quotes about the new features for the marketing launch content.

In either case, you’ll need to determine (along with your PM) which features are minimally marketable so you know what from the message map needs to be included. You may even want to determine a more granular level of importance so you can plan for a different treatment of the most important features versus the least important ones.

If you use a message map similar to our template you will also have a good basis for creating a release summary or brief that includes the product release messaging to use as the basis of your communications.