How to Write a Product Description from Your Meeting

Why Does the Person Who Knows the Product Best Write the Worst Description of It?

It's a genuine puzzle: the product manager sat in the user research sessions where customers described exactly what they needed. They ran the discovery sprints that surfaced the specific problems the product exists to solve. They sat through the positioning workshop where the team argued, word by word, over how to frame what the product does. Nobody on the team knows the product's reason for existing better than they do.

And then they write: "a powerful workflow automation platform that streamlines operations and increases efficiency."

The gap isn't knowledge. It's translation direction. PMs don't write weak descriptions because they don't understand the product — they write weak descriptions because they translate their deep knowledge into company language, the vocabulary of features, specifications, and internal positioning frameworks, instead of leaving it in the customer's own language, which is where it actually arrived.

That customer language already exists, sitting in the meeting notes. It got there when a research participant said "I need to stop being the only person who knows where everything is," and the PM wrote it down verbatim. It got there when someone in the positioning workshop said "the problem we're solving is that people don't trust the tool to remember things." It got there when a discovery interviewee said "every time I hand off a task, I lose visibility and something drops."

That's the raw material for a description that actually converts. The work isn't writing it from scratch — it's extracting it from notes that already have it, instead of replacing it with marketing language on the way to the page.

---

What Product Description Elements Meeting Notes Provide

Meeting notes from product work contain specific inputs for each element of a product description:

User research sessions → Hook material: Direct customer quotes about the problem the customer faces are the single most valuable input for product description hooks. The 3-star review equivalent in meeting notes is the customer who says "I like what this does but..." — the qualification that names the unsolved part of the problem. Also valuable: the negative cases, the workarounds customers describe, and the phrases customers repeat across multiple research sessions.

Positioning workshops → Primary benefit and competitive framing: Positioning workshops are where teams argue about the single most important thing the product does for a specific type of customer. The meeting notes from a positioning workshop usually contain: the problem statement the team agreed on, the customer type they're targeting, the alternatives those customers currently use, and the primary value the product provides that alternatives don't. All four map directly to product description elements.

Discovery sprint notes → Feature-benefit translations: Discovery sprints document the connection between customer problems and product features — the "therefore we're building X" chain. These notes contain the team's collective understanding of why each feature was added, which means they contain the benefit each feature is supposed to deliver. That causal chain is a feature-benefit translation waiting to be extracted.

Alignment meetings → Social proof and use cases: Notes from "what problem does this solve?" or "who is this for?" alignment meetings document the specific use cases and customer types the team has validated. These are the social proof signals for the product description — not broad "thousands of users" claims, but specific "built for [specific role] who [specific situation]" positioning.

---

Step 1: Extract the Right Passages

Before drafting the product description, extract three categories of material from your meeting notes:

Category A — Customer voice (exact quotes from users): Go through research session notes and pull direct customer quotes that:

• Name the problem in the customer's own words (not paraphrased into company language)
• Describe the emotional frustration or the specific moment the problem occurs
• Compare the current experience to what the customer wishes existed

Mark each with the session date, the customer's role/title if relevant, and the context of the quote. The context matters: a quote from a user who has tried and abandoned competitors is more useful for competitive positioning than a quote from a first-time user.

Category B — Team positioning language (from workshops and alignment meetings): Pull the specific sentences the team agreed on during positioning sessions:

• The one-sentence problem statement
• The customer type description (not "enterprises" — the specific role and situation)
• The agreed-upon primary benefit (what the product makes possible, not what it does)
• The competitive differentiation (what alternatives can't do, or don't do as well)

Category C — Feature-benefit chains (from discovery and roadmap meetings): For each key feature, find the meeting note passage that explains why it was added — the customer problem that drove the decision. The "why we built this" language is the benefit; the feature name is what gets listed in the spec.

---

Step 2: Translate Internal Language to Customer Language

The most important editing step when writing a product description from your meeting notes is translating internal product language into customer-facing copy. PM meeting notes are written in PM language. Customers don't speak PM language.

The most common translation challenges:

Jargon to plain language:

• "Reduce cognitive load in the handoff workflow" → "Stop worrying about what drops when you hand a project off"
• "Centralize source of truth for customer history" → "Everyone on your team sees the same information — no one has to ask you for it"
• "Async-first collaboration features" → "Everyone can contribute without being in the same meeting"

Feature names to outcomes:

• "Role-based access controls" → "Decide who sees what — so clients see their project status but not your margin notes"
• "Automated status updates" → "Your manager always knows where the project is without you sending a weekly email"
• "Templated workflows" → "Start every new project with the same reliable structure — nothing forgotten, nothing invented from scratch"

Internal metrics to customer results:

• "58% reduction in tool-switching" → "Most teams stop switching between four tools and just use this one"
• "NPS 72 among target segment" → "Teams that use it for 30 days typically don't go back" (when backed by actual retention data)

The test: would a customer say this, or would only a PM say this? If only a PM would say it, translate it.

---

Before/After Worked Example

Context: Rodrigo is a PM at a B2B SaaS company that has just shipped a new feature for their project management tool: an automated progress summary that notifies stakeholders of project status without requiring manual status updates from the project lead. He needs to write the product description for the pricing page, the app store listing, and the launch blog post.

He has meeting notes from: three user research sessions (total: 11 customers interviewed), one positioning workshop, one discovery sprint kickoff, and two "ready to ship?" alignment meetings.

Extracted meeting note passages:

From research session #2 (6 weeks prior): "My biggest time sink is writing status emails. Every Friday, I write the same kind of email to four different stakeholders, each of whom wants slightly different information. It takes two hours and none of them read it anyway." — Enterprise project lead, 8-person team

From research session #3: "The PM is always the information bottleneck. If they're out or swamped, nobody knows where anything is." — Department manager, spoke about the problem from the manager's side

From the positioning workshop notes: "We agreed: the product is for the project lead who is drowning in communication overhead. The benefit is not 'visibility' — it's that they stop being the single point of failure for status information."

From discovery sprint kickoff: "Why we're building automated summaries: because the current workflow requires the PM to manually compile status from five tools and write it up in prose. We want the tool to do that compilation automatically and send it on a schedule they define."

From alignment meeting: "Who is this for? The PM who has more projects than they can actively narrate. Five projects, eight stakeholders each. They can't write 40 status emails a week."

Before (internal language draft):

Automated Status Summaries

The automated status summary feature compiles project progress data from across your workspace and delivers scheduled updates to stakeholders via email or in-platform notification. Configurable frequency and recipient settings allow project leads to customize delivery. Reduces manual status communication overhead and improves stakeholder visibility into project progress.

PM language throughout. "Compilation" and "delivery" are product specifications, not customer outcomes. "Stakeholder visibility" is internal positioning language. "Reduces manual status communication overhead" is accurate but doesn't resonate. No hook.

After (from meeting notes extraction):

---

Stop spending Friday afternoons writing status emails nobody reads.

If you're the person who knows where every project stands — and the only person who knows — the automated status summary exists to get that information out of your head and in front of your stakeholders without you writing a single word of it.

Set the schedule once. The tool compiles progress from across your workspace and sends each stakeholder the update relevant to them — on the cadence you define, in the format they can actually use.

Built for project leads managing more projects than they can actively narrate. Five projects, eight stakeholders each — you don't have time to write forty status emails a week. Now you don't have to.

Set up your first automated summary in under 5 minutes.

Hook ("stop spending Friday afternoons writing status emails nobody reads") comes directly from the research session quote. The explanation of why it exists comes from the discovery sprint note. The use case ("five projects, eight stakeholders each") comes word-for-word from the alignment meeting. The CTA specifies setup time — a common objection handled upfront.

---

The Translation Rule That Prevents Internal Language Leakage

After drafting, apply the "would a customer say this?" test to every sentence. Go through the draft sentence by sentence and ask: could I hear a customer say this exact sentence in a research session, or is this something only a PM would say?

Phrases that fail the test:

• "Streamlines your workflow" — no customer describes their problem as "my workflow needs streamlining"
• "Centralized visibility" — customers say "I need to know what's going on without asking"
• "Seamless integration" — customers say "it connects to the tools we already use" or "I don't have to export anything"
• "Robust feature set" — customers say "it does the thing I need" or don't say anything because they expect that

Replace each failed phrase with the version from your meeting notes — the customer's own articulation, extracted from the research sessions.

---

Prompts to Reuse

Product Description From Meeting Notes

I'm writing a product description for: [Feature/product name and one-sentence description]
Context: [Where this will appear — pricing page / app store / launch post / sales deck]
Customer: [The specific role and situation — one person, not "enterprises" or "teams"]

Meeting notes I've extracted:

CUSTOMER VOICE (direct quotes from research):
  Quote 1: "[Exact customer quote — what they said about the problem]"
    Context: [Who said it, what role, when]
    Hook candidate: "[Draft of a hook line drawn from this language]"
  Quote 2: "[...]"
    Context: [...]

POSITIONING (from workshop/alignment notes):
  Problem statement: "[The agreed team articulation of the problem]"
  Primary benefit: "[What the product makes possible — not what it does]"
  Customer type: "[Specific role and situation — not general category]"
  vs. alternatives: "[What alternatives can't do, or don't do as well]"

FEATURE → BENEFIT CHAINS (from discovery/roadmap notes):
  Feature 1: "[Feature name]"
    Why we built it (from notes): "[The customer problem that drove this decision]"
    Benefit: "[What the customer experiences — in customer language, not PM language]"
  Feature 2: "[...]"
    Why we built it: "[...]"
    Benefit: "[...]"

USE CASE / SOCIAL PROOF (from alignment meeting):
  "[The specific validated use case — who uses it in what situation]"

Write the product description in three lengths:
1. Long form (250-400 words): Hook → primary benefit → features-as-benefits (bullets) → use case → CTA
2. Medium form (80-120 words): Hook → primary benefit → 2-3 features-as-benefits → CTA
3. Short form (40-60 words): Hook → primary benefit → CTA

Translation rules (apply before returning the draft):
- Every internal PM phrase must become customer language — "stakeholder visibility" → "everyone knows where things stand without asking you"
- Features appear only as benefits (outcomes), not specifications
- The hook uses a phrase a customer would actually say — check against the research quotes
- No hollow adjectives: "powerful," "seamless," "robust," "comprehensive" must be replaced with specific claims
- CTA names the immediate outcome of taking action, not just the action

---

Key Takeaways

1. The customer language you need for a product description is already in your research session notes: direct quotes from user interviews — especially descriptions of the problem and workarounds — are the rawest and most useful hook material available.
2. Positioning workshop notes answer the four foundational product description questions: who is this for, what problem does it solve, what do they currently do instead, and what does this product do better or differently.
3. Discovery sprint notes contain feature-benefit translations already done: the "why we built this" chain documents the connection between customer problem and feature — extract that chain rather than reinventing it for the product description.
4. The translation step is mandatory: PM language ("reduce cognitive load," "centralize source of truth," "streamlined workflow") must be converted to the customer language it came from before it can work as product copy.
5. The "would a customer say this?" test is the quality gate: run every sentence through it after drafting; any phrase that only a PM would say needs to be replaced with the research session language it was translated from.

---

Conclusion

A product manager's meeting notes from a single discovery sprint contain more useful product description material than most copywriters generate from a week of independent research. The customer quotes, the team's agreed positioning language, and the feature-benefit rationale are all there — captured in real time, from people who either have the problem or deeply understand it. The writing challenge is not finding the material. It is recognizing that the material is already written, and that the job is translation: back into customer language, out of the internal PM vocabulary that replaced it during documentation.

See also: The Ultimate Guide to Web Clipping.