Most product advice comes from people who have always had enough. Enough engineers, enough runway, enough time to A/B test their way to conviction. Almost everything written about building products assumes the bottleneck is insight. Talk to enough users, run enough experiments, write good enough specs, and a good product falls out the end.
That holds when the infrastructure already exists, the market is established, and a miss costs you a quarter instead of the company. It also breeds a particular blindness. You start substituting process for judgment, reaching for a framework when the answer should come from the ground up.
I built Kabba Transport in Addis Ababa with none of those safety nets. No VC runway to buy 18 months of figuring it out. No playbook for mass transit technology in that market. No room to ship rough and iterate, because in a city of five million commuters with no reliable transit, a platform that fails on day one never gets day two. The constraints were total. They clarified everything.
"Wealth is the slave of a wise man, the master of a fool." Seneca said that about money. It runs just as true for resources in product.
Optionality Is a Drug
Nassim Taleb made the case for optionality as a virtue, the value of keeping future choices open. He is right about finance and about careers. In product development, unlimited optionality is quietly catastrophic.
When you can always run one more test, ship one more iteration, bolt on one more feature to see what sticks, you never build the harder muscle of knowing in advance what is worth building. You outsource judgment to data. Data gathered at scale in an established market mostly confirms what you already suspected. It rarely shows you what you did not know to look for.
Constraints force a sharper question. The well-funded team asks what to test next. The constrained team asks what has to be true for this to work at all, what the system actually requires before a line of code gets written. That is a harder question. Answering it means understanding the problem at a depth most teams swimming in resources never reach. It takes skin in the game.
Skin in the Game
Skin in the game, Taleb's idea that the people making decisions should carry the consequences, usually gets discussed in finance. It applies straight to product work. Most product organizations are built to avoid it.
A PM at a big company who ships a dud gets a learning opportunity. A founder in a constrained market who ships the wrong thing gets an ending. That gap in consequence changes the quality of the thinking. The founder is not smarter. The founder screens ideas harder before they ever turn into work.
When I had to decide whether to require upfront payment from commuters, a move that cut against every freemium instinct, I could not afford to be wrong. That changed how I reasoned. I stopped asking what most users would prefer. I asked what the system needed from users in order to function at all. Those are different questions. The second one led to the right answer.
Via Negativa
There is an old principle called via negativa. You define a thing more reliably by what it is not. Taleb pointed it at decisions: to improve a situation, remove rather than add. Most hard problems get solved by subtraction.
Building under constraint is via negativa applied by force. When you cannot build everything, you learn fast what actually matters. The features that survive the squeeze are the ones with real utility. The rest turns out to be noise you had been calling signal.
At Kabba we could not build the full platform, so we built the operations dashboard before the consumer app. Financial reconciliation was the single highest-friction point in the whole system, invisible from outside and fatal from within. In a flush environment that call gets buried under a roadmap of shinier consumer features that are easier to demo and easier to sell to stakeholders. The constraint dragged it into the light.
The Paradox of More
Naval Ravikant has a clean frame for leverage. The biggest returns in life come from compound interest, in relationships, knowledge, and skill. Early choices about where to focus compound over time. So the true cost of unfocused early work is every stretch of compounding it never let you start.
More resources often compound less, because they permit and quietly reward unfocused work. Teams ship more features. More features mean more surface to maintain. Maintenance eats the bandwidth that should fund the next real improvement. The product widens faster than it deepens. Users get more to learn and less reason to stay.
Constrained teams cannot afford that, so they compound better. Every decision to build one thing is a decision not to build ten others. Hold that discipline long enough and you get a product that stays easy to understand and easy to love.
What This Actually Changes
I am not telling you to starve your team. Resources matter. Strong engineers, real time for discovery, bandwidth to instrument and measure, none of that is a luxury. The lesson is not to embrace deprivation.
The lesson is that constraints are information. When they do not show up on their own, manufacture them. Set the deadline before you know how long the work will take. Cap the scope before you know everything you want in it. Force the prioritization fight before you feel ready for it. The discomfort of a manufactured constraint is the discomfort of building judgment, and judgment is the one thing that does not rot when the resources finally arrive.
The product managers I have watched compound over the years are not the ones with the best tooling or the biggest teams. They are the ones who built real conviction about what matters, usually during a stretch when they had to decide without the safety net of testing everything first.
Constraints are a teacher that abundance never quite replaces. The lucky ones learn that early.