last month i shipped a feature in regent that contradicted three blog posts i'd read about "best practices". it works. it's one of the most quietly important decisions in the product. and it's the kind of bet i would never have taken two years ago.
this is about that part. the non-obvious 20%. the bets that only work because the boring 80% is already in place. and the strange skill of knowing when to break your own rules.
what the 20% actually is
the 20% isn't "more features". it isn't a new framework. it isn't refactoring everything to microservices because conway's law.
the 20% is:
- the feature your competitor would never ship because it doesn't fit a roadmap template
- the technical decision that violates a "best practice" but solves your users' actual problem
- the architectural choice that makes one workflow 10x faster at the cost of another being 2x slower (when you know which one matters)
- the ux detail that nobody asks for but everyone notices
- the radical simplification that requires deleting code you spent two weeks on
it's not magic. it's compounded judgment. and it's almost never the result of a brainstorm.
the wild bet i'm proudest of
in regent, every incoming email goes through a router that picks one of two model tiers: a local ollama instance running qwen3 or gemma3 for the easy stuff, and gemini for the hard stuff. the router decides per-email, in real time, based on a quick heuristic on the content.
this violates a few pieces of common ai-product wisdom. you're supposed to standardize on the best available model and let it handle everything. you're supposed to keep model serving in the cloud so latency is consistent. you're supposed to avoid the operational complexity of self-hosting llms.
i shipped it anyway because the math was undeniable. most inbox volume is short, repetitive, and doesn't need a frontier model. running all of it through gemini was costing more than a user's subscription brought in. running the easy stuff locally on ollama costs basically nothing. the emails that actually need reasoning still get gemini, with a circuit breaker that flips traffic back if local latency or quality drops.
the result: gross margins flipped from negative to comfortable in one weekend. and users can't tell the difference, because the router only sends "easy" emails to the smaller model.
that decision is the kind of bet you can only make when:
- you actually know your traffic patterns (not guesses, real distributions you've measured)
- the rest of the system is solid enough that you can change routing logic behind a flag and roll back in a minute
- you've earned the right to override "use the best model" by being right about smaller things first
the prerequisites for the 20%
here's the part i wish someone had told me earlier. the 20% isn't a personality trait. it isn't "being creative". it's a privilege you earn by doing the boring work first.
you can take a wild bet when:
- rollback is cheap: you can ship it behind a flag and turn it off in 30 seconds
- the blast radius is bounded: the worst case is "this feature is bad", not "the database is corrupt"
- you have evidence, not opinions: you've seen real users hit a real wall, not a slack channel guessing what users might want
- the alternative is tested: you know the boring version works because you've already tried it
if any of those four are missing, you're not betting. you're gambling. the difference is whether you can survive being wrong.
the wrong 20%
i've shipped some bad 20% bets. the pattern is always the same: i was scratching my own technical itch and calling it a product decision.
the warning signs are easy to recognize in hindsight:
- "users will probably want this" instead of "three users asked for this"
- "this is more elegant" instead of "this is faster for the user"
- "this lets us scale" instead of "this fixes a problem we have today"
- "wouldn't it be cool if..." (the deadliest of all)
each of those is a red flag. each of them is the engineer prioritizing what's interesting to build over what's useful to ship. the 20% isn't "things you find cool". it's "things your users would describe as obviously needed once they exist, and obviously missing today".
the test i now use: can i name three real users who said something that led directly to this feature? not "users would probably want this". not "this feels right". three names. three quotes. if i can't, i don't ship it.
taste is a learned skill
here's the uncomfortable thing: the 20% isn't democratic. some people are better at it than others. it looks like talent but it isn't. it's pattern matching from thousands of small decisions you've watched succeed or fail.
i'm still building mine. my pattern matching is better in backend systems than frontend ux because i've shipped more of the former. it's better in ai pipelines than growth experiments because i've debugged more of the former. taste is domain-specific and you only get it by paying attention to outcomes.
the way to develop it is brutal but simple: ship things, watch what happens, and be honest about why. don't blame the launch. don't blame the marketing. don't blame the timing. ask: did this actually solve the problem i thought it would? if not, what was i wrong about?
most engineers stop here. they ship, the metric moves or doesn't, they move on. the engineers who develop taste write the why down. literally a one-line note in a doc somewhere: "shipped X. expected Y. got Z. lesson was Q." after a hundred of those, you start to see patterns. after five hundred, you have intuition.
when to take the bet
i don't have a clean rule for this. but here's the closest thing i've found.
take the bet when:
- you've heard the same complaint from three different users in a week
- the obvious solution exists and everyone is shipping it
- the obvious solution doesn't actually solve the problem (it just makes you look productive)
- you have a hunch about why the obvious solution doesn't work
- the cost of testing your hunch is small compared to the cost of being wrong about the obvious one
skip the bet when:
- it's only your idea and nobody else can articulate the need
- you can't say what you'd learn if it failed
- you'd be ashamed to roll it back
- it requires a permanent architectural change just to test
- it would feel personally bad to throw away
that last one is the most important. if you can't kill the feature without ego getting in the way, you're not making an engineering decision anymore. you're protecting a piece of yourself, and that's how dead code lives in production for years.
the 20% in non-glamorous places
people associate the 20% with consumer features and slick ux. but the wildest bets i've made are in places no one sees:
- a database write pattern that violates normal form because reads were 100x more common than writes (and the duplication was tiny)
- a queue worker that processes items out of order because the natural order created hot keys (and out-of-order was actually fine for the use case)
- a typed config system that lets non-engineers change ai routing rules in a yaml file (so the engineers stopped being a bottleneck for ml experiments)
none of those will ever be in a launch announcement. all of them changed the product more than any new feature i shipped that quarter. the 20% lives in places nobody thinks to look.
the loop
the boring 80% earns you the 20%. the 20% pays back the 80%. the bets you take with confidence today become the foundations you take for granted tomorrow.
the cycle is the whole game. the discipline of the 80% lets you take risks. the risks teach you what to put in the next foundation. the next foundation lets you take bigger risks. eventually you're working on problems your competitors don't even see yet, because you've earned a vantage point they haven't.
that's the actual reward. not awards. not recognition. the slow, accumulating ability to see further than the people around you, because you've been paying attention to the right things for longer than they have.
the boring 80% is the price. the wild 20% is what you spend it on.