Silicon Valley Product Group has published "Build to Learn vs Build to Earn," a new essay arguing that "the project model, which is all about output" remains "the most common way" to develop product — even in the AI age.

The post sits inside an argument SVPG has made for years. The firm writes in the opening: "We have long argued that there have always been at least two major ways to develop product." The project model is one. Build to Learn is the other.

What is the project model, and why does SVPG call it Build to Earn?

The project model, as the post describes it, runs on a prioritized roadmap of features and projects handed down from stakeholders or executives. Teams then build and ship against that roadmap. Output — features delivered, dates hit — is the measure of success.

The essay's title maps "Build to Earn" onto that approach. SVPG has long framed it as the default in most organizations: ship features, earn revenue, justify headcount. The article's opening then notes that this default holds even as AI tooling compresses shipping cycles.

Why does the contrast matter now?

When output gets cheaper, the assumption that output equals value becomes more dangerous, not less. AI tooling can ship features faster than teams can validate whether the features solve the problem they were meant to solve. That dynamic is what SVPG is naming with the Build to Learn vs Build to Earn split.

Build to Learn, by the article's framing, treats each shipped product as an instrument for generating evidence about users, problems, and solutions. Learning is not an activity that runs before shipping; it is what shipping is for.

How should PMs apply the framework?

The framework reduces to a single question for every roadmap item: is this work expected to earn revenue, retention, or another business outcome — or expected to learn something the team does not yet know?

A working reading:

• Build to Earn work: a stakeholder or executive sets the goal; the team ships against a date; success means the feature goes live.
• Build to Learn work: a team identifies a risky assumption; designs a small experiment; the success metric is whether the team's confidence changed.

These modes demand different metrics, different team structures, and different relationships with leadership. Project-model teams optimize for delivery predictability. Learning-model teams optimize for the rate at which untested beliefs get replaced with evidence.

When does each model work, and when does it fail?

Output-driven roadmaps work when the problem is well understood, the customer is stable, and the solution is largely known. They fail — the term practitioners use is "feature factory" — when teams keep shipping features that move no business metric because the underlying assumptions about the customer were never tested.

Build to Learn approaches work when teams have permission to run experiments before committing engineering capacity, and when a clear path exists from evidence to roadmap. They fail when "learning" becomes research theater: artifacts produced, no change made to what gets shipped.

The article body received for this piece was truncated mid-sentence in its description of the project model, so SVPG's full account of failure modes is not captured here. PMs reading the original should weigh the framework against their own organization's willingness to decide on evidence rather than roadmap status.

What changes for PMs on Monday?

The SVPG framing turns on one operational question: what does the team get paid to produce? If the answer is features on a date, the team is operating Build to Earn. If the answer is validated evidence that changes what gets built next, the team is operating Build to Learn.

Practicing PMs should name which mode their team sits in, then decide whether that mode matches what the business actually needs from product. Closing that gap is where SVPG points product practice next.