Skip to content
Saturday, August 29, 2026
LICHT JOURNALMEDIA BUSINESS · PUBLISHING
S&P 500−0.35%FTSE 100−0.17%Euro/Dollar+0.22%Brent Crude+1.25%10-Year US+1.40%
LICHT JOURNALMEDIA BUSINESS · PUBLISHING
Home / Business News
Business News

Structuring a small newsroom's product team: what to build, buy and skip

A newsroom under fifty people does not need a Silicon Valley product org — it needs one embedded owner, two or three priorities and ruthless restraint on tooling.

MH
Michael Hayes, · August 5, 2026 · 4 min read
ShareXFacebookLinkedInTelegramEmail
Whiteboard sketch of a product loop in a newsroom meeting

The honest starting point for product at a small newsroom: you do not need a product team — you need product ownership, singular. The industry's product function grew up inside large publishers (the Times' product organization, the Washington Post's engineering arm under Bezos ownership), and the small newsroom version that works — documented across the trade literature's coverage of digital-native and nonprofit newsrooms — is one accountable person, a small priority list, and contractors for muscle. The failure pattern is equally documented: small outlets copying the org charts of giants, hiring specialists before foundations, and accumulating software faster than anyone owns it. This guide is the minimal structure that punches above its cost.

Licht Journal publishes information, not management advice; patterns are from the trade literature and operators' public post-mortems.

What does "product" mean at a small newsroom?

Three things, all in service of the reader relationship: the reading experience (site, app, newsletter templates — speed, clarity, the subscription flows), the audience data infrastructure (analytics, the CRM-adjacent plumbing, the preference center), and the internal tools that make publishing fast. What it does not mean, at this scale: a roadmap of speculative features, an innovation lab, or a design system. The product discipline that transfers from the big leagues is the loop — define the reader problem, ship the smallest thing that addresses it, measure, iterate — executed by one person who owns outcomes rather than a team that owns tickets.

The one-hire structure

Hire one product owner — a journalist-adjacent operator who can write a spec, read analytics, talk to readers and manage a contractor. Their portfolio, in priority order: subscription flows and churn points (the revenue-critical surfaces — checkout, account management, cancellation flow, the paywall logic); site performance (speed and reading experience, which measurably move both SEO and conversion); and email infrastructure (delivery, templates, segmentation). Everything else is queue. The owner's tools are the analytics stack, a testing tool (even a cheap A/B service pays for itself on checkout alone) and a reliable contractor bench — a trusted freelance developer and a designer, engaged in bursts rather than on retainer. The full-time roster stays at one until the backlog of revenue-relevant improvements genuinely exceeds one person's throughput for two consecutive quarters.

What to build, buy and skip

Buy: the commodity layer — CMS (the publishing platforms' standard tiers), analytics, email delivery, the subscription/paywall tool discussed in our platform comparison. Building commodity infrastructure is the classic small-newsroom product mistake: months of contractor spend replicating what a vendor rents for hundreds a month. Build: only the thin layer where your publication differs — the presentation of a distinctive format, a data project, an integration between two bought systems. Skip: apps without the behavioral case (covered in our app-versus-web guide), bespoke design systems, headless-CMS migrations before the content model is stable, and any tool whose purchase predates an owner to run it. The audit question for every line in the software budget: who owns this, and what reader-facing number does it move?

How does product work with editorial?

Embedded, not adjacent. The product owner sits in the newsroom's planning rhythm, reads the same analytics the editors do, and brings reader problems to the story meetings rather than receiving feature requests through a ticket queue. The trade literature's consistent finding across digital-native newsrooms: the product-editorial relationship works when both sides optimize the same metric — reader value — and fails when product becomes an internal services desk or, worse, a shadow editor deciding what journalism is worth. At small scale the advantage is structural: one owner cannot hide from outcomes, and the loop stays honest.

What generalizes?

That product at small scale is a discipline, not a department: one owner, the revenue-critical surfaces first, buy the commodities, build only the differentiators, and measure everything reader-facing. The structure scales down to a half-time role at the smallest outlets and up smoothly to the first hires of a growing one. What does not: the giants' org charts, which describe problems a fifty-person newsroom will never have, and the tooling envy that accompanies them — the best product organizations in small publishing are consistently the most restrained, not the best-equipped.

Frequently Asked Questions

Does a small newsroom need a product team?
No — it needs product ownership, singular: one embedded owner accountable for subscription flows, site performance and email infrastructure, with a contractor bench for development and design muscle.
What should newsrooms build versus buy?
Buy the commodity layer — CMS, analytics, email, paywall tooling. Build only the thin layer where the publication genuinely differs, like a distinctive format or a systems integration. Building commodity infrastructure is the classic small-newsroom waste.
How should product and editorial work together?
Embedded, not adjacent: the product owner sits in planning and story meetings, works from the same analytics, and brings reader problems directly. The relationship fails when product becomes a services desk or a shadow editor.