Why organizations should anchor work in outcomes as roles, processes, and team structures keep changing
A product team that once required eight or nine people may, in some contexts, operate with three people and several AI agents.
The roles may change.
The processes will change.
The tools will certainly change.
But the organization will still need to answer the same question:
What meaningful result are we trying to achieve?
Artificial intelligence is making output faster, cheaper, and more abundant. The advantage will increasingly belong to teams and organizations that organize their work around outcomes.
Throughout this article, I use “product team” as shorthand for cross-functional teams responsible for a product, platform, data product, service, or other software-enabled outcome.
AI Is Changing the Shape of Work
For years, organizations designed software and product work around relatively stable assumptions.
Product managers shaped priorities. Designers explored user needs. Engineers built and operated solutions. Data specialists helped interpret evidence. Delivery leaders coordinated risks and dependencies.
Agile had already challenged rigid handoffs by bringing these capabilities together in cross-functional teams.
AI does not make that idea obsolete. But it changes the composition of the team.
A product manager can create a prototype. A designer can generate and test code. An engineer can synthesize customer feedback. A small group can produce research summaries, test scenarios, implementation options, and release documentation in a fraction of the time.
Some activities that once required a dedicated person may become automated. Others will move across traditional role boundaries. New responsibilities will grow around context, orchestration, verification, governance, judgment, and decision quality.
The old question was often:
- Who is responsible for producing this artifact?
The more important question now is:
- Who is responsible for ensuring that this work contributes to the right result?
In my work with large organizations, I see many revisiting their processes, roles, and ways of working. They want to know how many people a team needs, which capabilities must remain human, where agents fit, and how decision rights should change.
Those are valid questions.
But they can also become a trap.
When the environment is changing quickly, spending time defining every role, workflow, and handoff may produce a model that is outdated before it is fully implemented.
Processes still matter. Roles still matter.
But when both are moving targets, they should not become the primary source of direction.
Rigid roles and processes are fragile in a changing environment. Outcomes give teams direction without fixing how the work must be done.
Not the exact task.
Not the exact job description.
Not the exact workflow.
The result.
When Output Becomes Abundant, Judgment Becomes the Constraint
For most of the history of knowledge work, producing a high-quality output required significant time, specialized skills, and coordination.
A prototype required design effort.
A market analysis required research and synthesis.
A feature required engineering, testing, and operational preparation.
A meaningful OKR required discussion, prioritization, and agreement.
An MVP required difficult choices about scope, risk, and learning.
Production was expensive.
AI changes that equation.
It can summarize interviews, generate product alternatives, propose experiments, write acceptance criteria, create interface concepts, produce and review code, organize evidence, and draft strategic options.
What was once scarce is becoming abundant.
But abundance of output does not create clarity of direction.
Teams can explore more alternatives, test ideas earlier, reduce repetitive work, and enter important conversations better prepared.
But abundance changes the problem.
When producing an output becomes easy, choosing the right output becomes harder.
A team can generate ten roadmap options.
That does not mean any of them represents a good strategic choice.
It can produce hundreds of backlog items.
That does not mean the backlog reflects what matters most.
It can generate a functional prototype.
That does not mean customers need it.
The ability to produce something no longer proves that it deserves to exist.
As the cost of production falls, the bottleneck moves:
From producing to choosing.
From creating options to evaluating them.
From writing plans to making decisions.
From generating information to interpreting what matters.
From completing work to learning whether the work created meaningful change.
This is where AI can create a dangerous illusion.
A detailed backlog can create a false sense of control.
More prototypes can look like stronger discovery.
More documentation can look like better alignment.
More code can look like faster delivery.
But quantity is not progress.
The danger is not that organizations will produce too little. It is that they will become extremely efficient at producing things that do not matter.
Many organizations are now investing in AI to accelerate the same metrics that already distort behavior: roadmap completion, feature volume, utilization, and delivery speed.
These measures are visible and easy to track.
But they describe the production system more than the result the organization is trying to achieve.
A feature was delivered.
A project reached its milestone.
A roadmap item moved to “done.”
None of those statements tells us whether anything meaningful changed.
Did customers adopt the solution?
Did retention improve?
Did operational risk decline?
Did the organization learn something important?
The distinction between output and outcome has always mattered.
This is not an argument against reliable delivery. Organizations still need to manage quality, risk, dependencies, and operational excellence.
The problem begins when the output becomes the definition of success.
An output is something the organization produces.
An outcome is a change that happens because of what the organization produced.
Consider a team working on customer onboarding.
An output-based goal might be:
- Launch the redesigned onboarding flow by the end of the quarter.
An outcome-based goal might be:
- Reduce the median time for a new customer to reach their first moment of value from ten days to three.
The redesigned flow may contribute to that result.
So might better guidance, proactive support, simpler configuration, or removing an unnecessary requirement.
The outcome gives the team room to adapt the outputs.
The question is no longer how much we can produce, but what meaningful change we are trying to create and how we will recognize progress.
Outcomes Become the Organizing Anchor
Many organizations are asking for help redesigning processes, clarifying roles, and rethinking team structures.
That is understandable.
The assumptions behind many operating models are becoming outdated. Some functions are being augmented. Some are being combined. Agents are taking on work that used to define parts of a job.
Organizations need to adapt.
But this is exactly why I increasingly prefer to begin somewhere else.
Instead of starting with a perfect description of roles and processes, start with the outcome.
Ask:
- What change are we trying to create?
- What evidence would indicate progress?
- What should the team be able to adapt as it learns within its mission and strategic boundaries?
A process describes how work is expected to happen.
A role describes who is expected to do part of that work.
Team design shapes where responsibility sits, how value can flow, and what mission the team is expected to fulfill.
An outcome clarifies the meaningful change that this structure is meant to enable.
When the “how,” the “who,” and even the team structure are changing rapidly, the intended result becomes a more reliable organizing anchor.
Outcomes are not permanent.
Strategies change. Markets shift. Customer behavior evolves. New evidence appears.
But outcomes are usually more stable than the activities, job boundaries, workflows, and outputs used to pursue them.
A team may change the solution, process, people, tools, or even its internal composition and still remain responsible for the same outcome during that cycle.
An outcome defines a meaningful and observable change.
It does not prescribe exactly what must be built.
It creates direction while preserving room for teams to adapt their approach within a clear strategic direction, mission, and set of constraints.
If a team is told to deliver a feature, the work is already framed around a solution.
If the team is asked to improve an outcome, it can explore several paths while remaining aligned with its mission and broader organizational direction.
This also changes how AI is used.
In an output-driven system, AI becomes mainly a production accelerator.
In an outcome-driven system, AI can become a learning accelerator.
It can help teams generate hypotheses, expose weak assumptions, synthesize evidence, compare options, and design faster experiments.
AI can help teams produce more, or help them learn faster. The distinction comes from how the work is framed.
Outcomes also create a better basis for accountability.
Traditional accountability asks whether a team delivered what it promised.
Outcome accountability asks:
Did the team make meaningful progress toward the change it was responsible for pursuing?
No team can guarantee an outcome.
Outcome ownership is not a promise of certainty. It is a commitment to pursue a meaningful change, learn from evidence, and adapt responsibly within the direction and constraints of the organization.
That changes the role of planning.
Plans become hypotheses about how to influence an outcome.
Backlogs remain adaptable.
MVPs become vehicles for learning, not merely smaller releases.
Team design matters here as well. The organization still needs to shape teams so they have enough context, capability, and authority to pursue the outcomes they own. But structure should support the outcome, not become an end in itself.
When the ways of working keeps changing, outcomes provide a more stable anchor for direction, focus, and accountability.
Strategic direction clarifies where the organization is going. Team design enables flow. Team-level outcomes create commitment.
One Problem, Three Responses
Lean Inception, Team OKR, and Triple Track emerged at different moments in my work.
But they respond to the same problem:
Organizations often confuse activity with progress.
Lean Inception: Do Not Start with the Full Solution
Lean Inception emerged because organizations were starting initiatives without enough shared understanding.
Business leaders, product people, designers, engineers, and other stakeholders entered the same initiative carrying different assumptions about the problem, the users, the business goal, and what should be built first.
Lean Inception created a collaborative space to build shared understanding and decide what should be validated first.
The visible result was often an MVP plan.
But the deeper value was the conversation that produced it.
The MVP was never meant to be a smaller version of the full solution. Its purpose was to test the most important assumptions with the least unnecessary effort.
A meaningful MVP connects an output to learning.
AI can now help teams create prototypes, interfaces, code, and alternatives much faster.
But faster prototyping does not automatically create faster learning.
The value of the MVP remains in the question it helps answer, not in the sophistication of the artifact.
A team presents its MVP Canvas during a Lean Inception, aligning different perspectives on what should be validated first—not merely what should be built.
Read more about Lean Inception here.
Team OKR: Do Not Derive Direction from the Backlog
Team OKR emerged from a different version of the same problem.
Organizations were adopting OKRs to connect strategy and execution. But in many cases, teams simply rewrote their existing backlog as an OKR.
The result looked aligned on paper.
But little had changed.
The OKR had become a new label for the work already planned.
The backlog should not determine the Team OKR.
The Team OKR should help the team decide what belongs in the backlog.
The backlog should not define the Team OKR. The Team OKR should guide what belongs in the backlog.(imagem form the book Team OKR in Action)
Leadership can define the broader strategic direction.
But teams need to interpret that direction in their context, define the outcome they can meaningfully influence, and decide how they will pursue it.
The objective gives meaning and direction.
The Key Results describe the change the team intends to produce.
The backlog remains adaptable.
If success is defined by completing the original backlog, adapting looks like failure.
If success is defined by pursuing the outcome and learning responsibly, adapting is part of the work.
Triple Track: One Team, Three Interwoven Responsibilities
Triple Track addresses a third version of the problem: Business Strategy, Discovery, and Delivery treated as separate worlds.
Strategy defines goals.
Discovery explores problems, assumptions, and possible solutions.
Delivery builds and releases.
Each area may work well on its own and still fail to create meaningful progress.
That is why I prefer to think of Triple Track not as three parallel lanes, but as a threefold cord:
- Business Strategy provides the WHERE TO: the outcomes the team wants to achieve.
- Discovery explores the WHAT: the problems worth solving, the assumptions to test, and the possible solutions.
- Delivery handles the HOW: building and releasing working software that produces real feedback.
Triple Track is not three teams working in parallel. It is one cross-functional team continuously connecting direction, learning, and execution.
Without that connection, each track can optimize independently.
Strategy produces plans.
Discovery produces insights.
Delivery produces features.
Everyone is busy.
But the organization may still fail to create meaningful change.
AI dramatically accelerates the HOW.
But faster Delivery does not remove the need for clarity about the WHERE TO or learning about the WHAT.
The faster we can build, the more important it becomes to choose the right problems, validate the right assumptions, and connect every output to a meaningful outcome.
Threefold Cord: Business Strategy, Discovery, and Delivery
Learn more in the article “Triple Track Development: Business Innovation Through Continuous Discovery and Continuous Delivery.”
Lean Inception, Team OKR, and Triple Track address different moments in product work.
But all three resist the same failure mode:
confusing the production of work with progress.
A polished MVP plan is not progress if it does not help validate an important hypothesis.
A well-written OKR is not progress if the team does not own it or use it to guide decisions.
A fast delivery system is not progress if it accelerates the wrong work.
AI does not invalidate these ideas.
It makes them more urgent.
Teams Are Changing, but Outcomes Still Require Teams
Agile already taught us that meaningful software work requires more than isolated specialists passing work from one function to another.
Cross-functional teams brought different capabilities closer together so they could solve problems, learn, and improve how they worked.
That principle remains.
What is changing is the composition of the team.
Some capabilities that once had to be provided by people may increasingly be provided by agents.
A product manager may create a prototype. A designer may generate and test code. An engineer may synthesize customer evidence. An agent may prepare research summaries, test cases, or implementation options.
Expertise still matters, but its value shifts from artifact production to judgment.
More of their value will come from framing the problem, interpreting context, making trade-offs, evaluating evidence, coordinating decisions, and taking responsibility for results.
Some teams will become smaller.
Some handoffs will disappear.
Some roles will merge.
But smaller teams do not eliminate the need for teams.
They change what teams are for.
In an output-driven organization, a team is treated mainly as a production unit.
In an outcome-driven organization, the team is a unit of judgment, ownership, and learning.
AI may reduce the number of people required to produce an output. It does not remove the need for a team to own an outcome.
An agent can generate a prototype.
It cannot carry organizational accountability for whether the prototype addresses the right problem.
It can recommend a prioritization.
It cannot resolve every strategic, political, ethical, and customer trade-off behind that decision.
Agents can participate in the work.
They can accelerate the work.
They can reshape the work.
But accountability still needs a home.
In a small company, a few highly capable people supported by AI may achieve results that once required a much larger organization.
But growth creates complexity: more customers, markets, products, platforms, regulations, and dependencies.
Context becomes harder to hold centrally.
Responsibility must be distributed through teams with enough context, capability, and authority to own meaningful outcomes.
This is where the relationship between leadership and teams becomes critical.
Leadership sets strategic direction. Teams turn that direction into choices, learning, and outcomes.
AI can support both sides.
But it does not remove the relationship between direction and ownership.
It makes that relationship more important.
When outputs become cheap, teams can pursue many directions at once.
Without clear ownership of outcomes, abundance becomes fragmentation.
Outcomes provide a shared reference point for adaptation. Coordination allows people and teams to adapt without moving in conflicting directions.
Different people can generate different strategies.
Different agents can produce different plans.
Different teams can optimize different local goals.
Everything may move faster while the organization moves less coherently.
Outcomes create a shared reference point.
Teams provide the organizational unit capable of taking responsibility for it.
The team of the future may look different, but organizations will still need a unit capable of turning direction into judgment, learning, and action.
That unit is the team.
Teams Still Matter
AI will continue changing roles, processes, team sizes, and the economics of production.
Outputs will become faster, cheaper, and more abundant.
But organizations will still need to decide what matters, interpret evidence, make trade-offs, and adapt together.
The strongest organizations will not be those that generate the most output.
They will be those that organize people and agents around meaningful outcomes—and learn faster than the environment changes.
That responsibility does not belong to a tool or to an isolated role. It belongs to a team.
Strategy provides direction.
Outcomes create focus.
Teams provide ownership.
AI provides acceleration.Teams still matter.
Further Reading and Events
This article brings together ideas I have developed across Team OKR in Action, Lean Inception, Triple Track Development, and my new book, Teams Still Matter: Human Direction, AI Acceleration, and the Future of Product Work.
It also reflects my current work with leadership teams through the Strategy to Outcomes Sprint, helping organizations turn strategic direction into aligned execution through OKRs, team design, discovery, and MVP definition.
I will explore these ideas further in my keynote at Agile Trends São Paulo 2026, where I will also launch the Portuguese edition of Teams Still Matter.
About Paulo Caroli
Paulo Caroli helps leadership teams and organizations turn strategy into outcomes by connecting strategic direction, Team OKRs, Lean Inception, discovery, delivery, and AI-assisted ways of working.
He is the creator of Lean Inception and Team OKR and the author of several books on product development, collaboration, and organizational outcomes. Over more than three decades, he has worked with startups, scale-ups, and large global organizations across the United States, Europe, Latin America, and India.
Working through similar challenges? Learn more at caroli.org or contact [email protected].
