When I write a recommendation, I'm lending credibility. I'd rather write fewer honest ones than many inflated ones.
Structure I'd use
- Relationship — how we worked together and for how long
- Context — the problem space / team constraints
- One or two concrete behaviors — decisions, communication, craft
- Outcome — what changed (qualitative OK if no public metrics)
- Forward-looking line — where they'd thrive
What I'd avoid
- Superlatives with no evidence ("best PM ever")
- Skills lists that read like a job description dump
- Sharing confidential metrics or unreleased strategy
- Writing about work I didn't actually see
| Weak | Better |
|---|---|
| "Great communicator" | "Turned a messy stakeholder conflict into a written decision log the eng team could execute" |
| "Data-driven" | "Killed a feature after the pilot missed the activation bar we set" |
If I can't be specific, I'd decline politely.
Writing clear recommendations is the same muscle as writing crisp PM narratives—worth practicing alongside a PM Certification. More craft notes in the newsletter.