A few questions to ask yourself:
Do you want to be the mini-CEO of the product?
Do you have enough experience to appreciate how engineering operates to build a product?
Are you comfortable making major tradeoffs between direct customer requests and company strategic priorities?
Are you savvy enough to navigate tough decisions when requirements or quality are cut to meet deadlines?
Are you excited about documenting product strategy, epics, users stories and low level requirements?
If you answered yes to a majority of these, by all means seek out a role in PM.
The most important business objective for Product Marketing is to help the business achieve its sales targets – for some businesses this will be measured in MRR or ACV. However you measure this number, ensure you understand PMMs role in helping the organization meet it. This is the most important thing PMM can do and everything we prioritize needs to tie back to it. If it does not, then we should not be working on it.
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)
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
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!
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.
It’s really important to understand your product’s team development process. How is the Product team structured and why? What and when are their sprint cycles. How do new tasks get on the backlog and how is the backlog prioritized. If possible, attend backlog prioritization meetings so you can understand what information PMs look at when making decisions.
This will help you be much more strategic in how, when, and why you add on the backlog. Also it’s key to develop a close relationship with a few PMs so they can champion for you during the prioritization process.
If your company has the resources, I would advocate for there to be an in-app copy writer that sits under design. By putting them with design, they will have the shortest path to where the product is actually being made. That being said, they should be very aligned with both product management and product marketing.
In one of my past roles, it's been a combination of product management and product marketing who were responsible for it.
We like keeping this with the PMM or a Product Manager/Owner, as the person writing this copy needs to be super familiar with the product and user experience. They need to be power users, IMO. Occasionally, I've leveraged Support or Customer Success Managers for this as well, becausr they are so familiar with the ins and outs of the user experience.
Another solution would be to have someone is design or engineering draft the basic copy and have a copywriter make it sound better.
In my opinion, PMM has a better vantage of customer needs and command of customer voice to produce best in app copy, product naming nomenclature and in-product guidance. This responsibility can be shared with UX and PM to ensure everyone is on the same page. Engineering and PM usually need a lot of help in this department as it is not their forte.
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.