What does Product Management have to provide in their Project Briefs in order for Product Marketing to be successful?

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.

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?

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. 

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!

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) 

Others?

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?

Objectives:

- 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?

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.

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