A pull request gets merged. The team celebrates for about ten seconds, then the next ticket takes over.
The feature may appear in a changelog. It may get a sentence in a customer call. Most of the time, though, the people who would benefit from it never hear about it.
That gap is not a writing problem. It is a workflow problem. The information needed for a useful launch is already in GitHub, but it is spread across the pull request, issue, review comments, screenshots, and the conversations that led to the change. Someone still has to turn that material into a story, decide where it belongs, and make sure the resulting posts do not all sound like the same paragraph.
The workflow below turns that scattered context into a launch without building a second marketing department.
1. Start with meaningful changes
Do not turn every merged pull request into a campaign. A dependency update, a typo fix, and a new workflow do not deserve the same treatment.
Start by asking what the customer can do now that they could not do before. If the answer is difficult to find, the change probably needs a changelog entry or an internal note, not a launch campaign.
A useful first pass looks for changes that:
- remove a repeated customer frustration
- make an important task faster or safer
- open a new use case
- change how the product should be understood
- complete a group of smaller improvements around one problem
This is where a GitHub label, release tag, or a simple command can help. Create a small queue of possible product moments instead of a marketing event for every commit.
2. Read the pull request as customer evidence
Pull requests are written for engineers and reviewers. They often explain implementation details well and customer value poorly. That does not make them bad source material. It means you need to translate them.
Look for five pieces of evidence:
- What was difficult before?
- Who ran into the problem?
- What changed in the product?
- What can the customer do now?
- How could someone verify the improvement?
Imagine a PR titled Add saved views to the campaign queue. The useful product story is not that the team added a new database table and a filter component. It might be that a marketing lead can now return to the same set of campaigns every morning without rebuilding the filter.
The implementation tells you what shipped. The surrounding issue and review comments often tell you why it matters.
3. Decide whether it needs a launch
Before writing, choose the communication level. A simple four-level system is enough:
| Level | Typical change | Best treatment |
|---|---|---|
| Silent | Infrastructure work or an invisible fix | Ship it and record it internally |
| Mention | Small usability improvement | Add it to a roundup or short update |
| Feature | A meaningful workflow improvement | Publish a changelog entry and selected posts |
| Launch | A new capability or strategic change | Build a coordinated campaign with assets and follow-up |
This decision saves more time than a better prompt. If the change is a mention, you do not need five channel variants and a carousel. If it is a launch, a single sentence in the changelog is not enough.
There is also a useful middle option: bundle several small changes that solve the same customer problem. Three improvements to onboarding can become one onboarding campaign. The individual commits stay small. The customer story becomes clear.
4. Write one campaign brief
Do not begin by opening LinkedIn. Start with a brief that gives every channel the same source material.
Keep it short:
- Audience: Who should pay attention?
- Problem: What were they trying to do?
- Change: What did you build?
- Outcome: What is easier, faster, or possible now?
- Proof: What can you show?
- Action: What should the reader do next?
For the saved-views example, the brief might say:
Marketing teams repeatedly rebuild the same campaign filters to check what is ready to publish. Saved views let them keep a working queue such as “needs review” or “scheduled this week” and return to it in one click. A short screen recording can show the old repeated setup and the new saved view.
That paragraph is not a finished post. It is a stable source for the posts.
5. Adapt the story for each channel
The campaign brief should stay consistent. The output should not.
A changelog entry can explain the workflow in detail and remain available as a permanent record. LinkedIn can lead with the problem and the lesson for a broader product audience. X can use a sharper hook, a short demo, or a thread. Instagram may need an image or carousel that makes the before-and-after obvious. Email can focus on relevance for existing customers and give them a direct next step.
The channel changes the job of the message:
- Changelog: Help an existing user understand what shipped.
- LinkedIn: Help a wider audience recognize the problem and see your point of view.
- X: Create a compact reason to stop, understand, and respond.
- Instagram: Show the change before asking the audience to read about it.
- Email: Explain why this matters to the recipient now.
The best multi-channel campaigns repeat the idea, not the wording.
6. Attach the proof
Product marketing gets easier when the asset is decided alongside the copy.
For a workflow change, a screen recording may be enough. For a new visual feature, use a before-and-after image. For a larger launch, you may need a short demo, a diagram, or a small set of channel-specific images.
Ask one question: what would let a skeptical customer understand this in ten seconds?
If the answer is “a paragraph explaining the architecture,” the campaign is probably describing the product from the inside. Go back to the user’s task and show the result.
7. Review the campaign as a set
Read all the outputs next to each other. Check for the same claim being made at different levels of certainty. Look for channel copy that promises more than the product does. Make sure the image and the text describe the same flow.
This review is also where you remove repetition. A campaign can have a common idea without saying “we are excited to announce” five times.
Keep publishing as an explicit boundary. Drafting and editing are reversible. Sending a post to a public channel is a side effect. Someone should know exactly which channels are selected, what will be sent, and when.
8. Measure the product moment
A launch is useful when it helps the right people discover and use something.
Choose one or two signals before publishing:
- visits to the feature page
- activation of the workflow
- replies or questions from current customers
- clicks from a post or email
- adoption among the audience named in the brief
Do not demand perfect attribution from every small update. A useful note in the campaign record is often enough: which message went out, what asset was used, and what you learned.
Where an agent fits
An agent can handle much of the repetitive path. It can inspect a selected GitHub PR, pull in the related issue, find the relevant product context, draft a brief, create channel-specific variants, and prepare assets from templates.
It still needs a product surface that makes the work legible. The agent should know which campaign it is editing, which channels are connected, which template each output uses, and whether it is preparing or publishing.
OpenPMM is being built for this workflow. You connect GitHub or Linear, give OpenPMM your brand context, and let an agent prepare direct sends or a full campaign. You can review the outputs in the UI or through the agent you already use, then confirm the send when you are ready.
A merged PR stops being the end of the communication process. It becomes a clear input to a small, repeatable product launch workflow.