April 16, 2026 | The Product Manager’s Journal
The Take
I pulled a dusty book off my shelf this week, and it told me exactly where product management is going.
The book is User Story Mapping by Jeff Patton. My copy has a coffee stain, a gnawed pen marking my place in chapter five, and a sticky note from a version of me who used to work on feature teams at HP (Compaq). I have no idea why I pulled it down. But I did. And I couldn’t put it back.
Patton coined a phrase over a decade ago that has become the single clearest diagnosis of what’s going wrong in product work right now: build to learn vs build to earn.
In discovery, you build to learn. The job is conviction, not revenue. Your prototypes are ugly, fast, and sometimes wrong on purpose because the only way to de-risk value, usability, feasibility, and viability is to put something crude in front of a real human and let reality push back. With modern AI tools, ten prototype iterations in a week is easy. That wasn’t true three years ago.
In delivery, you build to earn. The job is commercial quality scale, performance, reliability, security, operations, and the whole long list of things that let a customer run their business on top of what you shipped. That’s a different discipline, different risks, a different kind of “testing.”
Here is the trap most teams have fallen into, and AI has made it worse, not better: they build to earn something they never built to learn. They skip discovery. They let a stakeholder hand them a roadmap; they spec it, ship it beautifully, market it, sell it, and the thing that got built solves a problem nobody had. Polished outer layers. Rotten core. A feature factory with new tools.
Every PM I talk to right now is feeling this in some form. The work feels faster, but the outcomes aren’t better. Something’s off. That phrase is the off.
I wrote a full post this week on why Patton’s distinction is actually the missing verb in the Product Onion framework I’ve been writing about for two years. Short version: the Onion tells you what to build at each layer. Build-to-learn vs build-to-earn tells you how to build at each layer. Skip one and the whole thing collapses.
Pull your own dusty book off the shelf. Mine had the answer in it the whole time.
From the Trenches
The blog reached 80 published posts while I was in the air, and the email-capture infrastructure is now feeding subscribers into a working nurture flow. Small numbers still, but a few of you reading this came in through that flow, which is wild. Welcome. Hit reply whenever you want.
Rushi and I also sat down this week and decided what the next 15 NFC prototype iterations will test. We’re building to learn, deliberately, before we commit to the production pipeline. Which, it turns out, is exactly what this whole issue is about.
Spice Route Signal
Wearables are about to change what you eat. And what your spices do when they get there.
Over on the Spice Route Signal this week, we published a piece on the coming wearable-to-plate inflection point, the moment your ring, your patch, or your continuous glucose, whatever, starts telling your kitchen (and your spice drawer) which flavor profile your body actually needs right now. Not which diet plan. Which meal, tonight, tuned to your inflammation markers, your hydration, your sleep debt, your recovery state?
The spice implication is the part I can’t stop thinking about. Spices are not just for flavor. They are bioactive. Turmeric, cumin, cinnamon, oregano — each one interacts with your body in measurable ways. If the wearable layer knows what your body needs, and the kitchen layer knows how to deliver it, the spice blend stops being “what you like” and starts being “what you need.” Personalized at the biochemical level.
This sounds far off. It isn’t. The sensor side is already here. The food side is the bottleneck. And for the first time, the bottleneck is not technology — it’s trust. You don’t tailor what goes in your body based on data from a supply chain you can’t verify. Which is why NFC provenance, farmer-level sourcing, and freshness signals go from “nice story” to “necessary infrastructure” the moment wearables pick up this thread.
We’re early. But not that early.
→ Read the full wearable-to-plate piece on the Spice Route Signal.
From The Rack
An article I could not stop reading this week.
Study Reveals Consuming Herbs and Spices Together Amplifies Their Benefits — NaturalNews, April 15, 2026.
The headline sounds obvious. The data underneath is not. The study found that individual spices, measured in isolation, show modest health effects. But when you combine them in culturally traditional ratios (the kinds of ratios that show up in actual blends from actual regions), the bioactive effect isn’t additive. It’s multiplicative. Curcumin plus black pepper is the famous example, but the study expanded that into families: a warm-spice cluster, a resinous cluster, a floral-aromatic cluster, each with amplification patterns that single-ingredient research misses entirely.
Why I’m flagging this: it’s a scientific validation of something every traditional cuisine has known for three thousand years. The blend is the unit. Not the spice. A jar of cumin on its own is an ingredient. A blend assembled with intent is a functional food.
Which, not coincidentally, is exactly how Trevean thinks about Kyoto Garden, Persian Sunrise, North African Night Market, Caribbean Sunset, and The Silk Road. Each one is not a mix. Each one is an amplification pattern.
I’ll say the obvious thing: this study is worth reading if you’re building anything in the food space, and especially anything in the “functional” food space. The frame “blends amplify” is going to show up in a lot of marketing copy over the next eighteen months. Most of it will be lying. The real version is in the ratios, the provenance, and the freshness.
Framework Flash: Build to Learn vs Build to Earn
Jeff Patton gave us the verb. The Product Onion gives it a home.
The Product Onion is a sequence: Core Problem → Domain Logic → Features → Experience → Marketing → Sales. Inside out. Each layer earns its right to exist because of the layer beneath it.
Here’s what I didn’t make explicit in the original framework: the inner layers and the outer layers require different modes of building.
Inner layers → Build to Learn. Core problem and domain logic are not engineering work. They’re at risk. Value, usability, feasibility, viability. The output of a week spent here is not a feature. It’s a conviction that you’re solving the right problem in the right way. Prototypes. Interviews. Fast, ugly, disposable. Ten per week is easy now.
Outer layers → Build to Earn. Features, experience, marketing, sales. This is where you commit. Commercial quality. Scale, performance, reliability, security, ops, support. You earn revenue here, but only because you already earned conviction inside.
The feature factory is what happens when teams build to earn the outer layers without ever building to learn the inner ones. Polished thing that solves nothing. AI just made that trap cheaper to fall into.
→ Read the full post: Build to Learn, Build to Earn: The Verb the Product Onion Was Missing
The Toolkit
This week’s pick: *User Story Mapping* by Jeff Patton.
Yes, the book I started this issue with. I went into it expecting dated frameworks and came out highlighting half of chapter four. Patton’s core argument that the goal of product work is to discover the whole story before you build any of it holds up better in 2026 than it did when the book came out in 2014. If anything, AI has made the argument more urgent, not less.
It’s the book that gave us “build to learn vs build to earn.” That alone is worth the cover price. But the story mapping technique itself, turning a flat backlog into a narrative spine with a horizontal “what users do” axis and a vertical “what we’ll build first” axis, is still the cleanest way I’ve found to align a product team on an MVP that actually means minimum viable, not “half the thing, badly.”
Pick it up. If you already own it and it’s on your shelf, dust it off. You may be surprised by how much it has to say to the version of you doing product work right now.
That’s the Rack
Thanks for reading Issue #4. I’m Dan Blizinski, founder of Trevean Spice and the person behind The Product Manager’s Journal, where I write about PM frameworks that come from actually building things, not just theorizing about them.
New here? Grab the free Startup PM Toolkit, five frameworks I actually use at Trevean, including the Product Onion and build-to-learn/build-to-earn.
What’s one thing you’re wrestling with this week? Hit reply. I read each one.
The PM’s Spice Rack is published weekly on The Product Manager’s Journal and on LinkedIn. Subscribe to get it in your inbox.