Project teams get new names, but the money stays put
A former Verizon VP and other executives explain why product operating models stall when funding and decision rights don't change -- and what CIOs can do about it.
Many enterprises speak fluent product-speak. Product teams, product owners, value streams and outcomes over outputs -- the terms roll easily off the tongue. Org charts have been redrawn, project managers have new titles, and somebody has a slide mapping the business into product lines.
It all looks and sounds good, but too often it's a mirage. The old budgets, bosses and scorecards remain in place. That's where the model starts to stall, and the first clue is usually in the money trail.
Go ahead, ask who can move money from one product to another without writing a new business case.
"If the answer is nobody below the CFO, the enterprise has project funding with product vocabulary on top," says Michael Podgortsev, director of data and AI strategy and a former CTO.
That gap between language and authority is where the product model stalls. Mik Kersten, Planview's chief technology officer and author of Project to Product, calls the result a "ceremonial" product operating model, one where "a product taxonomy is defined, but money, authority, and accountability still flow through the old functional structure."
Giving a product team control over its own money and priorities takes power away from someone, and that's where things tend to quietly stop.
Hersh Tapadia, CEO and co-founder, Allstacks
Where the shift to product teams stalls
Renaming projects as products is easy because it costs nobody anything. "Changing titles and drawing value streams on a slide doesn't threaten anyone, so that part usually goes fine," says Hersh Tapadia, CEO and co-founder of engineering analytics firm Allstacks.
"Giving a product team control over its own money and priorities takes power away from someone, and that's where things tend to quietly stop," he said.
Abby Knowles saw that from the inside. In her previous role as vice president of global technology for Verizon Consumer Group, she led a three-year product model transformation that produced uneven results.
"Some product areas never matured and were product in name only," says Knowles, now founder and principal of ASKTech Works and a fractional C-suite advisor.
The bigger threat was leadership churn: three Verizon Consumer Group CEO changes and three business sponsor changes during the program, "and every new leader asked for proof." The effort survived, she says, because business and IT had already been combined through relationships, and "their own teams pitched to keep going."
Other organizations never get that far. Tapadia describes a large fintech with more than 50 products that did the visible work: value streams, an Agile framework, dashboards and AI coding assistants. Funding and decision-making stayed where they were, and business units that didn't want to change didn't have to. As the mandate wound down, a client employee called it "a false finish line," Tapadia says.
Another stall point comes after launch. Nishanth Sirikonda, a cloud and enterprise architect at FirstDay Foundation, says leadership often declares a platform project "done" and rebrands everything left over as support. "Labeling that ongoing work as mere maintenance completely ignores the decisions and funding required to keep a platform valuable."
AI is making the mismatch harder to hide. A team that can now build a feature in days "can still wait a quarter for a funding gate, an architecture review board, and a change advisory board," says Prayaag Kasundra, CEO of engineering services firm Simform. "Coding was never the bottleneck."
Make product funding work for finance
The budgeting fix is to replace the control, not just remove it. Several sources favor sustained product-team funding over annual project budgets, even as finance resists giving up familiar controls. Podgortsev argues the CFO's pushback is rarely conservatism. "It is that nobody replaced the control the business case used to provide, so finance is asked to give up its only instrument and gets nothing back."
His alternative: each product recommits quarterly against a published outcome measure, so the CFO reviews results four times a year instead of approving scope once.
Thomas DeFabrizio, CFO Americas at Vertage, agrees from the finance chair. "The CFO's role is not to fund something forever. It is to create enough continuity that the team can improve the product without having to rebuild the case every few months."
Tapadia recommends monthly spending reports by product and type of work while retaining the records finance needs for software capitalization. Kasundra points to another structural snag: build and run spending are often tracked separately, reinforcing the divide between the team that develops a product and the team that operates it. He favors tracking both at the product level.
At Verizon, Knowles says, the turning point was earning the CFO team's trust in year two. "After that, leadership changes did not easily derail us, because the money already moved that way."
Give product owners the authority to say no
Product owners must have the authority to say no. Several sources offered that as a practical test.
The CIO has to back the product owner publicly. Teams are watching to see whose decision sticks.
Dheeraj Garg, chief delivery officer, Kanerika
"The product owner has to be able to say no to a senior stakeholder and make it stick," says Arjun Jaggi, an industry executive in AI and an applied AI researcher. Dheeraj Garg, chief delivery officer at Kanerika, puts the moment of truth on the CIO. When someone influential wants to jump the queue, "the CIO has to back the product owner publicly," he says. "Teams are watching to see whose decision sticks."
Knowles offers a view she admits is "unpopular in technology circles": the business owns the customer relationship, so the product owner sits in the business. Verizon paired each one with a technical product owner to translate technology into business outcomes and trained both.
Measure results, not activity
CIOs also need to stop rewarding activity alone. "One of the easiest ways to kill a product model is to tell teams to optimize for outcomes and then reward leaders for utilization, project completion and staying inside a scope somebody defined twelve months earlier," says Aaron Hutten, CTO of Studio Science. DeFabrizio is blunter: "If the team can hit every IT metric while the economics do not change, you are measuring activity."
Tapadia warns that AI adoption numbers are becoming the next velocity trap, since seat counts and suggestion acceptance rates say little about value. Jason Gold, who advises public-company CEOs and CFOs at Resurge Investor Relations, adds a caution for business cases built on productivity: time saved "isn't a cash saving unless spending actually falls."
Make decision rights stick
Document decision rights and make budgets match. Conflicts usually come from authority that was never formally reassigned, Tapadia says. The project management office still approves scope changes, or a shared-services vice president still controls the engineers. "I'd write the decision rights down, publish them, and then make the budget match. If a shared function keeps overruling product teams, moving the budget line tends to settle it faster than another round of meetings."
Kasundra goes further. Decision rights that live in a RACI chart get overridden the first time a senior stakeholder disagrees, he says, so risk, security and architecture policies belong in the delivery pipeline as automated checks. The CIO's hardest job, in his view, "is standing down the change advisory board once the controls are automated."
Automating routine policy checks does not, however, remove the need to review high-risk, regulated or cross-system changes.
The year-one test
None of this requires converting the whole enterprise at once. Several sources recommended starting with two or three products, each with a stable team, a sustained budget, an owner with published decision rights and a small set of outcome measures that business and IT share.
The proof isn't a new org chart. Podgortsev's benchmark is "one visible kill, a product stopped on its numbers instead of carried because its budget was already signed." Jaggi's is simpler: "a business stakeholder who got told no and actually lived with it."
Knowles points to something no framework supplies. When technology leaders redesigned the org chart themselves, "without executive dictate, their teams owned it in a new way." A product operating model isn't installed on an organization. It's a transfer of power, and it becomes real only when the people who held that power let it go.
Pam Baker is a freelance journalist and the author of books including ChatGPT For Dummies andGenerative AI For Dummies. Baker is also an instructor on AI topics for LinkedIn Learning and a member of the National Press Club, the Society of Professional Journalists and the Internet Press Guild.
