All related (11)
Victoria Chernova
Director, Product Marketing, Gong.ioJune 8

There are different levels of information PMM needs from their PM partners throughout the development process. Depending on how your product documentation works, this information could entirely live in a product/feature brief or be split up between the brief and the product spec. 

At a high level, here's a deck we've used internally to build collaboration between PM and PMM. To be honest, we don't always get the answers to these questions in document format (or early enough), so sometimes this information is shared in meetings. 

Of course the size of the feature is a consideration as well. We have a tiering system, so the most depth is needed for Tier 1 features vs less information for Tier 3. 

Lauren Craigie
Director of Product Marketing, dbt LabsApril 26

oh mylanta I love this question. I think a lot of this can be an interative process with the PMM, but I think the things I see most often left out of these documents that could completely change the way a new feature is positioned includes:

- Not just what problem this solves, but how was the problem solved before this feature existed? (Was there a workaround in our product, or did users lean on external solutions?)

- Not just who will use the solution, but who, downstream, benefits from its use?

- Not just the business value, but the value for an individual that will prompt them to give it a try.

- Not just why users would use it, but why they wouldn't.

- Not just where the widget appears, but how and when a user should access it. Add some sample workflows that show the user journey from problem to resolution (should include interactions outside the product that prompt a user to go in, how they'll navigate to the feature, where the ah-ha moment is, and what they'll do with that info when they leave the product).

- Not just how it works, but what are all the ways it might not? What should the CS or Sales team be prepared to answer? Where are users likely to get stuck, if anywhere?

Becky Trevino
Executive Vice President Product (fmr VP PMM), Snow SoftwareMarch 2

When the transfer of information between PM and PMM occurs via a Project Brief, it is essential that the PM include a good description of the market problem this feature/product is intended to solve, why is this problem worth pursuing, who cares about it, why is our solution different than anything else the target customer could have purchased in market, and key use cases. The use case information should be broken down into feature and benefits.

This is a tricky question! I’d argue that there is more to the collaboration between Product Management and Product Marketing than the effectiveness of the Project Brief. However, you can read more about the relationship between PMMs and PMs here .

As for what to include in the project (or Product) brief, it should outline (at least) the following:

  1. Product name and release date
  2. Who the product is targeted to
  3. Product description
  4. Summary of the customer needs the product will meet
  5. Customer value proposition
  6. The impact the product will have on the customer
  7. Launch plan description and timetable of key events
  8. Product benefits and features
  9. Sales and customer service talking points
  10. Pricing
Max A.
Director of Product Marketing, PandaDocJune 15

I’ll probably need to write a blog post about it one day. :) For now, here is a brief summary of what we aligned on with the product team in terms of the categories of inputs we need to prepare a successful launch:

Earlier in the process:
1. Feature Description
2. Target Audience
3. Use Case and Customer Benefits
4. Timeline

Later in the process:
5. Business Objective
6. Availability (plans the feature will be available under – might not be relevant in your case)
7. Support Needed from Marketing
8. Linked to Product Assets
9. Additional Resources

Hope it's helpful. I'm happy to chat more!

Mary (Shirley) Sheehan
Group Manager, Engagement & Retention Campaigns, AdobeJune 7

The more context the better. PMMs should help to fill in the gaps, but a product brief should include:

- What problem this product / feature solves

- Who it solves for and insights about this audience

- Why we solve it differently (different > better)

- Timeline with milestones to get there

- Risks to timeline 

- Broader context/ how this fits in with other things you're doing (or if it's brand new, why / how) 


Tracy Montour
Head of Product Marketing, HiredScoreJuly 28

Product Managers have to give us PMMs the information we need to be successful, but it's often on us to inform them of what we need and hold them accountable for providing the proper documentation. Ensure you have a good relationship with the PMs you engage with, as well as the VP of Product who can give you the clearance to hold PMs responsible for providing the right context in the form of a feature brief. 

While the work starts WAY before the feature brief is created, here is what I hold the PMs accountable for providing (in general, it varied launch-by-launch):

Target audience:

- Who is this for?

- Which departments does this impact internally?

Problem scoping:

- What is the problem we are trying to solve? 

- What pains is the user/customer experiencing in their experience today? How will this feature/product improve this experience?


- What is the goal of the feature?

What is needed in order to launch the feature/product?

- Technical caveats

- Implementation guidelines

- Technical requirements

Which integrations are required?

How do we measure success?

Which OKRs is this tied to?

Joshua Lory
Sr. Director Product Marketing, VMware | Formerly Accenture, United States Air Force
Here are some OKRs my teams track for product launches: Awareness - Web, social and blog activity (impressions, engagements and link clicks) Sales if not self-serve - MQLs and SQLs Time to value - how long does it take a customer to onboard and get value? Consumption - How often are new features being used (DAU / MAU) Renewals - NRR
Becky Trevino
Executive Vice President Product (fmr VP PMM), Snow Software
I am also a huge fan of Amazon's "working backwards" framework where a press release is written at the onset of development. In organizations that use this methodology, it is a great time to bring in the PMM. It also begs the question, when should a press release be written? We typically write in in Phase 5 or 7. I'd argue we should be using this template or another much sooner in the process.
Lauren Craigie
Director of Product Marketing, dbt Labs
A few answers here, based on use case!  Naming inside the product (like features, tabs, or experiences) would be handled by PMM during the launch process. PM is likely to have ideated an internally-referenced name early on, but as we get past the beta and understand what value users actually derive from the feature, PMM adjusts to better match what the user would expect to see, for the task they want to complete. Other copy in the product UI that describes what a function is, or does, in the shortest and sharpest way, is handled by our design team (which sits inside our product org). ...