Product Marketing

For a long time, how to describe a feature was something a team figured out after the feature was finished. Engineering wrote a release note, someone added a line to the feature list on the website, and sales got a heads-up that something new had shipped. The trouble was that the line was written in the language of the people who built it.

Pagedeck's real-time collaborative editing release went exactly that way. Theo, the engineer, wrote "multiple users can edit the same document at once" in the release note, and the same sentence went straight onto the website. Six months of work, and signups didn't move. When Sofia read that sentence out in a customer meeting, the reply was "why would we need that?" Nothing in the sentence was false. It just gave the listener no way to recognize their own problem in it.

Mia rewrote the line as "your meeting notes are finished before the meeting ends," and the reaction changed. What customers were actually living with was this: someone took the recording away after the meeting, wrote it up, posted the document two days later, and by then nobody quite remembered who had agreed to do what. The first sentence described the feature. The second described the annoyance the feature removes. Same software, and only one version stuck.

A second problem surfaced at the same time. The website called Pagedeck a collaborative document tool, the sales deck called it a team knowledge management solution, and the support articles called it an online notebook. Three names for one product, so a customer heard three different explanations and had to decide from scratch each time whether this was the thing they were looking for. The longer that decision took, the more people simply closed the tab.

Neither problem shows up as a bug report. Nothing is broken, the feature works, the website is live, and every team can point to work they finished. The cost lands somewhere nobody is measuring — in the seconds a visitor spends deciding whether this page is about their problem, and in the meetings where a prospect has to be told the story from the beginning again.

Both problems have the same root: nobody owned the job of turning what got built into what customers say. Engineering treats an accurate account of what shipped as the end of its responsibility. The ads team treats carrying an already-approved phrase to a channel as the end of its own. The gap in between — finding out what pain customers have and what they call it, then fixing that in one sentence — has to belong to someone.

At most companies the gap opens up because of who sits next to whom. The people who know the product best sit with engineering and talk in terms of what the system does; the people who talk to customers all day sit with sales and hear the problem in the customer's words, one deal at a time. Neither side has the time or the standing to write the sentence everyone else will have to use.

Product marketing is that gap turned into one person's job. It moves what was built into customer language, and it makes that language identical no matter which door of the company it comes out of. Positioning and the value proposition sit at the front of the work for that reason. Positioning decides which slot the product takes in a customer's head among the alternatives they're already weighing; the value proposition compresses that slot into a single sentence. Until both are settled, every phrase downstream gets invented again from nothing.

The work splits two ways: the artifacts that pin the language down in writing, and the activities that push that language outward and keep it current. Separating them tells you where to look when something is off. If every person describes the product differently, look at the artifacts. If the documents exist but nobody uses the words in them, look at the activities.

Artifacts are the documents that hold the language still. Three of them get used at different moments.

1. Messaging — the core phrases that describe the product, organized as a system. A one-sentence introduction, three core values, and the variants to use for each customer type all live on one page. Website copy, ad copy, and sales decks all come down from here. Pagedeck's messaging document opens with "the collaborative document tool where meeting notes are finished before the meeting ends," with separate phrasings underneath for product managers, engineering leads, and executives. Without it, each team invents its own sentence and within six months the product has four or five names.
2. Battlecard — the counter-arguments for a deal against a specific competitor, on a single sheet. It carries the rival's strengths and weaknesses, the comparison questions customers keep asking, and the evidence to answer them. It has to be readable mid-meeting, so it rarely runs past two pages. It's where you prepare, in advance, to answer "their free plan gives us more storage" with "we don't cap document count, and teams that pile up short meeting notes hit their limit first."
3. Customer story — what a real customer achieved, written as a narrative: the problem, what changed, and how the numbers moved, in that order. What someone else got out of the product carries more weight at the final decision than anything the company says about itself. One story with "writing up meeting notes dropped from six hours a week to one" in it is worth more to the person who has to get budget approved than ten lines of feature list.

Activities are what actually moves the language. Three again.

1. Sales enablement — giving the sales team the material and the training to sell well. It doesn't end when the messaging and the battlecards exist; it stays with a rep until they can say those things in their own voice. New-hire training, demo scripts, and a bank of answers to the objections that keep coming up all belong here. You check whether it's working by whether reps use the language in meetings, not by how many documents got produced.
2. Competitive intelligence — continuously gathering what rivals ship and how they price, then circulating it internally. The continuous part is the point. If a competitor cut prices 30 percent last month and your battlecard still answers with last year's price sheet, that document costs the sales team credibility instead of helping.
3. Launch plan — who does what, and when, around a release. The announcement copy, the release date, who gets advance notice, the briefing for support, and the metrics that will say whether it worked all sit on one page. Set only the date the feature turns on and leave the rest blank, and support will be hearing about the feature for the first time from the customers asking about it.

The two halves feed each other. What competitive intelligence collects changes what the battlecard says; sales enablement carries the revised battlecard to the reps; what reps hear in the field sends the messaging back for another pass. The loop has a natural pace. Messaging gets a serious pass once or twice a year and small corrections in between; battlecards move whenever a competitor does, which in a crowded category means monthly; launch plans come and go with releases. Run only one half and it spins. A team that writes documents without delivering them ends up with a folder nobody opens, and a team that delivers without revising spreads six-month-old claims.

"Before we write the release note, can we settle the messaging? We haven't decided what customers call this yet."

A request to agree on the name for the thing before writing anything that describes it.

"They doubled their free storage last week. I'll update the battlecard and get it to the sales team."

One person owning the whole path from spotting a competitor's move to revising the material and putting it in reps' hands.

"Launch is next week and support hasn't been briefed. Let's push the date three days."

A judgment that shipping the code isn't the same as being ready, and that opening the gate early just dumps the questions on the support queue.

For a while nobody at Pagedeck owned this. Mia wrote the launch copy as part of planning the feature, Ravi wrote separate ad copy, and Sofia explained it again in her own words in meetings. All three worked hard, and customers still got a different explanation every time.

That changed when Grace hired a product marketing manager. A messaging draft now lands a month before the feature is finished, Mia and Sofia go through it together and rewrite it in the phrases customers actually use, and the agreed sentences go into the website, the sales deck, and the support articles at the same time. When real-time editing was reintroduced, the only thing that had changed was one sentence, and paid-conversion inquiries rose noticeably that month. One more thing changed too: once Sofia's explanation matched the website's, the first ten minutes of each meeting — spent re-confirming what the customer had already read — disappeared.

The most common reading is that product marketing is advertising for the product. Marketing is in the name and the visible output is copy and collateral, so the assumption is easy to make. The center of gravity is on the inward side, not the outward one: deciding who the product is for, why someone should pick it over the alternative, and what to call it, all worked out alongside the product team. A useful test: if the messaging document were deleted tomorrow, could the ads still run? They could — badly, in five different voices. If the ad account were closed tomorrow, could the messaging still be written? Yes, and the sales team would still need it. That asymmetry is where the job actually lives. Left uncorrected, this reading delays the hire. Someone already runs the ads, so it doesn't feel urgent, and budget goes up while the thing being said stays undecided.

The other frequent mistake is treating it as launch-time work. The launch plan is the most visible artifact, so it looks that way. But launches happen a few times a year, and in between, competitors keep moving and the words customers use keep shifting. Work that only attaches at launch leaves battlecards answering last year's pricing and messaging aimed at a segment that stopped converting. Ship a great feature into that state and no sentence about it lands. There is plenty to do in a month with no release: reviewing why lost deals were lost, collecting the phrases customers leave in support tickets and folding them into the messaging, moving a rival's new price tiers onto the battlecard.