There is a new version of an old stupid idea going around.
The old version came from engineers: "Build a great product and users will come." Product was everything. Distribution was almost beneath them. If the software was good enough, people would somehow find it, understand it, and pay for it.
Maybe that worked twenty years ago, when there were fewer software products and simply having one made you unusual. It does not work in a market where people can choose between fifty tools that do roughly the same thing.
Now the bias has flipped. Software is cheap to build because LLMs and coding agents can write it so quickly, so people on the distribution side say product does not matter anymore. Distribution is everything. Get attention, push the thing hard enough, and people will use it.
It is the same blatant bias, from a different person.
Heart or lungs?
Imagine I tell you that, for the next hour, I can stop either your heart or your lungs. You get to choose which one.
It is not much of a choice. Either way, you are dead.
Product and distribution work like that. A company needs both, and arguing about which one matters more is a false choice. A business needs three critical engines behind it:
- Acquisition: people discover and try the product.
- Retention: they keep using it.
- Referral: they tell other people about it.
Distribution will give you acquisition. A great product is what drives both retention and referrals.
Strong distribution can hide a bad product for a while. This is what makes the distribution-only view dangerous. You spend money, generate attention, and watch new users arrive. The graph moves, so it looks like something is working. You might even raise a ton of money from VCs with this. But if those users leave and tell nobody, how great of a business that is?
Eventually the signal catches up with you.
Cheap code is not a cheap product
People are mixing up two different things.
AI has created a huge supply of coding output, especially at the junior and intermediate level. Work that used to take a developer several days can now come out of an agent in an hour. When the supply of a skill rises that quickly, the market value of that skill falls. I do think junior and intermediate software execution is loosing value at crazy speed because there is suddenly so much more of it available.
That says nothing about the value of the product itself.
If refrigerators became one hundred times easier to manufacture tomorrow, the skill of assembling a refrigerator would become less scarce. A refrigerator that keeps food cold would still be useful. We should not confuse the cost of making the thing with the value of the thing once it exists.
I would go further. Product judgment becomes more important when building gets cheap.
I remember planning sprints and sizing tiny API integrations. Someone would say the work was three man-days, or person-days, or whatever sizing approach you used (I remember engineers using t-shirt sizes, never really got it!). Then we would debate whether the integration was worth doing.
Now I can record a two-minute voice note, give it to an agent, and go do something else. The feature may be built before the old sizing meeting would have ended. We do not ask whether we should build it because building it feels almost free.
That is how you end up with more software and worse products.
The best products hide the mess
Most great products are complex behind the scenes and simple on the surface. The complexity is often part of the barrier to entry. The product absorbs it so the user does not have to.
Stripe is the obvious example. Payments are a mess. Banks, card networks, currencies, fraud, compliance, retries, disputes, payouts, and a long list of other things sit behind a payment. Stripe's original magic was that a developer could add a few lines of code and make that mess disappear.
That is what a good product does. It compresses a hard problem into a simple experience.
Now imagine building Stripe by vibe coding. Every time you notice a possible edge case, you ask an agent to add another setting, another tab, another workflow, another button. It can do all of that for you. Very quickly. Six months later the product may be so complicated that using it is harder than building your own payment processing logic yourself.
This is the odd thing about product work. A lot of the value comes from removal. The final experience is good because someone decided which parts the user should never have to see.
AI makes addition cheap. It does not make removal automatic.
AI wants to add
The first dangerous tendency I see with LLMs is that they almost always want to add something.
AI is always ready to add one more feature.
They are trained to be helpful. In a chat box, helpful usually means producing an answer, a plan, some code, or a new option. Output tokens are also the expensive part of an API call (typically 4-5x more expensive than input tokens), which makes the whole setup slightly funny. Think about this for a minute: it is incentivized to charge you more on the output than the input you give it. How bad could this get? We have built a colleague whose default behavior is to talk and produce more work.
I would often prefer the quiet colleague who looks at the idea and says, "No. We do not need this."
You can prompt a model to remove things. You can ask it to simplify. But you have to push it in that direction because its natural response to a request is to satisfy the request. Ask it for a feature and it gives you a feature. It rarely stops first and asks whether the product would be better without it.
When code was expensive, cost forced some discipline. A feature that took three weeks had to survive a real argument. When it takes three minutes, that filter disappears. The ability to build anything creates a new job: deciding what not to build.
AI wants a compromise
The second tendency may be worse for product decisions.
When I brainstorm four or five solutions with an LLM and then ask it to help me pick one, it often produces a polite mixture of all five. Take the speed of option A, the flexibility of option B, the safety of option C, and add a little bit of option D in phase two.
In other words, build a Frankenstein.
It treats product decisions like a vinaigrette. Add a little of everything, shake vigorously.
A little bit of everything. The best of nothing.
Compromise is useful when you are optimizing for social cohesion. If six friends are booking a hotel together, you probably should find something that nobody hates. The objective is not to identify the objectively best hotel. The objective is to go on holiday without destroying the group chat.
Product decisions are different. You are not trying to protect the ego of everyone who suggested an option. You are trying to solve a user's problem. Making each internal person twenty percent happy can easily produce a solution that makes the user zero percent happy.
Jeff Bezos gave a good example of this on the Lex Fridman podcast. If he says a ceiling is eleven feet high and Lex says it is twelve, calling it eleven and a half is easy. It is also wrong. The right answer is to get a measuring tape. Compromise takes less energy, but it does not get you closer to the truth.
Sometimes there is no measuring tape for a product decision. You listen to the arguments, make a call, and disagree and commit. What you should not do is merge every idea into one solution because no one wanted to choose.
There is an important distinction here. You can compromise on constraints. You should avoid compromising on the solution.
Say you are choosing between latency, cost, and performance. You may decide that cost can be a little worse because latency matters most for this product. Fine. You accepted a tradeoff in the constraints, and now you can choose the solution that fits it. That is different from combining options A, B, C, and D until the result has every weakness and no clear strength.
LLMs are very good at generating options. I use them for that all the time. But choosing means rejecting, and rejection is where product judgment lives.
What got cheaper
The easier it gets to build, the easier it gets to build the wrong product, add the wrong feature, and keep every possible option alive. Distribution can put that product in front of people, but it cannot make them stay. It definitely cannot make them recommend it.
So yes, distribution matters. It always did. Product still matters too.
I still catch myself doing the opposite of what I am arguing for. An agent makes a feature cheap, I get excited, and only later ask whether anyone needed it. That is the habit I am trying to break. We are all token addicts who need to sober up.
Maybe I should open a token detox center. No prompts, no agents, just the unbearable question: does anyone need this?
Written with ❤️ by a human (still)