At the end of 2011, The New York Times had sold just 406,000 digital subscriptions — $44 million in revenue, or 1.9% of the company's top line — and that shortfall is the opening exhibit in a new Harvard Business Review argument that the project-based operating model is structurally broken for digital work.

In "Why the Digital Product Model Beats Project-Based Approaches" (March–April 2026 issue), authors Ryan Nelson and Thomas H. Davenport use the Times' paywall stumble to frame a distinction practicing product managers live every day: temporary teams can build new systems, but only permanent teams can both develop them and manage them after launch.

The Times case is instructive precisely because the launch itself was a success by conventional project standards. In March 2011, against industry trends, the 160-year-old company implemented a paywall and began charging for online content. The system shipped. The project closed. And then the numbers stalled — 406,000 subscriptions after nine months is not nothing, but it is not a transformation either.

What changed at the Times?

According to the authors, the company realized it needed "a different way to operate" to aggressively grow digital revenue. That realization is the hinge of the article: the problem was not the build, it was the operating model left behind once the project team dispersed.

This is the core failure mode of project-based digital work:

• Projects end at launch, but digital products generate most of their value — and most of their hard decisions — after launch.
• Temporary project teams take institutional knowledge with them when they roll off.
• No one owns the ongoing tradeoffs between iterating on the product, maintaining it, and managing it as a business.

A digital product model, by contrast, assigns a permanent, cross-functional team to a product and its outcomes for the product's entire life — building it, running it, and evolving it against revenue and engagement goals rather than against a delivery date.

Why does the distinction matter for product managers?

The authors' framing — temporary teams build, permanent teams build and manage — is a sharp tool for PMs arguing against the project mind-set inside their own organizations. It locates the failure not in individual execution but in team topology.

The conditions matter. The project model still works where work is genuinely finite, well-specified, and hands off to a stable system that someone else owns — a data center migration, say. It fails where the deliverable is a system whose value depends on continuous iteration, measurement, and re-prioritization in response to user behavior. The Times paywall was exactly that kind of asset: shipping it was the starting line.

The tradeoffs are real, and the piece's argument does not make them disappear. Permanent product teams demand sustained headcount commitment rather than fungible project staffing, which makes them a harder sell in cost-cutting cycles. They require funding tied to outcomes rather than milestone completion, which most finance functions are not set up to administer. And they concentrate accountability in a way that exposes weak product leadership quickly — there is no project closure to hide behind.

The Monday application

For product managers, the practical takeaway from the Times example is to audit what happens to your initiatives at launch:

• Who owns the metrics after go-live — by name, not by committee?
• Is the team that built the thing still funded to iterate on it a year later?
• Does your budgeting treat the product as an ongoing business line or a completed capital expenditure?

The Times' 1.9% figure is the number to keep in view: a shipped product with no permanent owner behind it can look like a success on the project dashboard while contributing almost nothing to the business. Digital subscriptions eventually became a pillar of the Times' revenue — the outcome the article sets up as the payoff of the operating-model shift — but the 2011 baseline shows how little a project-model launch guarantees.

Davenport, a longtime analyst of analytics and digital operations, and Nelson stake out a position that product practitioners have argued for a decade: the org chart, not the backlog, is what determines whether digital investments compound. As more enterprises reorganize around durable product teams funded by outcome, the project-to-product shift stops being a tech-industry convention and becomes the default operating model for digital work.