Most software sucks because we won't do boring work
Why quality emerges at iteration 300, not 30—and other lessons from obsessive craft
"Where the fuck did you pull that analogy from? Oh wait, why are you testing out a video editing platform - are you about to launch a video podcast?"
My colleague caught me red-handed last week, deep in the interface of some new video tool I'd never use professionally. No podcast planned. No video content strategy. Just... testing.
It's a weird habit I've developed over the years. If something looks well-made, well-marketed, I'll give it a test drive. Consume it. Learn from it. Most founders think this is a waste of time. They're wrong, and Jiro Ono proves why.
Jiro Dreams of Sushi has become required viewing for founders. The Founders podcast did a great analysis hitting all the obvious lessons - obsession with perfection, supply chain control, decades of deliberate practice. Essential insights, but they're just scratching the surface. Studying Jiro through a product management lens - having made hundreds of product decisions and watched tech companies fumble basic disciplines for years - I found five deeper principles hiding in plain sight. The stuff that actually explains why most products suck and most startups fail. These aren't the feel-good lessons about passion and persistence. They're the uncomfortable truths about discipline that everyone sees but no one wants to implement.
⏱️ If you only have 5 minutes: here are the key points
Quality emerges through volume and discipline: Like Jiro's apprentices making hundreds of egg sushis, product excellence only surfaces after hundreds of iterations—not the first 10 or 20.
Taste is developed, not innate: Founders must obsessively consume great products in their space to develop the discernment needed to build great ones.
Environmental discipline sharpens cognitive performance: Clean, optimized workspaces reduce friction and boost decision quality—mirroring Jiro’s surgical precision.
Mastery comes from constraint, not variety: Founders who jump between roles rarely build deep competence; real breakthroughs come from focused, long-term practice in one domain.
The gap isn’t knowledge—it’s discipline: Most teams know best practices (TDD, continuous delivery, etc.) but fail to apply them consistently. Jiro’s excellence proves that rigorous repetition of well-known methods creates irreplicable results.
Reps 300-500 are where quality emerges
I've processed over 300 product ideas in the last 10 months, making that an average of 30 each month. I know because I keep very close track. It’s been the pace I’ve been operating since I started out in product management 6 years ago. When I started out as PM, I started doing Peter Drucker's decision analysis framework - tracking what I decided, why, and how it turned out.
Here's what surprised me: The learning curve wasn't between decisions 1-10, or even 10-100. The real shift happened between decisions 50-300, then again from 300-500. That's when patterns emerged. When intuition developed. When the frameworks I use now started looking "starkly different" from those first two years of fumbling around.
Everyone loves the startup advice: "Ship your first feature quick because it'll suck anyway." True, but incomplete. That advice optimizes for getting to iteration 20 fast. The magic happens at iteration 300.
Jiro's apprentice made over 200 egg sushis before one passed. Egg sushis are among the mos basic one can make. It took months. But the real insight isn't the rejection count - it's what volume creates. After decades of daily experimentation, Jiro developed pattern recognition that seems supernatural. He can assess fish quality by touch in seconds, detect temperature variations that would escape others, spot quality problems before they manifest.
This wasn't repetition - it was systematic experimentation within constraints. What happens if we massage octopus for 40 minutes instead of 30? What if we boil shrimp when the customer arrives instead of storing it cold?
"I do the same thing over and over, improving bit by bit," he says. But watch carefully - he's not doing the same thing. He's running controlled experiments within a disciplined framework. The routine provides the control group. The daily adjustments provide the variables.
"There is always a yearning to achieve more. I'll continue to climb trying to reach the top, but no one knows where the top is." At 85, he's still experimenting. Still finding new variables to test.
Volume doesn't create perfection - it creates the ability to recognize micro-improvements that others miss.
Most founders give up before reaching the quality zone. They pivot after 50 iterations instead of pushing to 500. They optimize for shipping features 1-20 quickly, but the breakthrough insights come from the disciplined work of iterations 200-500. That's when you stop making beginner mistakes and start seeing patterns others can't.
But all those iterations mean nothing without the ability to recognize what's actually better...
Consume to create
Back to that video editing platform. I wasn't being scattered or unfocused. I was doing what Jiro calls essential: developing taste. I consume great products constantly. If it looks well-made, I'll test drive it. Email tools, design software, AI platforms, project management apps - doesn't matter if they're in my space. I'm developing my ability to recognize quality, studying how great products feel, understanding what makes interfaces sing.
This directly contradicts the "disruption from outsiders" narrative that VCs love to push. You know what you get when outsiders build products in categories they don't consume? BI tools built by people who've never used BI tools. AI products by people who don't actually use AI. The result? Products that technically work but feel wrong to actual users.
"In order to make delicious food, you must eat delicious food," Jiro says. "Without good taste, you cannot make good food." But here's what most miss: Jiro's taste wasn't innate - it was systematically developed through decades of deliberate comparison.
His tuna dealer explains how he teaches Jiro to recognize quality levels most people can't detect. His rice supplier describes how they worked together to understand the relationship between pressure, temperature, and texture. Each supplier relationship was essentially a masterclass in their specialty.
Jiro admires Joel Robuchon: "If I had his tongue and nose, I could probably make better food." He's describing taste as a learnable skill that requires constant exposure to excellence. At 85, he's still actively developing his palate, still learning from suppliers who've spent their lives perfecting single ingredients.
Watch how this plays out: Jiro's early sushi was competent but unremarkable. His breakthrough innovations - serving sushi at body temperature, the specific rice pressure technique, the timing protocols - came from understanding quality at a level his competitors couldn't reach.
Superior taste enabled superior innovation.
The pattern is everywhere in tech: companies hiring brilliant engineers to build products for users whose problems they've never experienced. Engineering teams building dashboards they'll never look at. Product managers designing workflows they'll never run. It's like asking someone who's never eaten sushi to design a sushi restaurant.
You cannot build great products in categories you don't deeply consume. Your lack of taste will show up in every design decision, every feature priority, every user interaction.
Developing taste requires the right conditions. Which brings us to something everyone misses about Jiro's workspace...
Environment discipline drives product discipline
First thing every morning, before coffee, before checking messages, I clean my whiteboards. All of them. Even the ones I won't use that day. If I don't do that, things feel cluttered. It's not about actually using them, but having them clean simply means I'll take care with the next thing I tackle - which is planning the day.
It's not about the whiteboards. It's about cognitive load and decision amplification. A clean environment eliminates micro-decisions and mental friction, freeing cognitive resources for creative work.
Jiro figured this out decades ago. His restaurant is described as "possibly the cleanest restaurant in the world," but watch what this enables: lightning-fast decision-making during service. No hunting for tools. No cognitive load from visual clutter. No decision fatigue from environmental chaos.
"If the restaurant doesn't feel clean, the food isn't going to taste good," he says. His knife sharpening isn't just maintenance - it's environmental optimization. Sharp tools reduce effort and increase precision. Clean surfaces reduce contamination risk and increase speed.
Your environment shapes your standards in real-time. If you tolerate low standards in your workspace, you'll tolerate them in your product. Jiro's immaculate workspace isn't separate from his perfect sushi. It's the same discipline creating conditions for excellence.
This environmental discipline isn't separate from career strategy - it's how you build lasting competence...
Core competence vs. role hopping
In my career, I've jumped between seemingly different functions: internal product manager for 700 users, Head of Marketing at a Valley startup, Head of Product at an AI company. Thing is, for me those roles aren't different at all. They're all extensions of what I've been doing since I started: building a core competence in making great decisions under uncertainty in tech-related fields.
It started with poker when I was young, moved to foreign exchange trading, then founding a BI startup, and now all of this. Every role has been practice in the same fundamental skill set. I'm not chasing titles or trends - I'm applying one deep competence across different domains.
I already wrote about how I do product for MAIA and I think that resonates here well - we're focusing on building up core competencies, not chasing features and fads.
Most founders do the opposite. They chase roles, trends, and opportunities without building deep expertise in anything. Product manager to founder to investor to consultant - always moving before mastering.
Jiro understood this at nine years old when his father kicked him out. "I knew that I was on my own and I didn't want to sleep under a bridge. So I had to work just to survive. That has never left me." He realized early that competence was the only safe harbor.
But here's what most miss about Jiro's focus: his innovations came FROM constraints, not despite them. By committing to sushi exclusively for 75 years, he could experiment at a depth generalists never reach. His breakthrough techniques - the rice pressure method, the body temperature serving protocol, the timing precision - required decades of focused experimentation.
When asked about his creative process, Jiro explains how innovations emerge from systematic exploration within bounds: "I would make sushi in my dreams. I would jump out of bed at night with ideas." But these weren't random inspirations - they were solutions to problems only someone with his depth of experience would recognize.
When Jiro told his sons "you have no home to come back to," he was forcing the same choice that saved him: develop genuine competence or fail.
"A great sushi chef will never go hungry." While everyone else chases the next opportunity, Jiro doubled down on one thing and became irreplaceable. Not because he was lucky or had connections, but because he built competence that couldn't be commoditized.
In an uncertain world, being genuinely the best at something core is the only real moat. Not network effects, not first-mover advantage - competence.
Individual competence is just the beginning. The same discipline applies to how teams work...
The software product practices gap
I've been evangelizing software product practices for years. Infrastructure as Code. Test Driven Development. Continuous Delivery. Chaos Engineering. Trunk-based development. Documentation-driven development. Product discovery frameworks. User research methodologies.
Here's what's fascinating: companies like ThoughtWorks spend enormous effort developing and curating these cutting-edge tools and practices. The knowledge exists. The frameworks are documented. The benefits are proven.
And yet, it's almost impossible to find a single company that actually uses even a significant subset of them.
Can you name ONE company doing trunk-based development + continuous delivery + chaos engineering + TDD? I can't. And I've worked with dozens of tech companies and founders. Most do maybe 2 out of 5 of the known best practices.
Jiro explains why: "The techniques we use, they're not a big secret. You can see what we're doing. It's just about making an effort and repeating the same thing every day." The gap isn't knowledge - it's discipline.
Take documentation. An essential part of any software product, and yet the best framework for creating documentation, something called diataxis is almost never applied. And yet, I can safely say, the meltano docs became substantially more helpful after changing to that framework, and so did the MAIA docs.
Jiro's techniques aren't proprietary. Other chefs can observe his methods. The rice preparation, the fish handling, the timing protocols - it's all visible. "Shokunin tried to get the highest quality fish and apply their technique to it. All I want to do is make better sushi."
Yet no one else achieves his results. His suppliers explain why: "Most people want an easy job, lots of free time, and lots of money, but they aren't thinking of building their skills."
Even luxury hotels can't replicate his rice preparation. His supplier explains: "Even if I wanted to sell them the same rice, they wouldn't know what to do with it because only Jiro knows how to cook it." The techniques are observable, but the disciplined application creates an unbridgeable gap.
Most tech teams know they should write tests first. They know they should deploy continuously. They know they should document decisions. They just won't do the disciplined work required.
Instead, they'll spend weeks evaluating new frameworks, debating architecture patterns, and optimizing for developer experience. Anything except the boring work of applying known best practices consistently.
This is why most software sucks. Not because we don't know how to build great software - we absolutely do. The practices exist, are documented, are proven. Companies just won't commit to the discipline required.
Here's the test: audit your practices right now. How many of the known best practices are you actually implementing? Be honest. The gap between your answer and "all of them" explains why your software doesn't feel like Jiro's sushi.
Then go ahead and tell me about the results of your audit!