Back to articles
03.08 — The product operating model: moving beyond feature teams
·12 min read

The product operating model: moving beyond feature teams

JB · jarodbarrera.comDRAWING NO. PO-01 · 01 OF 01THE PRODUCT TABLE OF ELEMENTSSix elements every real product organization runs on. Missing any? You’re running project management with new vocabulary.Pr01Problem DiscoveryContinuous contact with customers. Teams own the problem, not the feature backlog.St02Strategy + BetsExplicit hypotheses about how the product wins. Teams know which ones they’re testing.Tm03Empowered TeamsPM, designer, engineer in a trio. Given a problem, not a feature. Trusted with the outcome.Fn04Funding CadenceBets get funded for periods, not for projects. You re-fund based on what was learned.Ms05Outcome MeasurementSuccess is whether the metric moved, not whether the ticket closed. Velocity is not the goal.Ld06Leadership PostureLeaders set the problem and the success metric. They do NOT dictate the solution.Renaming the project manager to product manager does not install the operating system.

There's a pattern I keep encountering in product organizations, and it's becoming more pronounced as teams adopt AI tooling. Companies reorganize around "product teams," hire PMs, adopt agile ceremonies, and call themselves product-led. But the underlying operating model hasn't changed. They're still feature teams running a project management process, just with fancier titles.

Melissa Perri diagnosed this years ago. The build trap. But I think the problem has evolved since she wrote that book, and AI is making the gap between genuine product organizations and cosplay product organizations more visible.

What a product operating model actually is

Let me define terms, because "product operating model" gets thrown around loosely.

A product operating model is the system by which a company decides what to build, funds the work, organizes the people, and measures success. It's not the same as "having product managers" or "doing sprints." It's the entire system of decision-making and accountability around product.

In a genuine product operating model, teams are given problems to solve and the autonomy to find solutions. Product strategy flows from company strategy. Teams are funded to pursue outcomes, not to deliver features. And the measure of success is business impact, not delivery velocity.

In the more common pseudo-product operating model, teams are told what to build by stakeholders. The "product strategy" is a list of features compiled from sales requests and executive pet projects. Teams are measured by whether they shipped on time. And the PM's actual job is project management with a product title.

How AI exposes the gap

Here's what's interesting. When AI tools make execution faster, the difference between these two models becomes impossible to ignore.

In a genuine product organization, faster execution means faster learning. Teams can run more experiments, validate hypotheses quicker, and iterate on solutions more rapidly. The time saved on building gets redirected toward discovery, analysis, and strategic thinking. The product gets better faster.

In a pseudo-product organization, faster execution means more features shipped. Teams clear the backlog quicker, so stakeholders pile on more requests. The time saved on building gets consumed by more building. Nobody stops to ask whether any of it is working. The product gets bigger faster, but not necessarily better.

I watched this happen at a company last year. They invested heavily in AI development tools and cut their average feature delivery time in half. The CEO was thrilled. But their retention metrics didn't improve, their NPS barely moved, and customer support tickets actually increased because the product was getting more complex without getting more useful.

The tools worked exactly as designed. The operating model was the problem.

JB · jarodbarrera.comDRAWING NO. PO-02 · FIG 1TWO OPERATING RHYTHMSProject mode runs a sequence. Product mode runs a loop. The difference compounds every quarter.PROJECT MODE · sequential, no loopSCOPEESTIMATESHIPNEXT PROJECTSuccess = ship on time, on scope. No mechanism to learn whether shipped feature actually mattered.PRODUCT MODE · continuous loopDISCOVERBETSHIPMEASURERE-FUNDSuccess = what was learned from the last loop. The next cycle is funded based on signal, not on plan.Project mode optimizes delivery. Product mode optimizes learning.

The same AI tooling investment, the same talented engineers, the same market opportunity. Completely different outcomes based on the operating model surrounding the work.

The components of a working product operating model

Based on what I've seen work across different organizations, five components distinguish a real product operating model from the imitation.

JB · jarodbarrera.comDRAWING NO. PO-03 · FIG 2THE STACKEach layer depends on the one below. Remove the foundation, the layers above collapse.L1STRATEGY & BETSexplicit hypotheses about how the product wins this year teams know which bet they’re onL2EMPOWERED TEAMSPM + designer + engineer trio · given a problem, not a feature trusted with the outcomeL3FUNDING + MEASUREMENTmoney flows to bets, not projects · re-funded based on outcome success = metric moved, not ticket closedL4CUSTOMER OUTCOMES (the foundation)everything above this layer derives its meaning from here no customer outcome layer = no product operating model, regardless of titlesBuild top-down, collapse top-down. Build bottom-up, scale bottom-up.

First, product strategy that connects to company strategy. This isn't a feature list. It's a clear articulation of who you're serving, what problems you're solving for them, and how solving those problems drives the business. Every team should be able to explain how their work connects to the company strategy without needing a Miro board and 45 minutes. Most companies have a company strategy and team-level backlogs, but nothing connecting the two. The product strategy is the missing middle layer. Without it, teams make local decisions that don't add up to a coherent product.

Second, outcome-based team missions. Each product team should own a meaningful outcome, not a feature area. "Reduce time to first value for new customers" is a mission. "Own the onboarding flows" is a feature area. The difference matters because missions create accountability for impact, while feature areas create accountability for maintenance. Marty Cagan emphasizes this distinction in his work on empowered teams: the difference between a feature team and an empowered product team starts with whether they own an outcome or a backlog.

Third, discovery as a continuous practice, not a phase. In a working product operating model, teams are talking to customers every week -- not because it's a box to check, but because it's how they stay connected to the problems they're supposed to solve. Discovery isn't a project phase that happens before development. It runs in parallel, continuously. Teresa Torres makes this point clearly: the product trio -- PM, designer, and tech lead -- should be doing discovery work together every week. When discovery is a phase that "happens before engineering starts," it becomes something the PM does alone and then hands off. That handoff is where context and nuance die.

Fourth, funding tied to outcomes, not projects. This is the hardest organizational change and the one most companies resist. Instead of funding individual projects with fixed scopes and timelines, fund teams to pursue outcomes for a sustained period. Give them the resources and time to figure out the right solution. This requires different accountability (showing progress toward the outcome, not through a Gantt chart) and a different kind of trust.

Finally, measurement that goes beyond delivery. Output metrics like features shipped, velocity, and story points should be supplementary, not primary. The primary metrics should be outcome-oriented: did the thing we shipped move the number we care about? If you can't answer that question for most of what your team ships, you have a measurement problem that no amount of tooling will fix.

Diagnosing a pseudo-product operating model

Before you can transition, you need to honestly assess where you are. I've found that a few diagnostic questions cut through the self-deception quickly. Most organizations believe they're running a product operating model because they have the vocabulary. These questions test whether they have the substance.

"Where do most feature ideas originate?" In a genuine product operating model, the majority of what teams build comes from their own discovery work -- customer interviews, data analysis, experimentation. In a pseudo model, the majority comes from stakeholders: sales, the CEO, a large customer's request. Track this for a quarter. If more than 60% of what you build was specified by someone outside the product team, you're running a project model with product titles.

"What happens when a team says no to a stakeholder request?" In a genuine model, this is normal and expected. Teams evaluate requests against their outcome and make a judgment call. In a pseudo model, saying no triggers escalation, political pressure, or the request gets reframed as a "strategic priority" and forced through anyway. If your PMs can't say no without consequences, they don't actually own the product.

"Can your PM describe the top three problems in their problem space without referencing a specific solution?" PMs in genuine product organizations think in terms of problems and opportunities. PMs in pseudo models think in terms of features and timelines. If your PM describes their current focus as "building the reporting dashboard" rather than "helping managers understand team performance so they can intervene earlier," you've got a feature team.

"What percentage of shipped features have a defined success metric that gets reviewed post-launch?" In teams I've worked with that genuinely operate as product teams, this number is above 70%. In pseudo-product organizations, it's often below 20%. If you ship things and never check whether they worked, you're optimizing for output, not outcomes.

"How does the team spend time saved by faster tooling?" This is the AI-specific diagnostic. When engineering velocity improves, do product teams invest the freed capacity in deeper discovery, more experimentation, and strategic analysis? Or does the backlog just get refilled with the next batch of stakeholder requests? The answer tells you what the organization actually values.

Making the transition

Transitioning to a product operating model is an organizational change that takes years, not quarters. But there are starting points that generate momentum.

Start with one team. Find a team with a willing PM, a supportive engineering lead, and a stakeholder who's open to experimentation. Give that team a clear outcome to pursue and the freedom to figure out the approach. Protect them from the feature request pipeline for one quarter. Let them demonstrate what outcome-oriented product work looks like.

I saw this approach work at a mid-size fintech company where one team was given the outcome of reducing churn among SMB customers. For the first three weeks, they did no building at all. They ran observation sessions, analyzed cancellation data, and interviewed churned customers. What they found was that the primary churn driver wasn't missing features -- it was that new customers couldn't get to their first meaningful report within the first week. The existing onboarding flow assumed knowledge that SMB customers didn't have. The team redesigned the first-week experience with guided setup and pre-built templates. Churn in that segment dropped 18% over two quarters. That result became the proof point that convinced the rest of the organization to take the transition seriously. You can't argue with the metric.

Make product strategy visible. Write it down, share it widely, and review it quarterly. Most product organizations don't have a written product strategy, so every team, stakeholder, and executive has their own version of what the product should be. A written strategy creates alignment, even if the strategy itself is imperfect. The act of writing forces clarity. I've seen teams realize during the writing process that their leadership had three mutually exclusive definitions of the target customer. Better to discover that during a strategy exercise than after three teams have spent a quarter building for different audiences.

Shift one planning conversation. In your next quarterly planning, ask "What outcomes should we target?" before asking "What should we build?" It's a small change in the agenda, but it shifts the entire conversation. If the room can't agree on outcomes, that tells you something important about your strategic clarity.

Measure what you ship. Track the impact of features after launch, not just whether they launched on time. This sounds obvious, but most teams can tell me their velocity and ship date accuracy. They cannot tell me whether the last three things they built actually improved any metric. Start by picking three recently shipped features and retroactively measuring their impact. If you can't measure the impact because you didn't define success criteria upfront, that's your first process fix.

Change the incentive structure. This is the step people skip because it's politically uncomfortable. If PMs are still evaluated on features shipped and engineers on story points completed, every other change is cosmetic. People optimize for what they're measured on. Transitioning to a product operating model requires rewarding outcome progress, learning velocity, and strategic clarity -- not throughput. I've watched organizations redesign their entire planning process around outcomes and then undermine it all by keeping the old performance review criteria. The planning process says "pursue outcomes." The review says "ship features." Guess which one wins.

Build executive fluency in outcomes. This is the step most transition guides skip, and it's often the bottleneck. Your VP or C-suite needs to be comfortable reviewing outcome progress instead of feature demos. That means coaching them on what a good outcome review looks like: showing leading indicators, explaining what the team learned, presenting the next set of bets. If executives still expect a walkthrough of shipped features, the team will keep optimizing for what gets rewarded in that room.

The AI opportunity

Here's the optimistic framing. AI creates an opportunity to accelerate the transition to a product operating model, if leaders choose to use it that way.

When execution is faster, teams have more capacity for discovery and strategy work. When data synthesis is easier, outcome measurement becomes more practical. When prototyping is cheaper, experimentation becomes more feasible.

But these benefits only materialize if the organizational model supports them. Giving AI tools to a feature factory makes a faster feature factory. Giving AI tools to an empowered product team amplifies their impact.

The technology won't fix the organization. But the technology creates space for the organization to fix itself, if leaders are willing to use that space for the hard work of organizational change instead of just shipping more features. The companies that use AI's speed dividend to buy time for better thinking will outperform the ones that use it to build more stuff. That's the bet, and I think it's the right one.

This article is part of a series on product management in an AI-transformed landscape.