---
aliases: ["The Real Job of a Newsletter"]
Is A: Evergreen
Topics: ["[[topic-content-strategy]]", "[[topic-newsletter-growth]]"]
Status: Published
---
# The Real Job of a Newsletter
People subscribe to newsletters for different reasons: to learn, to stay informed, to feel part of a community, to be entertained, to have a trusted filter. But they stay subscribed for one reason: the newsletter reliably delivers on the implicit promise it made when they subscribed.

The biggest growth lever for any newsletter isn't content, distribution, or growth hacks — it's understanding the real job the reader is hiring the newsletter to do, and doing that job consistently well.

For Refactoring, the job is: 'help me think more clearly about engineering, leadership, and building software at scale, without taking too much of my time.'

The jobs-to-be-done framework, originally developed for product management, maps perfectly to newsletters because a newsletter is a product. Readers have alternatives — other newsletters, blogs, podcasts, books, conversations with peers — and they allocate their limited attention based on which option does the job best. Understanding the specific job your newsletter is hired to do, in the reader's own language, is the single most important strategic insight you can have. It determines content scope, tone, length, frequency, and format. Every decision flows from it.

I arrived at Refactoring's job statement through reader interviews, not assumption. Early on, I assumed readers wanted tactical advice — specific frameworks, templates, and how-tos. The interviews revealed something different. Readers wanted to feel less alone in the challenges of engineering leadership. They wanted someone who understood their specific problems to help them think through those problems, not hand them a pre-packaged solution. The difference is subtle but enormous in its implications for content strategy. Tactical content competes with documentation and Stack Overflow. Thinking-partner content competes with trusted mentors, and there is far less supply of that.

The job statement also serves as a powerful editorial filter. When I am choosing between two potential newsletter topics, the question "which of these better helps engineering leaders think more clearly about building software at scale?" immediately resolves the decision. It eliminates topics that are interesting but off-job — a piece about personal productivity habits, for example, might be interesting coming from me but does not serve the core job readers hired Refactoring to do. This discipline to stay on-job is what builds the reliability that drives retention. Readers learn that every issue will be relevant to their core challenge, and that predictability is worth more than occasional brilliance in an unrelated domain.

## Key insight
A newsletter's job is not what the author thinks it is — it is what the reader experiences it as. The gap between these two perspectives is where most newsletter strategies fail. Authors optimize for what they want to write. Successful newsletters optimize for the job readers are hiring them to do. Discovering that job requires talking to readers and listening carefully to the language they use, not making assumptions based on content strategy theory. Once you know the job, every editorial decision becomes clearer, and the newsletter builds the kind of reliable value that drives long-term retention and growth.

## Related
- [[newsletter-growth-is-about-trust]] — Consistently doing the job well is how trust is built
- [[why-b2b-newsletters-work]] — The B2B context creates specific jobs-to-be-done that newsletters are uniquely suited to fill
- [[newsletter-subject-lines]] — Subject lines should communicate the job each issue will do for the reader
- [[b2b-content-is-trust-not-traffic]] — Understanding the reader's job is how content becomes trust-building rather than traffic-chasing
- [[note-good-strategy-bad-strategy]] — Strategy as understanding the core challenge, which parallels understanding the core job
