·

Build to Learn, Build to Earn: The Verb the Product Onion Was Missing

TL;DR

I pulled a book off my shelf last week that had been gathering dust for the better part of a decade.

Jeff Patton’s User Story Mapping: Discover the Whole Story; Build the Right Product. My copy has a coffee stain on the cover, a half-chewed pen bookmarking chapter five, and a sticky note from a version of me who used to work on feature teams at HP (Compaq, actually, but only a few of the old-timers can recall that story). I didn’t grab it out of nostalgia. I grabbed it because I needed to remember something.

And Patton said it in a phrase I had forgotten I knew: build to learn vs build to earn.

Marty Cagan leaned on it again in a recent piece on the product model in the age of AI, and it stopped me cold. Not because the idea is new. But because it’s the missing verb in the framework I’ve been writing about here for two years.

The Onion Tells You What. Patton Tells You How.

If you’ve read anything on this blog about the Product Onion, you know the inside-out logic: start from the core problem, then strategy, then features, then experience, then marketing, then go-to-market. Six layers. Each one earns its right to exist because of the layer beneath it. If you skip a layer, the whole thing gets wobbly, no matter how pretty the outermost ring looks.

But here’s what the Onion doesn’t tell you: how you build at each layer isn’t the same thing.

That’s the piece that always bugged me when I taught the framework to other PMs. “Okay, so I work inside out, but what am I actually doing at each layer? Am I writing specs? Am I coding? Am I running user interviews? Am I building production infrastructure?”

The honest answer is: depends on the layer.

And Patton’s phrase is the cleanest way I’ve seen to capture why.

Build to Learn: The Inner Layers

The inner two layers of the onion, the core problem, and the domain logic that makes your solution unique are not engineering problems. They’re risk problems.

Cagan lists four risks in product discovery: value, usability, feasibility, and viability. Patton would call these the “right product” questions. And the only way to resolve them is to build something that lets you learn.

This is the golden nugget. It’s not a PRD. It’s not a sprint plan. It’s a prototype.

The point of a prototype isn’t to ship. It’s to put a crude version of what you are thinking in front of a real human, a customer, an engineer, a stakeholder, so reality can push back before you’ve sunk six months of build cost into the wrong answer. Today, with tools like Claude Code, Cursor, and Figma-plus-AI, a competent PM can spin up ten or twenty prototype iterations in a week. That wasn’t true five years ago. It is now.

Here’s what’s clicked for me at Trevean: the inner layers of the Onion are not built to generate revenue. They’re built to earn conviction. Conviction that the core problem is real. Conviction that your unique approach actually solves it better than the alternatives. Conviction that your company can afford to build it and your customers can figure out how to use it.

You don’t earn conviction by writing specs. You earn it by building cheap, ugly, fast things that teach you something.

That’s build to learn.

Build to Earn: The Outer Layers

Once the inner onion is real, once you’ve got evidence, not opinions, that you’re solving the right problem in the right way, then you move outward. Features. Experience. Marketing. Sales.

This is where building looks the way most people picture it looking. Commercial-quality code. Production infrastructure. Reliability, scale, privacy, security, internationalization, operations, support. Patton and Cagan would both say, “This is where you earn the right to charge money.” This is where you deliver value that customers are willing to pay for, rely on, and build their business on.

Build to earn.

And this is the work that tools like modern AI coding agents have compressed, not eliminated, in ways that would have sounded like science fiction when I first opened Patton’s book. What used to take an engineering team six months now takes weeks. Delivery has sped up. That’s real.

But here’s the trap.

The Feature Factory Is Build-to-Earn Without Build-to-Learn

Most companies I’ve watched up close, HP, Dell, Canon, and, honestly, inside my own past habits, all have one problem. They’re very good at building to earn. They just skip the build-to-learn part entirely.

A stakeholder hands down a roadmap. A feature-team PM writes a spec. A designer mocks it up. Engineers ship it. Marketing announces it. Sales push it. The loop runs. Output happens. The Jira board looks beautiful.

And the thing that got built? It solves a problem nobody had, in a way nobody asked for, and sells to people who aren’t switching from what they already use.

That’s a feature factory. That’s built to earn, strapped to a rotten core. And AI has made this pattern faster and more expensive than before because the cost of building the wrong thing has dropped, but the cost of being wrong in the market has not.

In Onion language: teams are building the outermost rings, polished features (we called it polishing the turd), sleek UX, clever marketing, while the core is unverified. They’re earning without learning. And the onion rots from the inside, and stinks.

What This Looks Like at Trevean

Rushi and I have been building Trevean Spice with this sequence explicitly. Not because we’re pure, but because we can’t afford not to.

When we started testing the NFC-tag-to-farmer-story experience last year, we didn’t build production infrastructure. We built a prototype. A real NFC chip, a phone-tapped landing page that rendered a single farmer’s story, and we handed it to six customers in our network to tap. We learned in an afternoon that the tap itself was magical, but the landing page story was too long, buried the farmer, and didn’t answer the one question every tester actually asked: “Can I trust this?”

That was build to learn. Zero revenue. Massive clarity.

Now, only now, fifteen iterations later, we’re building to earn. The production of NFC integration. The scalable content pipeline. The operations behind each farmer relationship that let us actually keep the story accurate over time. That’s real engineering. Real cost. Real commitment. But we’re committing because we’ve already learned.

If we had gone the other way, built production NFC from day one, polished marketing, retail-ready packaging, the whole outer onion, we’d have spent six months shipping an experience that told the wrong story, to the wrong customer, with no way to learn we were wrong until the SKUs came back unsold.

Two Types of Testing. Don’t Confuse Them.

This distinction costs teams a lot of time, and it’s worth naming out loud.

In build-to-learn, testing means: Is this idea real? You’re testing for value and usability with users. Feasibility with engineers. Viability with your business. The outcome of the test is a decision to continue, pivot, or kill.

In build-to-earn, testing means: does this actually work as promised? You’re testing for scale, performance, reliability, security, and accuracy. The outcome is a decision to ship or hold.

Both are called “testing.” They could not be more different jobs. When a PM conflates them by treating a production load test as discovery evidence or a customer interview as a QA signal, they end up with products that don’t fail in useful ways. They fail in expensive ways.

Patton’s framing is the cleanest separation I’ve found: one activity is a learning activity. The other is an earning activity. Don’t run them on the same clock.

The Sequence Is the Whole Point

Here’s what I think both Patton and Cagan are really pointing at, and what the Product Onion makes visible:

You cannot build to earn what you have not first built to learn.

The Onion tells you the sequence of layers. Build-to-learn vs build-to-earn tells you the mode you should be in at each layer. The inner rings are learning rings. The outer rings are earning rings. Rush the inner rings and the outer rings collapse on nothing.

This is not a new insight. INSPIRED laid this out in 2007, and again in 2017. Patton’s book has been in print since 2014. Every product person who’s built anything substantial has lived the lesson. But AI has made it urgent again because the temptation to skip build-to-learn and jump straight to a production prototype has never been higher.

You can now ship a beautiful, broken thing in a weekend. That is both a gift and a test.

The Golden Era Question

Cagan closed his recent piece with a line I’ve been turning over all week. For product people who embrace the builder role, who develop their product sense, who get good at prototyping, he thinks we’re entering a golden era.

I agree. But the door is narrower than it looks. It’s not enough to know how to spin up prototypes. You have to know which layer of the onion you’re working on, and therefore what mode of building belongs there.

If you’re prototyping the core problem, you’re building to learn. Be ugly, be fast, be wrong a lot.

If you’re productizing the outer experience, you’re building to earn. Be rigorous, be scalable, be right.

If you’re not sure which one you’re doing, that’s the signal. That’s where most product work goes sideways.

One More Thing

After I finished Patton’s book the second time, I flipped to the back and found a handwritten note to myself from what must have been 2018. It said, “The work is the map, not the backlog.”

Past-me was onto something. The onion is a map. Build-to-learn and build-to-earn are the two ways you travel through it. And if you’ve been feeling the strange paralysis of modern product work, where AI is accelerating delivery but the outcomes haven’t gotten better, and something about the whole loop feels off, the diagnosis is probably right there.

You’re earning when you should be learning. Or you’re learning when you should be earning.

Peel the onion. Pick your layer. Pick your verb. Then build.

FAQ

Isn’t “build to learn” just another name for product discovery?

Yes and no. Discovery is the phase. Build-to-learn is the verb. You can be in a discovery phase and still be operating in build-to-earn mode (specs, production code, roadmap kabuki), and when you are, discovery produces nothing. Patton’s phrase is useful precisely because it names the mode of work, not the calendar block on a Gantt chart.

How does this relate to the Product Onion?

The Product Onion gives you the sequence of what to work on: Core Problem → Domain Logic → Features → Experience → Marketing → Sales, inside out. Build-to-learn and build-to-earn give you the mode of work at each layer. Inner two layers → build to learn. Outer four layers → build to earn. Skip either the sequence or the mode, and the onion rots.

Has AI actually changed the distinction, or just the speed?

Both. Delivery has sped up dramatically, building to earn takes weeks where it used to take months. But discovery also got cheaper, because a competent PM can now prototype ten variations in a week without a designer or an engineer. The net effect is that the cost of learning has fallen faster than the cost of earning, meaning teams that don’t lean into build-to-learn are leaving more value on the table than ever before.

If I’m a PM at a feature factory, what do I actually do first?

Pick one feature on your current roadmap and ask a quiet question: what risk is this addressing? If the honest answer is “a stakeholder asked for it,” you are building to earn something you have not built to learn. Before writing the spec, spend a week prototyping to test the underlying assumption. One prototype, five customers, one decision. That’s your wedge into a better operating mode. You don’t need permission to do discovery on a single feature.

What does “testing” mean in each mode?

They are completely different jobs. In build-to-learn, testing means is this idea real? You’re testing for value with users, usability with users, feasibility with engineers, and viability with your business. In build-to-earn, testing means does this work as promised? scale, performance, reliability, security, accuracy. Same word, different work. Don’t run them on the same clock.

Where do I read more on the Product Onion?

Start with the canonical post: The Product Onion Framework: Why Most Businesses Build From the Outside In (And Why That’s Backward). From there, the series walks through how we’ve applied it at Trevean Spice, Trevean Living, and even to my own home operating system.

This post is part of an ongoing series on The Product Manager’s Journal, where I write about PM frameworks that come from actually building things, not just theorizing about them. The Product Onion and Build-to-Learn / Build-to-Earn are two of the five frameworks in my free Startup PM Toolkit. Grab your copy and hit reply to tell me which one you’re wrestling with this week.

Related Reading

In this series

Start here: The Product Onion Framework

More on The Product Onion Framework

Connect across pillars