When Implementation Becomes Cheap, Product Becomes a Curation Problem

Hatched by Noah

Jul 13, 2026

11 min read

3 views

90%

The strange inversion nobody planned for

What happens when anyone can build almost anything, almost instantly, but very few people can tell what should actually exist?

That is the quiet inversion reshaping product work. For years, software teams treated implementation as the expensive part. The logic was simple: write long docs, de risk with research, prototype sparingly, then spend the real money on building. But once AI made implementation cheap, that old sequence started collapsing. The bottleneck moved. Not to coding. Not even to design. It moved to judgment.

That sounds elegant until you see what it means in practice. Teams can now produce 90 versions of the same idea, all plausible, all fast, all slightly wrong in different ways. The hard part is no longer making something. It is deciding which thing belongs in the product, which thing belongs in a prototype, which thing should wait for better models, and which thing should never ship at all.

The new scarce skill is not creation. It is curation under uncertainty.

That single shift explains a surprising amount of what is happening across modern AI products, from coding tools to general knowledge work systems. It also explains why some teams feel like they are moving faster than ever while simultaneously becoming less coordinated. When abundance arrives, taste stops being a luxury. It becomes infrastructure.

Why taste is no longer a soft skill

Most people hear the word taste and think of aesthetics: spacing, typography, animation curves, or whether a product feels polished. That version matters, but it is only the visible layer. The deeper version of taste is a compound skill made of three things: systems thinking, timing, and framing.

Systems thinking asks: how does this feature fit into the product as a whole? Timing asks: is the model or the market ready for this shape yet? Framing asks: what is this product actually promising to be?

Those questions used to sit downstream of engineering constraints. Now they sit upstream of almost everything. If a feature can be built in an afternoon, then what differentiates teams is not whether they can build it, but whether they know whether they should. That is why taste has become a product discipline, not just a design one.

A useful mental model here is to think of product leadership as signal routing. In the old world, leaders spent much of their time reducing risk before construction. In the new world, leaders spend much of their time reducing noise after construction. The challenge is not scarcity of ideas. It is overproduction.

This is also why the best product people increasingly look like editors. They do not simply invent. They triage, combine, sharpen, delay, reject, and reframe. They ask whether the prototype is actually proving the thing they need to prove, or merely making the idea feel real. A beautiful prototype can mislead just as easily as a bad one. A long document can clarify a foggy area, but it can also become a graveyard of untested assumptions. Choosing the medium is now part of the work.

A prototype is for stress testing interaction. A document is for making a vague idea legible. Confusing those two is one of the fastest ways to waste the new abundance.

The product org becomes a zone defense

If everyone can build, then overlap becomes the enemy. The old hierarchy, where a few people planned and many executed, no longer maps cleanly to reality. What emerges instead is something closer to zone defense.

In basketball, zone defense is not about everyone guarding one person. It is about covering space. The same logic applies to product work in the AI era. You do not want multiple people crowding the same feature just because they all have good ideas and unlimited tokens. You want clear coverage across the product surface, with each person owning a region of possibility and filling gaps as they appear.

That changes what high performing teams look like. The most valuable person is often the one who can take an idea from zero to done, but with the judgment to know when done should mean “released,” when it should mean “parked,” and when it should mean “reframed.” In other words, the best people are not pure builders or pure managers. They are operators of attention.

This is where the old boundary between IC and manager starts to blur. If an IC is directing agents, coordinating dependencies, and deciding what work is worth the machine’s time, then they are managing in a new sense. If a manager is doing the same thing at a broader grain, they are still managing, just across a larger system. The unit of leverage has changed.

The important implication is that modern product organizations need less coordination by proximity and more coordination by intentional separation. Counterintuitively, strong product people may need to work more independently, not less. Too much overlap now creates churn, duplicate effort, and product incoherence. Space is a feature.

In an abundant building environment, the job of leadership is not to maximize collaboration. It is to maximize coverage without collision.

Timing is part of the product

One of the most counterintuitive lessons from AI products is that the same product shape can fail in one month and work in the next. That means product is not just interface, flow, or feature set. Product also includes timing relative to capability.

This is a brutal truth because it undermines the comforting idea that if a product fails, the shape was wrong. Sometimes the shape was right and the models were too weak. Sometimes the model was ready, but the product framing was too ambitious. Sometimes the whole thing was just launched a few months too early.

That leads to a different planning philosophy. Long range plans should be hazy on purpose. Precision six months or nine months out often creates false confidence and wasted motion. Near term work, by contrast, deserves specificity. The closer the horizon, the more detail you can trust.

This is not anti planning. It is anti fake certainty. A good roadmap in this world is less like a commitment to a fixed sequence and more like a portfolio of bets with staged readiness levels. Some ideas are ready now. Some need more model capability. Some need better UX. Some need a different user persona entirely.

A practical framework is to classify every candidate feature into one of four buckets:

Ship now: the model, UX, and user need are aligned.
Prototype now, ship later: the shape matters, but capability is still lagging.
Keep warm: the idea is promising, but the timing is wrong.
Drop it: the concept only seems good because the tooling makes it easy to imagine.

That last category is important. Cheap implementation creates a special kind of delusion. Because you can build it, you start to believe it deserves to exist.

Why the best products may be homes, not destinations

A lot of product thinking still assumes that the best tool is the one that replaces the others. But the more interesting direction is often the opposite. The best AI products may not be full replacements. They may be orchestrators.

Think of a system that can live at the center of your workflow, understand what you are trying to do, and connect out to specialized tools when needed. It does not need to become a better spreadsheet, video editor, browser, or IDE than the best dedicated app. It needs to know when to hand work off, when to observe, and when to act across tools.

That matters because real work is messy. A videographer may use AI to edit by having it manipulate markers inside Premiere. A finance person may want a conversational interface that can answer questions and move money. A developer may want a coding surface that can spawn browser work, summarize Slack updates, or create artifacts without turning into a giant monolithic IDE.

The strategic lesson is subtle: general tools win by becoming good at coordination, not by absorbing every specialized domain.

This makes the product surface a kind of home base. It is where work begins, where context accumulates, and where orchestration happens. But the real work may happen elsewhere, inside the app that was already best at that task. The AI layer becomes the connective tissue.

The future is not one app that does everything. It is one app that knows how to make everything else usable.

This also explains why extensibility matters so much. If the product can talk to external tools, it can grow into new workflows without needing to rebuild them from scratch. In a world where models improve quickly, this is a major advantage. You want a product architecture that can survive multiple capability jumps without changing its essence every quarter.

Dogfooding as the real feedback loop

There is another subtle pattern here: the best way to discover what a product should become is often to use it until it starts irritating you.

Dogfooding is not just validation. It is role discovery. When a builder uses their own product to solve real work, the product reveals the work they actually do, not the work they think they do. A tool that started as a developer aid may slowly become a product discovery engine, a daily briefing system, a release manager, or a cross functional coordinator.

This is important because it exposes the mismatch between a product’s original persona and its real one. Many products begin as if they serve one user, then reveal they are useful to five adjacent users in radically different ways. Trying to force everyone into the first persona often fails. The trick is to preserve a coherent core while letting the surface adapt.

The same dynamic applies to internal roles. As the product grows, the founder, product lead, or engineer often has to keep changing how they use the tool in order to stay aligned with its current frontier. That is not a bug. It is the feedback loop.

A strong dogfooding practice has three properties:

It produces personal pain, not abstract metrics.
It reveals workflow gaps, not just feature requests.
It evolves the user's role in parallel with the product.

This is why the best AI products are often discovered through lived frustration. The builder wants one thing, then needs another, then notices the product is becoming useful in an adjacent domain. That sequence is not accidental. It is how product meaning gets negotiated.

The real lesson: products are becoming living systems

If implementation is cheap, taste is the bottleneck. If models can write more code, then deleting code becomes more important. If products can orchestrate other tools, then integration becomes as important as interface. If planning becomes less precise, then adaptation becomes part of execution.

All of this points to a bigger shift. We are moving from products as static artifacts to products as living systems.

A static product is something you design, build, and ship. A living system is something you continuously steer. It learns from use, accumulates context, and changes shape based on capability, timing, and user behavior. It has loops, not just launches.

That is why the highest leverage people in this world will be unusually broad. They will need enough technical fluency to understand what the machine can do, enough product judgment to know what matters, enough design sensitivity to preserve meaning, and enough operational discipline to keep the system moving. They will not just ship features. They will manage ecosystems of work.

This is also why the old distinction between “product” and “execution” is dissolving. When the system itself can execute, the human role shifts toward deciding what execution is worth pursuing. That is not less important than before. It is more important, because it sits upstream of all leverage.

Key Takeaways

Treat taste as an operating system, not a style preference. It combines aesthetics, systems thinking, timing, and product framing.
Choose the medium by the job. Use documents for clarity, prototypes for interaction testing, and do not confuse the two.
Plan with asymmetric precision. Be specific near term, hazy far out, and assume long horizon forecasts will be wrong.
Design for orchestration, not replacement. The best AI products often connect to specialized tools instead of trying to rebuild them.
Organize product teams like zone defense. Spread people out for coverage, minimize overlap, and hire builders with product sense.

Conclusion: the new product question is not can we build it

The old product question was, can we build this?

The new question is more unsettling: what deserves to exist now that building is cheap?

That shift changes everything. It changes how we plan, how we organize teams, how we evaluate design, how we use prototypes, and how we think about product success. It also changes what excellence means. Excellence is no longer just velocity. It is the ability to route scarce attention through an environment flooded with possibility.

The companies that win will not necessarily be the ones that generate the most ideas or the most code. They will be the ones that know how to turn abundance into coherence. In an era where anyone can make almost anything, the rarest talent is not creation. It is the courage and discipline to say: this one, now, in this form, with this frame, for this reason.

That is not a smaller job than software used to be. It is a larger one. And it may be the most important product skill of the decade.