# Why renaming IT to product didn't fix anything **Author:** Ivan Misic **Published:** 2026-01-14 **URL:** https://ivanmisic.net/blog/product/renaming-it-to-product-didnt-fix-anything **In plain English** Renaming the delivery team to "Product" moves nothing on its own. The real test: can that team tell a senior stakeholder no and make it stick? If the business still hands down the roadmap, you have order-takers with a fresh title. What has to change is authority: real ownership of the outcome, and the backing to say no when it counts. Renaming an IT team to Product changes nothing if the same people still decide what gets built. In one program I worked on, the titles and organization changed while business stakeholders kept the product decisions. Project Managers became Product Managers. Business Analysts became Product Owners. The meetings and approval flow stayed the same. Same meeting. Different org charts. No transformation. ## Run the conference-room test Sit in a meeting where the next product change is being decided. Ignore the titles and follow the decision. Ask: - Who brought the customer problem and evidence? - Who proposed the options and trade-offs? - Who can reject a feature request? - Who owns the result after release? - Which risks require another function to approve or advise? Product should own the customer problem, evidence, and proposed trade-offs. Business, risk, legal, operations, and technology should have explicit decision rights where their accountability applies. The test is whether everyone knows who decides. It is not whether Product decides everything alone. If stakeholders arrive with a feature list and the product team only clarifies scope and estimates delivery, the operating model has not changed. Intent still arrives as an order. ## Ask someone doing the work The conference room can hide the real model. I also ask someone working on a current ticket, usually an engineer, designer, analyst, or tester: 1. What are you building? 2. Why are we building this, and what happens if we do not? 3. How will we know whether it worked after launch, and when will we review the result? Listen for a named customer or business measure, its current baseline, and a review date. “It shipped on time” only measures delivery. If the person knows the feature but not the problem or result, the team is still separated from the product decision. That is an operating-model problem, not a failure by the person answering. ## Titles do not move power The old model survives for practical reasons. People who held decision authority before the reorganization still carry business targets and accountability. A new job title does not remove that responsibility. Product people who spent years receiving requirements may also need time, coaching, and access to customers before they can lead discovery well. Funding pulls in the same direction. A team funded to deliver a fixed project is rewarded for completing scope. It has little room to stop a weak feature or move money toward a better option. Trust takes longer than the org-chart change. Stakeholders remember the team as a delivery function, while the team may still expect decisions to come from above. Both sides can continue the old behavior without choosing it deliberately. ## Look at the symptoms A feature-list roadmap is one warning. Many roadmaps contain features that have not earned their place through customer evidence or a clear outcome. I cover that problem in [The Laundry List Trap](/blog/product/laundry-list-trap-prioritization). Another warning is a team that stays busy while the customer measures do not move. Shipping reliably matters, but output is not evidence that the right problem was solved. Human support is not a failure by itself. A digital product should complete common journeys well and hand complex cases to a person without making the customer start again. The problem appears when the digital layer changes none of the process and adds another place for the customer to get stuck. The blunt test is still useful: can someone with Product in their title say no to a senior stakeholder and make the decision stick? ## Give authority a boundary The answer is not “ask for forgiveness.” Give the team a bounded area where it can test and ship without another steering decision. Define the customer outcome, budget, risk limits, decision rights, and escalation points first. Speed comes from clear authority, not from ignoring accountability. When a stakeholder asks for another feature, I prefer a trade-off question over a flat rejection: > Yes, we can do that. Which agreed outcome should we deprioritize to make room for it? This makes the cost visible. The discussion moves from whether the stakeholder matters to which result matters more now. I explore the authority model further in [Your digital team needs to act like a startup](/blog/product/digital-team-act-like-startup). ## What changed in another program In another program I worked on, leadership gave the digital team a customer problem instead of a feature list. The team could test options, choose what to build, and stop work that was not moving the outcome. When a senior stakeholder pushed for a feature, leadership backed the agreed decision rights. That support mattered more than the title or delivery method. The team still worked with business, operations, technology, risk, and other accountable functions. The difference was that consultation did not quietly become product approval. Changing titles is easier than moving decision authority, funding, and accountability. Check one active product decision this week. If nobody can say who owns it, start there.