Vector North Advisory · September 8, 2026 · 11 min read
For years, the software industry has talked about small, autonomous, cross-functional teams. Agile encouraged teams to organize around work, bring the necessary skills together, and give those teams enough autonomy to figure out how to accomplish an outcome. It was a compelling idea, and in many organizations, we genuinely tried to make it work.
Then reality intervened.
Building modern software required increasingly specialized skills. We needed product managers, designers, frontend engineers, backend engineers, QA engineers, data engineers, architects, DevOps specialists, security experts, researchers, analysts, and any number of other disciplines depending on what we were building. Even when we called a team cross-functional, it frequently depended on half a dozen other teams before it could actually accomplish anything.
So we created structures to manage those dependencies. We built permanent product teams around areas of the application. We assigned people to them. We created backlogs for each team, established ceremonies, coordinated dependencies, and developed increasingly sophisticated processes for getting work from one specialized group to another.
Eventually, the structure became so familiar that we stopped asking why it existed.
I think it is worth asking again.
Most product organizations begin with the people.
We decide that a product area needs a product manager, a designer, several engineers, perhaps a QA engineer, and access to other specialists. We give the team ownership of a product or feature area, and then we begin feeding work into it.
There is nothing inherently wrong with that model. It brought stability and clear ownership to increasingly complex software organizations. The problem is that the composition of the team becomes fixed while the nature of the problems being solved constantly changes.
One problem may primarily require customer research and experience design. Another may be deeply technical and require architecture and platform expertise. Another may involve data analysis. Another may require experimentation across several products. Some problems may require five people working closely together for several weeks. Others may require two people for a couple of days.
Yet our organizational model often responds to all of them with essentially the same answer: give it to the team that owns that part of the product.
We have been starting with the team and asking what work we should give it.
What happens if we reverse that?
Start with the outcome we want to create, the problem we want to understand, or the idea we believe is worth exploring. Then ask what capabilities are required to pursue it.
I think that leads to a very different kind of product organization.
I have come to think of these as outcome teams. I have used other names for them in practice, including PODs, but the name matters considerably less than the principle.
An outcome team forms around something the organization has determined is worth pursuing. Sometimes that begins with a clearly understood problem. Sometimes it begins with an idea or opportunity that needs to be explored. In either case, the team is not handed a predetermined solution and a deadline and asked to back into what can be delivered within the allotted time.
The team begins by learning.
It understands the problem or opportunity, establishes the outcome it hopes to create, develops hypotheses, and determines how those hypotheses can be tested. That might involve customer conversations, prototypes, proofs of concept, data analysis, A/B tests, technical experiments, or some combination of them. What happens next depends on what the team learns.
There is usually a core group that remains connected to the work throughout its lifecycle, but the composition around that core can change. If the team discovers that a hypothesis depends heavily on data, someone with deeper data expertise might join. If a prototype reveals an architectural issue, an architect may become involved. If the eventual solution requires a shared platform capability, someone responsible for that platform may participate.
Those people do not necessarily become permanently assigned to the team. Someone may contribute to several outcome teams simultaneously, particularly when their expertise is needed at specific points rather than continuously.
That is an important distinction because dynamic teams should not become another organizational extreme. The goal is not to take everyone in Product, Engineering, Design, Data, and Architecture, throw them into one giant pool, and have them randomly assemble every Monday morning.
People still need homes.
Product people should still belong to Product. Engineers should still belong to Engineering. Designers should still belong to Design.
Those functional organizations provide things that temporary outcome teams cannot. They develop professional capabilities and practices. They provide coaching and career development. They share domain knowledge. They establish appropriate standards. They identify risks and overlapping work that may not be visible from inside an individual initiative. They help resolve conflicts when multiple teams need the same scarce expertise.
Perhaps most importantly, they maintain a broader perspective.
An individual outcome team should be intensely focused on accomplishing its objective. Someone still needs to recognize that three different teams are unknowingly solving variations of the same problem, that two proposed solutions will create conflicting experiences, or that an architectural decision being considered by one team has implications across the platform.
Functional leadership and outcome teams therefore solve different problems. One provides continuity, expertise, standards, and perspective. The other creates focus around an outcome.
We do not have to choose between them.
There is another potential misunderstanding with autonomous teams that is worth addressing. Autonomy does not mean that every team independently decides what the company should work on.
Organizations still need strategy and prioritization.
Senior leadership establishes the broader direction of the company, including the strategy, objectives, and North Star toward which the organization is moving. From there, product, engineering, design, and other leaders closer to the work play a critical role in translating that direction into decisions about which problems and opportunities deserve attention.
That layer of leadership is particularly important because priorities rarely exist neatly within the boundaries of one product.
A product manager looking exclusively at their own product area may make a completely rational prioritization decision and still make the wrong decision for the company. A platform capability affecting five customer workflows may matter more than the highest-scoring item in one product backlog. A shared identity problem may deserve resources from several teams. An organizational objective may require temporarily deprioritizing something that appears more valuable when viewed through only one product's metrics.
Outcome teams do not eliminate that judgment. They depend on it.
Leadership determines which mountains are worth climbing. The outcome team gets considerably more freedom to determine the best route up the mountain.
This is where AI enters the conversation, although I do not think AI is the reason for this model.
The aspiration toward smaller, autonomous teams has existed for decades. What is changing is our ability to make it practical.
Many of the boundaries between disciplines were created for legitimate reasons. Specialized tools, programming languages, technical stacks, analytical skills, and professional expertise made it difficult for any individual to operate very far outside their primary discipline.
Those boundaries are becoming more permeable.
A product manager can now analyze data that might previously have required an analyst. They can create a working prototype or proof of concept rather than waiting for engineering capacity simply to test whether an idea has merit. A designer can move much closer to a functional experience rather than stopping at a static representation of one. Engineers can work more effectively across unfamiliar parts of the technology stack.
This does not mean everyone suddenly becomes interchangeable.
There is an enormous difference between creating a prototype and building secure, scalable, maintainable production software. Engineers and architects remain essential to the latter. Deep design expertise still matters. Data expertise still matters. Security, infrastructure, research, and other specializations still matter.
The opportunity is not to eliminate expertise. It is to become more deliberate about when expertise is required.
If a product manager can build enough of a prototype to test a hypothesis with customers, there is no reason to wait three weeks for a development team simply because building things historically belonged exclusively to Engineering. If the hypothesis survives the experiment and the organization decides to build production software, the equation changes.
The lines between disciplines can blur without pretending the disciplines themselves have disappeared.
There is an uncomfortable implication to all of this for Product Management.
If AI makes it dramatically easier for people to build things, product managers will increasingly be able to build things too. I think that is a good development. Product managers who can turn an idea into something tangible enough to put in front of customers can dramatically accelerate learning.
But building was never the most important part of Product Management.
Knowing what is worth building is.
If anything, that responsibility becomes more important as building gets easier. When creating software was expensive, the cost itself created friction. Ideas had to compete for scarce engineering capacity. That was not always a good prioritization mechanism, but it did prevent us from pursuing everything that sounded interesting.
As that friction disappears, organizations run a new risk. They can build the wrong things faster.
The product manager's responsibility to understand customers, connect work to strategy, define meaningful outcomes, challenge assumptions, prioritize opportunities, and determine whether something actually created value does not disappear because they can now produce a prototype themselves.
The tools change. The accountability does not.
There is another assumption I think we should reconsider: that product managers and their teams must always organize around product pillars.
Customers do not experience our organizations as product pillars. They experience workflows.
A nonprofit, for example, might think about acquiring a new donor, processing a gift, understanding that donor, deepening the relationship, running a campaign, recruiting volunteers, or demonstrating impact. Those experiences may cross CRM, payments, communications, reporting, data, and other capabilities that the software company has divided into separate products.
A for-profit company has the same issue. A customer might be trying to evaluate a product, purchase it, onboard their organization, invite their team, complete their first successful workflow, expand usage, resolve a problem, or renew their subscription. Internally, those experiences may span Growth, Commerce, Identity, Core Product, Analytics, Support, and Billing.
The customer does not care.
That creates an interesting alternative to permanent ownership of a feature area. Product leaders can own customer workflows, problems, or outcomes that naturally cross the boundaries of individual products.
The software still requires stewardship. Platforms still need owners. Architecture still needs continuity. Products still require people who deeply understand their customers, markets, and long-term direction.
But the work does not always need to inherit the boundaries of the org chart.
One of the things I like most about outcome teams is that they do not need an arbitrary expiration date.
Some problems can be understood and addressed in a few days. Others may require weeks of experimentation and development. The duration should emerge from the work rather than being imposed on it.
That does not mean there is no urgency. Quite the opposite. The team should constantly be asking what it needs to learn next and what the least expensive way is to learn it. What it should not be doing is deciding that it has six weeks and then backing into whatever can be shipped in six weeks.
The core team stays accountable through delivery and measurement. Once the solution is in customers' hands, the work is not suddenly finished because Jira says Done. The team continues watching the outcomes, learning from behavior, and intervening when necessary.
At that stage, however, its members may already have another primary focus. They can participate in another outcome team while continuing to monitor what they previously delivered.
This is not synchronous work marching through identical stages on identical schedules. It is a portfolio of problems and opportunities moving at different speeds, with people contributing where their capabilities create the most value.
That is messier than drawing ten permanent boxes on an organizational chart.
It may also be considerably closer to how innovation actually happens.
For a long time, we built organizations around the constraints of building software. Specialization was expensive, coordination was difficult, and technical boundaries made permanent teams a practical way to manage complexity.
Some of those constraints remain. Others are weakening quickly.
That gives us an opportunity to revisit an idea we have talked about since the early days of Agile but have rarely achieved completely: small, autonomous, genuinely cross-functional teams organized around meaningful work.
The answer is not to eliminate functional expertise or organizational leadership. It is not to turn every employee into an interchangeable generalist. It is not to use AI as justification for cutting a ten-person team to three and expecting the same people to simply do more work.
It is to stop assuming that every problem requires the same predetermined collection of titles.
Start with the strategy. Identify the outcomes that matter. Choose the problems and opportunities worth pursuing. Establish a core group that remains accountable for the outcome, and bring in the capabilities the work actually requires as the team learns more about it.
Then allow that team to explore, experiment, build, measure, and learn.
For years, we have asked what work we should give our product teams.
Perhaps the better question is what team does this outcome deserve?
Wishing you all the best
Mike
AI is too important to become another technology looking for a problem. The real opportunity is to start with outcomes, rethink old processes and assumptions, and use AI where it creates the best solution, rather than making AI itself the strategy.
August 24, 2026 · 8 min read
Read the perspective
AI has shortened how far ahead product teams can plan with confidence. Modern roadmaps should commit to outcomes, not distant features, allowing POCs, evidence, and continuous learning to determine the solutions that ultimately get built.
August 20, 2026 · 13 min read
Read the perspective
Prioritization frameworks help evaluate opportunities, but they can’t make difficult decisions. The real challenge often isn’t knowing what matters most, it’s having the courage to say no to good ideas so the organization can stay focused.
August 12, 2026 · 6 min read
Read the perspective.png)