Collaborating with PMs

Contents

PostHog's culture leans heavily on independence, but launching and growing a product is one area where product marketers (PMMs) and product managers (PMs) genuinely need to work together. Here are the most important things a PMM can do to build that relationship:

  • Make first contact. Don't wait for your PM to come to you. Reach out early to learn the team's revenue goals, activation and retention gaps, what marketing has been tried before, where users come from, and any quick opportunities. Ask for customer interviews and competitive research too.
  • Live in your team's channel. Monitor the team Slack daily for feature updates, sales notes, and customer feedback. PMMs often spot marketable features that PMs and engineers overlook.
  • Show up in person and in meetings. Use rare in-person gatherings for growth reviews and planning, and join sprint meetings to stay informed and show genuine interest in the team's work.
  • Loop your PM into marketing. Share quarterly plans, campaigns, and creative directions. Core assets like the product page, launch email, and launch blog should always get PM review.
  • Use AI to stay informed. Lean on tools like the PostHog Slack app and scheduled tasks (e.g. a weekly product digest) to surface product status automatically instead of manually scrolling.

Know who owns what

Most confusion between PMs and PMMs comes from the word "launch" being used to mean several different things. We split shipping something new into two moments with two different owners:

  • A release makes a product or feature available to existing users. It's owned by the product team – the PM or team lead drives it from their own release checklist.
  • A launch gets a product in front of existing and new people. It's owned by marketing, with the PMM working from the launch checklist.

Releases and launches can happen together or separately, so the clearer you are on this split, the less you'll step on each other's toes. Read the full breakdown of releases vs. launches and who's responsible for what.

Use activation criteria to shape your GTM plan

Every product should have activation criteria – the qualifying events that tell us a user has actually got value from a product. Setting these is the PM's job, working with the product team, but they're just as useful to you.

Currently, activation criteria must occur at the person level, not the org level. This is due to limitations in how we map profiles in Customer.io.

Because activation criteria define what "success" looks like for a product, they're the natural foundation for your go-to-market plan and campaign goals. When you set the "now what?" goal metric for a launch in Customer.io, tie it to the product's activation criteria rather than a vanity metric like clicks. Ask your PM what the activation criteria are early – if they aren't defined yet, that's a signal worth flagging, because a launch that drives signups but not activation isn't really working.

Tap into growth reviews, not just launches

Per-product growth reviews are run monthly by PMs, and they're full of exactly the context a PMM needs – acquisition sources, drop-off points, retention curves, and open-ended user feedback. As a general habit, PMMs don't read these, which is a shame: there's a lot of good marketing insight buried in them.

Make a point of following the growth reviews for your products. Join them where you can, or read the write-ups async. This matters most for mature products. Early on, marketing's job is often awareness (getting people to notice a launch). Once a product has product-market fit, the bigger levers are usually engagement and retention, and growth reviews are where those gaps surface first. A dip in retention or a stuck activation step is often something marketing can help with (lifecycle emails, in-app nudges, best-practice content). Treat the growth review as your standing input for that work.

For the full story, including concrete examples from working across PostHog's product teams, read Collaborating with PMs as a product marketer.

Was this page useful?