There is a version of the AI conversation that I find deeply uninspiring. It is the version that starts with the question, “How can we do the same work with fewer people?”

That may be a tempting framing in some rooms, but I think it misses the real opportunity. The better question is, “How much more could we build, learn, test, and improve with the same team?”

That distinction changes how we think about productivity. It changes how we think about team design. It changes how we think about leadership. Most importantly, it keeps the conversation focused on potential instead of scarcity.

AI should not be viewed only as a cost-reduction mechanism. Used well, it is a capability multiplier. It can compress the mechanics of work so teams have more time and energy for the parts of the work that require judgment, creativity, taste, context, and accountability.

In my world, working across product, personalization, search, experimentation, and AI-enhanced discovery, that distinction is very real. We are not trying to create more output for the sake of output. We are trying to create better audience experiences, make stronger decisions, move faster from idea to evidence, and increase the number of meaningful product bets we can responsibly explore.

That is where AI becomes interesting. It does not just make individual tasks faster. It changes the shape of the team.

For a long time, product development has been organized around specialized handoffs. A program manager coordinates the work. A product manager frames the problem. A researcher gathers user insight. A designer explores the experience. A front-end engineer builds the interface. A back-end engineer connects the systems. A machine learning expert works through models, ranking, personalization, data, and evaluation.

That structure made sense. Each discipline had different tools, different queues, different knowledge, and different constraints. Specialization created quality. It gave teams depth. It gave complex work a way to move forward.

But it also created latency because the system itself depended on translation. Ideas moved from conversation to document to meeting to design to ticket to implementation to review to analysis. Every handoff required context transfer. Every transfer created room for delay, ambiguity, and some loss of intent.

AI changes this because it reduces the distance between intent and artifact.

A product leader can now turn a strategy question into a prototype, a product brief, a set of experiment options, a customer-facing narrative, or a working demo much faster than before. An engineer can move more easily across product context, code, testing, documentation, and edge-case review. A designer can explore interaction logic, simulate flows, and make prototypes that behave more like real software. A data or ML specialist can make evaluation logic easier for the rest of the team to inspect and understand.

The result is that each person can stretch further across the lifecycle while still bringing real depth where it matters.

AI expands range. Expertise gives depth.

Amazon popularized the idea of the two-pizza team: a team close enough to the problem to move quickly and own outcomes without excessive coordination overhead. I think AI makes that principle even more relevant. The future may be less dependent on long chains of handoffs and more supportive of high-context teams with overlapping range, strong ownership, and frontier tools embedded directly into the work.

I like the word builder because it is broader than job title. A builder is not only someone who writes code. A builder is someone who can move from problem to artifact. They can frame the question, explore options, make something tangible, inspect the result, learn from it, and improve it. They create the next piece of evidence instead of waiting for perfect certainty.

Frontier LLM tools make that posture much more powerful. They help people draft, code, critique, summarize, compare, test, analyze, and iterate. They help teams move from abstract alignment to working artifacts. They help convert ideas into things people can react to. The unlocked potential is in the extra reps.

When the cost of creating the first version drops, teams can explore more options before they commit. They can test more variants before they settle. They can create demos before spending weeks aligning around words. They can pressure-test assumptions earlier. They can expose weak thinking sooner. They can spend more time on the decision and less time fighting the blank page.

Lowering the cost of a first version should increase the number of useful experiments a team can run. But AI output often looks finished before it has earned trust. It can produce a polished draft, a plausible answer, a working prototype, or a clean analysis very quickly.

But polished is not the same as true. Fast is not the same as good. Confident is not the same as correct.

The benefit appears when teams know how to direct, verify, edit, and own the work instead of simply generating more.

That is why I keep coming back to a simple operating model: human, AI, human.

The human sets the direction. What matters? Who is this for? What constraints apply? What tradeoffs are we willing to make? What does good look like?

AI expands the middle. It can research, structure, draft, compare, critique, generate alternatives, write code, summarize messy inputs, and create working artifacts.

Then the human owns the finish. Is it true? Is it useful? Is it specific? Is it safe? Does it reflect our audience, our standards, and our strategy? Is this something we are willing to ship, share, or defend?

That last step becomes more important as the tools get better.

The leadership challenge is to make this repeatable. It is not enough for individuals to become better at prompting. Teams need workflows that are observable, reviewable, and reusable. We need to know what was asked, what changed, what was verified, and what pattern should be repeated. Otherwise, AI remains a personal productivity practice instead of becoming an organizational capability.

Teams can turn good AI usage into shared operating habits: reusable prompts, examples, test harnesses, review checklists, and evaluation patterns. The purpose is to make the work easier to inspect and repeat without obscuring accountability.

This is where I think the “do more with the same” framing becomes important.

The goal is not to use AI to fill everyone’s calendar with more noise. The goal is to automate the drag and reinvest the attention.

Use AI for repetitive synthesis, formatting, first passes, comparisons, meeting preparation, and rough prototypes. Then reinvest the time in product judgment, audience understanding, experimentation, and decisions.

In content discovery, this distinction is especially important. The quality of the experience is not just whether a feature ships. It is whether the product helps people find something meaningful. It is whether search behaves the way audiences expect. It is whether recommendations feel useful. It is whether personalization is relevant without becoming narrow. It is whether the interface earns trust. It is whether we can measure what changed and learn from it.

AI can help us explore more possibilities before we make expensive bets. It can help us make messy evidence easier to inspect. It can help us move from product stories to demos. It can help us test ideas against real constraints. It can help us generate sharper questions and expose weaker assumptions earlier.

But the point is not to outsource the product judgment. The point is to give that judgment more surface area, more evidence, and more cycles.

The opportunity I care about is the same team with greater range: fewer unnecessary handoffs, more evidence before decisions, and enough discipline to keep accountability with people.

Use AI to create more room for judgment.

That is what it means to do more with the same.