Code Is Not the Outcome, Learning Is - by Pawel Brodzinski
SubscribeSign in
Code Is Not the Outcome, Learning Is<br>There's a build-learn trade-off. We can't optimize for both. For early-stage startups, the choice should be a no-brainer.
Pawel Brodzinski<br>Aug 12, 2026
Share
At Lunar, we’ve helped build some 200 digital products. None was a slam dunk. There was no “we shipped it, and it went wild.” Hell, I’d have settled for “it performed as intended.”<br>Nope. Not one.<br>There’s a neat explanation coming from a recent podcast with Eric Ries of Lean Startup fame. Aside from some promotion of his new book, which I guess was the point of the interview, he got asked how Lean Startup fares in the AI era.<br>The centerpiece of his answer is something that I think still few companies claiming to be lean startups (or Lean Startups) get.<br>Learning is where the value is. Not the artifact.
In other words, the point of building an MVP is not the MVP. It’s everything we learn on the way.
Subscribe
Building a Product Is Never a Home Run
As in the Anna Karenina principle (”All happy families are alike”), all the products we helped build that eventually succeeded share the path. It was a long haul of changes, adjustments, discovery, and exploration to eventually find the right ingredients that clicked. And after that whole effort, “clicked” still doesn’t mean getting to millions in Annual Recurring Revenue (or whatever placeholder we now use instead) in months.<br>If we boiled it down to one meta pattern, it was optimizing for learning. My old mantra all over again:<br>Try stuff. See what works. Stick with what does. Drop what does not .
We don’t know up front what might work. We can’t know it. It’s unknown and—more importantly—unknowable. If the odds of a home run are but a fraction of a percentage point, what actually constitutes an MVP doesn’t matter at all. What matters is whether we improve our understanding of our surroundings and set ourselves in a better position for another swing.<br>Learning. Again.<br>In the Complex Domain Recipes Don’t Work
Cynefin offers a neat explanation why there are no home runs in the startup world. Here’s one of the filters that helps to figure out whether we’re in a complicated or complex domain.
If good solutions to a problem exist and we can scrutinize the problem enough to pick the right one, we are in the complicated domain. We can analyze our way through the issue.<br>If, on the other hand, we can’t possibly know the course of action unless we start probing the environment around us, we are in the complex domain. We can only play the sense-and-respond game here as we learn the novel environment. There are no recipes that can reliably work in this land.<br>So where do early-stage startups live? It’s the complex domain all the way. If they were complicated, we would be able to devise a path to success up front. Somehow, I’m not seeing these bulletproof plans turning into anything but a pipe dream. And, believe me, I’ve seen a lot of ‘em plans.<br>Again, we can’t know what to build from the outset. It’s not building pace that is the constraint. It’s the learning pace.<br>More Swings, More Hits, Right?
“But Pawel, we build 10x faster now. That’s 10x the attempts and 10x the learning!”<br>Um, it’s not 10x. Faros crunched the numbers, and the productivity gain is way below 2x. Packaged with deteriorating quality. If there is a more impressive change somewhere, it’s the size of a task. I looked at Lunar data, and the average PR might be more than 3x as big as it used to be. Packaged with deteriorating quality. Different data. Different metric. Same outcome. Coincidence?<br>Coding musings aside, we talk about two fundamentally different activities. Think of it as a difference between shooting as fast as you possibly can versus practicing to improve your technique. It’s not the attempts that count. It’s whether you score. And you don’t see teams trying to shoot the second they get the ball. One has to wonder why. They’d literally 10x their volume, wouldn’t they?<br>By the same token, getting another MVP or feature out the door at breakneck speed does virtually nothing to improve a startup’s odds.<br>Fine, say you can 2x the build speed. You can’t double the traffic by sheer willpower, though. You can’t summon twice as many customers willing to run interviews. Most importantly, you can’t extend anyone’s attention limit . It is the hard constraint.<br>But you sure can overwhelm said attention with the new feature overload. Break a leg.<br>The Learning Cycles
One of the useful things introduced by Lean Startup is the Build-Measure-Learn cycle. The gist of it is that you go in rounds. First, you build something. Then, you measure its impact against the expected results. Finally, you draw conclusions that inform the next iteration. Repeat. Over and over and over again.<br>While Eric Ries explicitly labels one part “learning,” the meta concept is anything but new. In the 70s, John Boyd introduced the Observe-Orient-Decide-Act loop,...