AI made building free. So why is the whole conversation still about how to build?
A few weeks ago I sat on a call with a company that had spent two and a half years and four design iterations building and re-building a product. About forty minutes in, one of their engineers chimed in and echoed a mantra I’ve said many times and one that plenty of people smarter than me have shouted for decades because its the most important mantra in the world of creating products: just because you can build something doesn’t mean you should.
But he kept going and the part that stuck with me was what had actually gone wrong.
A startup used to get one real shot at an idea, he said, because building was slow enough and expensive enough that your budget only paid for one go at it. AI had cut that cost so much that they’d taken multiple shots instead and many iterations later they were no closer to having a product anyone wanted.
They still could not tell me who they were building it for because building it wasn’t the bottleneck. The decision process was, and there unfortunately hadn’t been much in terms of decisions or process.
To be clear, these were not clumsy or ignorant people. The engineering was, in a lot of places, genuinely beautiful. They had a working voice interface, a slick web app, and a problem-solving engine running underneath it that was smarter than most things I’ve seen after several years in the AI space.
The same engineer used a biotech analogy to describe where they’d landed: they’d invented a molecule that might really cure something, and they had no manufacturing, no distribution, and no earthly idea who was sick. They could build anything. They had built almost everything, but none of it had touched a single customer who cared.
I’ve thought about that call ever since, because that company represents so much of the AI industry as it stands today. We have made building products nearly free, and we have spent all our energy getting even better at it, while the one thing that actually decides whether a product succeeds, why it deserves to exist and for whom, gets almost none of the conversation.
That work has a name. It’s strategy, and it’s supposed to be our job. Product exists to decide what’s worth building.
Roman Pichler frames the core of it as a handful of choices that sit above everything else: who the product is for, and why anyone would want it. Somewhere along the way, those questions just stopped getting asked. Not by us, not by anyone.
Everyone Is Solving the Wrong Problem
Open any design publication this month, and you’ll find the same conversation dressed up in more costumes than Taylor Swift’s Eras Tour.
Some people say the role of design just leveled up. Lisa Demchenko has a sharp piece on the product designer becoming a system architect instead of a spec maker, and she’s right about the shape of the shift. Taste is the last thing AI can’t touch. Andrea Grigsby made that case cleanly, and I’ve made a version of it myself.
We need standards, real ones, to survive this moment. Patrick Neeman put together a good playbook arguing that the web-standards fight that ended the browser wars is the exact playbook for this AI moment, won by building a coalition to agree on how we could remove the incredible frustration we dealt with in dot-com 1.0. Neeman is a standards guy to his bones and when he tells you to take the work seriously, listen. He’s usually right.
The pattern coming out of these arguments, and as designers we love a pattern, is impossible to miss. Every piece is about how we build. The role, the craft, the taste, the standards, the system.
We have gotten incredibly good at making sophisticated, high-minded arguments about the quality of the work, but we suck at asking whether the work should exist at all.
Here is the thing we keep forgetting. There is an opponent in this fight, and it is not designers, developers, or anyone involved in our process. It is the market. It is the actual human being who has to want the thing you made.
The market is the opponent because it is the only party in this whole fight that can kill your product, and the only one that never negotiates. Your team is on your side. Your craft is on your side. Your standards, your taste, your roadmap, all of it lines up behind you. The market is the one force at the table that does not care how hard you worked.
The market does not fight fair. It never tells you the rules. It changes them while you are creating and it renders its verdict without explaining why. You launch the thing you were certain it wanted, and it can just ignore it. No feedback, no second-try, no appeal.
So when I say craft is a knife and strategy is a gun, here what really matters: the market is not holding a bigger gun.
The market is holding reality. Indifference, alternatives, switching costs, and the thousand other things fighting for the same person’s attention.
Your knife cannot even reach that. Craft is close-range, and the market never gets close. Strategy is the only weapon you have with the range to hit the thing that is actually trying to kill you.
David Mamet wrote the rule for exactly this fight and, obviously, didn’t know he was writing it about us. In The Untouchables, Sean Connery’s cop explains to Eliot Ness how you actually win a fight in Chicago. “He pulls a knife, you pull a gun. He sends one of yours to the hospital, you send one of his to the morgue.”
Craft is the knife. It is close-range, personal, takes years to master, and feels like the whole fight when you are the one holding it. Strategy, deciding what deserves to exist and for whom, is the gun. It is the only thing that matches what the market brings to the table.
Right now the entire industry is standing in the street, lovingly sharpening the most beautiful knife anyone has ever seen, walking into a gunfight it refuses to admit it is in.
When Being Wrong Was Expensive
The quality of the work has almost never been what sends a product to the startup graveyard. In the decades I’ve worked in what we now call Product, I can count on one hand the times a product died because the buttons were the wrong shade of blue or the code had an anti-pattern in it.
Products die because somebody built the wrong thing, with total confidence, and nobody stopped them in time.
This is true outside of tech. In 2009 I stood on the corner of 13th and Avenue A in Manhattan’s East Village, looking at the abandoned space that would become Destination, the first bar I opened, and I counted at least six bars I could see without turning my head. A craft beer spot next door. A sports bar and an Irish pub across the street. A dive, a gay bar, a little German place around the corner. My exact thought, standing in the February slush, was how the hell do we compete with that.
So before we spent a dollar we couldn’t get back, I walked into every one of them and figured out what the block was missing, which turned out to be a genuine neighborhood living room, a place you’d actually want to spend a whole Sunday. That became the entire strategy. Not because I was disciplined. Because I had one hundred and fifty grand and six weeks and exactly one shot, and building the wrong bar would have destroyed the business before it even had a chance.
That constraint did the strategic work for me and my partners. Money, time, and the sheer physical effort of building forced us to get honest about the idea before being wrong got expensive.
The cost of building was the last thing standing between us and a bad decision. It was crude and accidental, but it worked, because when being wrong costs real money, you check your thinking while you can still afford to.
AI got rid of that.
When building is this cheap and this fast, nothing forces you to stop and ask if the idea is any good. You just keep going.
The people who study this for a living have known the mechanism for years: when an experiment is expensive, teams are far more willing to walk away from a bad one, and when experimenting gets cheap, the Cloud Native patterns folks who catalog this note the sunk-cost pull keeps a doomed idea alive well past the point where you should have killed it.
The company I told you about didn’t fail because the tools were bad. They failed because the tools were so good they never had to stop. A bunch of shots, each one fast and convincing and finished-looking, each one feeling like progress and it feels exactly like the real thing right up until you look up two and a half years later and realize none of it went anywhere.
Operators are starting to name this out loud. One CIO who is also a CPO put it plainly this year: when you can build something meaningful in an afternoon, the default quietly flips to “why wouldn’t we just build it,” and that is exactly when enthusiasm starts turning into debt nobody chose to take on.
Andrew Bosworth, Meta’s CTO, says his north star after twenty years of building product is embarrassingly simple: find a human somewhere who has a problem, then ask whether you can do something to solve it. Simple, and almost nobody starts there.
When you make everything fast, you don’t just get where you were going faster. You get to a lot of wrong places faster, and every one of them looks finished when you arrive.
When building was expensive, the cost showed up on a budget, and a budget forces a decision. When building is free, the cost does not disappear. It just moves onto your team. The endless iterating, the build-everything-and-see-what-sticks mode, that is not a strategy. It is a fire drill that never gets called off, and people are the ones running it.
Your product might come out a little prettier. It might even come out a little stronger. But ask the people who built it what the last six months cost them. Ask how many nights got eaten by a pivot nobody could explain the reason for. Ask whether anyone ever told them why. A person can sprint through a fire drill. Nobody can live in one.
Run enough of them back to back, with no decision at the end to show for it, and you do not get a stronger team. You get a burned-out one, and the good people leave first, because they are the ones with somewhere else to go.
A Beautiful Product Nobody Wants
So here’s where I part ways with the whole lovely quality conversation, Neeman’s piece included, and I want to be careful, because I’m not saying any of them are wrong. They’re arming for a fight I’m not losing sleep over.
Standards make sure the thing gets made well. Taste makes sure it’s good. Both matter more than they did a year ago, because AI just made building infinite. Jakob Nielsen puts it well: generative tools make ideation basically free, which means the scarce, valuable skill is no longer producing options, it’s the discernment to pick the good one out of the flood.
Standards and taste are both, at heart, ways of choosing well.
But…you can have impeccable standards and exquisite taste and still build, beautifully and to spec, a product not one human being on earth wants. Marty Cagan, who has spent a career on this, draws the line between teams that ship features and teams that solve problems, and his whole argument rests on one uncomfortable idea: shipping efficiently means nothing if you’re shipping the wrong thing.
Cagan’s been making that case for years. AI just made it easy to be wrong faster. The feasibility risk he wrote about, can we even build it, has mostly collapsed. The value question, should this exist at all, is exactly where it always was.
Gale Robins framed the same split cleanly in a recent piece: there’s a short game, the activities and outputs of figuring out what to build, and a long game, getting better at the judgment of what’s worth building at all.
AI made the short game fast and left the long game exactly as hard as it ever was. That long game is old, older than any of our tools.
Clayton Christensen spent a career on this and boiled it to a sentence: people don’t buy products, they hire them to do a job. The classic example is his team’s study for McDonald’s, who wanted to sell more milkshakes and couldn’t figure out how. Turned out a huge share of them sold before eight in the morning, to commuters hiring a milkshake to get through a long, boring drive and stay full till lunch.
The real competition wasn’t other milkshakes, it was bagels and boredom. Figure out the job and the product almost designs itself. Miss it and you can build the most beautiful milkshake in the world and watch it sit there. AI has no idea what job anybody is hiring your product to do. It’ll just keep making milkshakes.
I watched a version of this play out with someone who knew exactly what he was doing. When Rafat Ali launched Skift, he built it on a four-legged stool of content: aggregation, curation, syndication, original reporting. Smart, well made, defensible on a whiteboard. Then the audience showed up and, in his words, nobody gave a shit about the aggregated headlines. Four legs became three. Three became two.
He told me later that in the beginning they’d planned the company around what VCs wanted to hear, and only when they threw that out and found their own way did Skift become the thing that actually worked.
Building the product was never the problem. Ali had to find out in public which parts people actually wanted, and kill the ones they didn’t.
Now here’s the thing that should scare you a little. Ali found out because building all four legs cost him real time and money, and that cost made him look hard at what was actually working.
Run that same launch today and AI builds you all four legs by Thursday, and probably two more you didn’t ask for (thanks, Claude!). Maybe they’re good. They’re probably not. But they all look finished. And the thing that told Ali to cut gets buried under how easy it’s become to just keep everything.
None of this is a knock on how well we create products. We’ve never made them better. What’s missing is anyone stopping, before the work starts, to ask the boring questions. Who is this for? Do they actually want it? Should it exist at all?
Standards are how you build it right. Strategy is whether you build it at all. When building costs nothing, the second question is the only one holding any real leverage, and it’s the one nobody wants to write about, because “figure out what’s worth building” doesn’t trend like a shiny new practice with five steps and a downloadable template.
Deciding Is the Only Skill Left That Matters
I’m not anti-quality. I run a studio and doing the exceptional work is the tax we pay to be allowed in the room. Nielsen is right that curation is the scarce skill, Grigsby is right that taste is a moat, Demchenko is right that the role is leveling up. All of it true and all of it worth doing.
Don’t confuse a well-built thing with a right thing, because AI is about to hand you an infinite supply of the former and it will not spend a single clock cycle helping you find the latter.
The model will build you a hundred answers before lunch and have no idea which one anybody actually needs. Buzz Usborne put the stakes about as bluntly as anyone: once delivery gets this cheap, if you automate the deciding-what-to-build layer too, what’s left is quickly-built, cheaply-made, average software, same as everyone else’s.
Figuring out what to make is the actual job. It always has been. Plenty of people were never any good at it, they just never got caught, because making the wrong thing used to be slow and expensive enough to cover the mistake. Now that that part’s cheap, there’s nowhere left to hide.
With that crutch gone, the truth is simpler than we’ve let ourselves admit: this is the real work. Deciding what deserves to exist, and for whom, and why now, is the highest-leverage thing a product person can do.
Roman Pichler calls the gap between the deciding and the doing a strategy-execution chasm, and for years a lot of us have been living on the wrong side of it, heads down in roadmaps and rituals and the comfortable busyness of shipping.
Joe Smiley sees it happening right now, senior people pulled into production firefighting instead of strategy, everyone sprinting flat out in the wrong direction. If you’re in product and you’re not doing this, a model is already doing the part you thought was your job, and doing it faster.
Anyone can make anything now, which means the only skill with any leverage left is knowing what’s worth making. Everyone else is still in the street sharpening the knife. The people who win this are the ones who put it down, pick up the gun, and go decide what the market actually wants before it decides for them.
References and further reading
- Amy Gottler, on why “just because AI can, doesn’t mean it should”
- Lisa Demchenko, on the designer’s role leveling up from spec maker to system architect
- Andrea Grigsby, on taste as the edge AI can’t reach
- Patrick Neeman, on web standards as the playbook for this AI moment
- Jakob Nielsen, on ideation becoming free and curation becoming the scarce skill
- Marty Cagan, on the difference between shipping features and solving problems
- Gale Robins, on the short game of execution versus the long game of judgment
- Clayton Christensen, on customers hiring products to make progress
- Buzz Usborne, on how automating discovery leaves you with average software
- Rafat Ali, on tearing legs off the stool until Skift became the right product
- Andrew Bosworth, on starting from a human with a problem
- AJ Sunder, on how “why wouldn’t we just build it” turns into debt
- Roman Pichler, on the strategic choices that sit above execution
- Joe Smiley, on senior people pulled off strategy into firefighting
- The Cloud Native patterns project, on how a low cost of experimentation weakens the instinct to kill a bad idea
Designers are sharpening knives for the wrong fight was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More