#019: AI Is Making Execution Cheap. Now What?
When building becomes easy, the human aspects generate more leverage.
Not so long ago, turning a product idea into something testable required a small act of organisational will. You needed a spec, a designer, an engineer, alignment across at least three calendars, and several weeks of patience before anything resembling the idea existed in the world. The cost of trying things was high enough that teams thought carefully before building.
That constraint is gone. A solo founder can prototype a working product in an afternoon. A team can generate a PRD, mock up flows, scaffold code, and have something clickable before the end of the day. The tools have made building genuinely, dramatically cheaper.
Most people describe this as a productivity improvement. That framing is correct but it misses the more important shift underneath it.
This isn’t immediately obvious, which is why most teams haven’t fully absorbed it. They see faster tools and optimise for speed — faster prototypes, faster specs, faster iteration cycles. But speed, without a corresponding improvement in direction, introduces a failure mode that didn’t exist before. Teams can now build the wrong thing with extraordinary efficiency. A founder can prototype an impressive product that has no real market. A team can ship features faster than users can understand them. A company can automate a broken process and mistake the automation for progress.
The bottleneck has moved. It used to live in execution. It now lives in judgment about what’s worth executing at all.
This means the central question for product builders has changed. It’s no longer primarily “how do we build this efficiently?” It is “should this exist at all, and if so, what exactly should it be?” The builders who will stand out in this era are not the fastest ones. They are the ones who think most clearly — about users, about problems, about what actually matters. That advantage shows up reliably through five capabilities: curiosity, clarity, judgment, people leadership, and taste.
1. Curiosity
Curiosity, in the context of building products, is the habit of actively investigating what is changing before the rest of the market has named it. Not casual interest or keeping up with newsletters; sustained intellectual restlessness. A compulsion to ask what is different now, and what that difference makes possible or necessary.
The environment is changing faster than any fixed body of knowledge can keep up with. A product builder who relies on frameworks that worked two years ago will slowly drift toward irrelevance. The people who stay ahead build the habit of looking:
At user behaviour, especially at the edges, where something unusual is happening
At new tool capabilities before those tools become mainstream
At adjacent markets where a version of their problem has already been solved differently
At their own workflows — how they are building, not just what they are building
Curiosity compounds. Seeing something six months before the market names it is a meaningful edge. Seeing it consistently, across multiple cycles, is a durable one.
A developer building a B2B SaaS product starts experimenting with AI coding assistants — not because anyone told them to, but because they are curious about how their own workflow is changing. Here is how that curiosity plays out:
They notice that the team is shipping more code than before, but the review queue is backing up — the bottleneck has quietly shifted from writing to evaluating
They start asking whether this is a tooling problem or a process problem, and discover it is neither — it is a product problem that nobody has named yet
That observation becomes the seed of a roadmap conversation that shapes the next quarter, surfaced not through a research sprint but through the simple habit of paying attention
That’s what curiosity produces. Not just awareness, but earlier, better-framed opportunities that formal processes would have taken months longer to surface.
2. Clarity
Clarity is the ability to reduce ambiguity into a precise statement of the problem, the decision being made, and the criteria for knowing whether it worked. It sounds basic. In practice, it is rare, and it matters more now than ever.
When building was slow and expensive, vagueness got corrected naturally. There was time for teams to discover, through the friction of execution, that the brief was unclear or the problem was wrong.
Now that building is fast, a team without clarity can spend a week generating large volumes of impressive, misdirected work. AI is excellent at producing output. It is not effective at determining whether that output points to the right problem. That remains a human responsibility. Beyond that, the quality of what AI returns is largely determined by the quality of what you put in:
A vague prompt produces a plausible but unfocused answer
A precisely framed problem — with clear context, constraints, and a definition of what good looks like — produces something genuinely useful
The teams getting the most out of AI tools are not the ones with the best prompts. They are the ones with the clearest thinking before they open the tool
A designer working on a fintech app is asked to improve onboarding. Watch how clarity, or the absence of it, changes the outcome entirely:
Without it, the designer runs the brief through an AI tool, generates twelve visual variations of the existing screens, and presents them in a review. The work looks thorough. The problem hasn’t moved.
With it, someone first asks why users are actually dropping off. The answer, pulled from support data, is that users abandon at the income verification step because they don’t understand which documents are acceptable, not because the design is visually confusing
That single clarification changes the entire solution space. The problem isn’t visual. It’s informational. The right fix is a clearer explanation, not a redesigned screen
The team that started with clarity shipped a solution in two days. The team that started without it spent a week building the wrong thing beautifully
Clarity is what ensures that when a team moves fast, they are moving in the right direction
3. Judgment
Judgment is the ability to make sound decisions under uncertainty by weighing context, incentives, constraints, and consequences that extend beyond the immediate problem. It is the capability that answers whether something should exist at all, and in what form, and when.
AI makes judgment more important for a specific reason. AI generates plausible answers, and plausible is dangerous. A plausible answer looks convincing; coherent, well-structured, and difficult to immediately refute. But plausibility is not correctness. A strategy can be logically consistent and still be wrong about the market. A product can work technically and still fail to earn user trust. The gap between plausible and actually right is exactly where judgment lives. Products don’t exist inside tools or documents. They exist inside markets, regulatory environments, and the lived experience of real people making real decisions. No tool can tell you:
Whether your model will face compliance scrutiny in a specific market six months from now
Whether users who already have reasons to distrust technology will accept an automated decision that affects their livelihood
Whether the feature your competitor just shipped is a genuine threat or a distraction
Whether the thing you’re about to build will still look like a good idea in two years
A product team at a lending startup builds a working AI credit scoring feature in a week. It is fast, technically impressive, and the demo is clean. Here is what judgment looks like in that moment:
The builder pauses before declaring it ready to ship and asks: are the input variables — transaction history, mobile data patterns, behavioural signals — introducing bias against certain user segments in ways the model won’t surface on its own?
They ask whether the compliance team has seen this, and whether automated decisioning without a human review layer will pass scrutiny in their operating market
They ask whether a user who receives a rejection in seconds, with no explanation, will trust this product again — or tell everyone they know not to use it
They use those questions not to kill the project but to define the conditions under which it can ship: an explainability layer, a manual review trigger above certain risk thresholds, and a plain-language rejection message that treats the user like an adult
The prototype becomes a product that can survive contact with the real world. The week of building was valuable. The judgment applied after it is what made it shippable. Judgment is what stops teams from shipping polished mistakes.
4. People Leadership
People leadership is the ability to align groups around a shared goal and maintain that alignment through disagreement, ambiguity, and the constant pressure to change course. It is not about authority — most product builders don’t have formal authority over the people they depend on. It is about influence — the ability to shape how a group thinks about a problem and make a decision feel genuinely shared rather than imposed.
AI has made this harder in a way that isn’t immediately obvious. Better tools create new coordination problems. When individuals can produce high-quality artifacts very quickly, teams can diverge very quickly. The result is a specific kind of fragmentation that is easy to miss because everyone looks busy:
Designers explore ten directions before the team has agreed on one
Engineers prototype two competing approaches before the PM has finished the brief
Leadership sees speed and adds new requests into the mix
Everyone is moving, but nobody is moving together
A founding team building a marketplace product gets excited by AI-generated prototypes and starts exploring four different product directions simultaneously. Here is how that plays out without strong leadership:
Week one looks excellent — the team is shipping explorations faster than ever and energy is high
By week two, the designer is context-switching between directions and the quality of the thinking in each one is thinning out
The engineering lead starts building infrastructure for two of the directions simultaneously, unsure which one will be chosen
By week three, nobody is sure what the team is actually building, morale has quietly dropped, and a month of effort has produced impressively polished work that points in four different directions
The founder who steps in to end that situation — who can say clearly this is the one thing we are building right now, and here is why it is the right bet — is not doing less than the people writing code. They are doing the hardest thing on the team. In the AI era, the ability to move people remains harder and more consequential than the ability to move documents.
5. Taste
Taste is the ability to recognise quality — to distinguish between something that technically satisfies a requirement and something that actually works well. Something that earns trust, communicates clearly, respects the user’s intelligence, and feels like it was made by people who understood what they were building and for whom.
AI has shifted the bottleneck from generation to selection. Where the constraint used to be producing enough options, it is now choosing well among many. A team can generate ten onboarding flows or thirty microcopy variants in an afternoon. The question is no longer whether you have options. The question is whether you have the standard to select from them well. AI does not reliably provide that standard. It can produce a great option and a mediocre one in the same batch without flagging the difference. Taste is what allows a builder to tell them apart. In practice, it shows up as the ability to ask and answer:
Does this feel right for the person who will actually use it?
Does it communicate what it needs to communicate, or just what we wanted to say?
Is this complexity earned, or is it just noise?
Would a user who has never seen this before understand immediately what to do?
A content team building a health product generates several onboarding messages with AI. Here is what the selection process looks like when taste is present:
All five options are grammatically correct and contain the necessary information — any of them would pass a basic review
Four of them feel clinical. They are precise but cold, and for a user who is nervous about a health decision, cold creates distance and distance creates doubt
One of them manages to feel reassuring without being condescending, honest without being evasive, and specific without being overwhelming
The builder with taste picks that one immediately, and can articulate why: it meets the user where they actually are emotionally, not where the product team wished they were
Choosing it, and knowing why it is right, is taste. Getting to the right answer by accident is luck. Getting there consistently is a skill. When mediocre output is abundant and cheap, taste is the filter that protects quality.
The actual point
Better tools produce faster output. Whether that output becomes something meaningful depends entirely on the people directing it.
AI reduces the cost of execution. The advantage moves to thinking. Curiosity surfaces opportunities before the consensus has named them. Clarity stops teams from accelerating in the wrong direction. Judgment protects decisions from real-world failure. People leadership keeps teams coherent when speed creates pressure to fragment. Taste protects standards when mediocre output becomes the norm.
These are not peripheral qualities. They are not the soft complement to the real work. In a world where execution is cheap and fast, they have become the primary source of leverage for anyone building products. The builders who understand this — and invest in developing these capabilities as seriously as they invest in learning new tools — are the ones who will do work that matters and that lasts.
What to do with this
Get fluent with the tools — that is table stakes now, and falling behind on it is a real cost. But invest even more deliberately in the harder layer:
Study user behaviour directly and often, not through dashboards alone but through direct contact with how people actually experience the problems you are solving
Practice framing problems with precision before reaching for solutions
Make decisions, write down your reasoning, and revisit them honestly — judgment is built through repetition and reflection
Put yourself in situations where you have to bring people with you, without the authority to simply direct them
Pay close attention to great products — not just their features but the quality of thinking embedded in every interaction they create
The builders who will define this era will not be the ones who prompt the best. They will be the ones who think the most clearly, care the most deeply about what they are actually building, and know how to bring people with them.