Skip to content

Article

May 21, 2026

8 min read

Do More With the Same, Not the Same With Less

AI should help teams do more with the same people by reducing handoffs, increasing builder range, and giving product judgment more cycles.

By Cristiano Pierry

Do More With the Same, Not the Same With Less

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 small enough to stay close to the problem, move quickly, and own outcomes without excessive coordination overhead. I think AI makes that idea even more relevant. The future may look less like a large cross-functional assembly line and more like a smaller builder team 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.

Historically, this is what happens when technology lowers the friction around capability. The PC made computing personal. The internet made knowledge networked. Mobile made access constant. Cloud made capacity elastic. Each wave made something previously difficult easier, cheaper, or more widely available. And each wave increased ambition.

We did not use the internet simply to do the same amount of research with fewer people. We used it to create new products, new companies, new workflows, new markets, and new expectations. We did not use the cloud simply to run the same systems with less infrastructure effort. We used it to build faster, scale faster, experiment faster, and operate in ways that were previously impractical.

AI will follow a similar pattern, but with a different kind of leverage. It makes capability collaborative. It gives individuals and teams an execution layer that can help them think, build, inspect, and iterate. Now judgment becomes the bottleneck.

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 teams that benefit most from AI will not be the teams that simply generate the most. They will be the teams that know how to direct, verify, edit, and own the work.

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 theater instead of becoming an organizational capability.

The best teams will turn good AI usage into shared operating habits. They will create reusable prompts, examples, test harnesses, review checklists, evaluation patterns, and lightweight agents. They will make the work easier to inspect. They will teach each other what worked. They will build systems where AI accelerates the work 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.

Automate the repetitive synthesis. Automate the tedious formatting. Automate the first pass. Automate the comparison table. Automate the meeting prep. Automate the rough prototype. Automate the boring mechanics that prevent talented people from spending enough time on the work that actually matters.

Then reinvest that time in better judgment, better product thinking, better audience understanding, better experimentation, and better 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.

That is the version of AI transformation I care about.

Not fewer people doing the same work. Not generic output at higher volume. Not a race to automate away the parts of the work that make the work meaningful.

The real opportunity is smaller teams with greater range. Faster loops with stronger review. More artifacts before alignment meetings. More prototypes before roadmaps harden. More evidence before decisions. More time spent on creativity, strategy, and meaning.

The teams of the future will be builder teams. They will be small enough to move quickly, broad enough to reduce unnecessary handoffs, deep enough to maintain craft, and disciplined enough to keep accountability with people.

They will not ask AI to replace judgment. They will use AI to create more room for judgment.

That is how we do more with the same.

And that is a much more interesting future than doing the same with less.


This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.