product operating model
Your team structure determines your product quality. Put a brilliant PM on a feature team and they will build mediocre products. Put an average PM on an empowered team and they will build good ones. The operating model is the invisible hand that shapes everything.
I have watched hundreds of PMs blame themselves for shipping the wrong thing. They read the books, ran the discovery, wrote the hypothesis, designed the experiment. Then leadership handed them a list of features and told them to deliver by Q3.
The PM did not fail. The operating model failed them.
How your company organises product teams — who decides what to build, how success is measured, how much autonomy the team has — matters more than any individual PM’s skill. And most companies in India get this wrong.
Feature teams vs empowered teams
Marty Cagan at SVPG draws a line that every PM needs to understand. There are two fundamentally different ways to organise product work.
Feature teams receive a roadmap of features to build. Product management is project management with a fancier title. The PM writes tickets, tracks timelines, coordinates with engineering, and reports progress. Success means: did you ship the feature on time?
Empowered teams receive problems to solve. The product trio — PM, designer, and tech lead — has the autonomy to discover the right solution. Success means: did the metric move?
This is not a subtle distinction. It changes everything about how a PM spends their day.
| Feature team | Empowered team | |
|---|---|---|
| Input | Roadmap of features from leadership | Problems or outcomes to achieve |
| PM’s role | Coordinate delivery | Discover and validate solutions |
| Designer’s role | Make the spec look nice | Explore solution space with PM |
| Tech lead’s role | Estimate and build | Contribute to solution design |
| Success metric | Shipped on time | Outcome improved |
| Discovery | Minimal or none | Continuous |
| Autonomy | Low — execute the plan | High — own the how |
The product trio is the unit that matters. PM brings the customer and business context. Design brings the user experience lens. The tech lead brings feasibility and architecture knowledge. When these three work as a unit with real autonomy, they produce solutions that none of them could have designed alone.
When leadership dictates the solution and the trio just executes, you have paid three senior people to do the work of one project coordinator.
The Drive Test: why your company structure predicts your product quality
In What Is PM, I introduced the concept of business-driven vs product-driven companies. The operating model is where that distinction becomes concrete.
Business-driven companies almost always run feature teams. Sales closes a deal that requires feature X. The CEO promises it at a conference. A board member saw a competitor launch something. These requests flow down as a roadmap. The PM’s job is to deliver.
Product-driven companies run empowered teams. Leadership sets the strategic context — the vision, the objectives, the constraints. Teams decide how to achieve those objectives. The PM’s job is to solve problems.
If your roadmap is a list of features that came from people who do not talk to users, you are on a feature team. It does not matter what your Confluence page calls it.
India’s feature team problem
Most Indian companies run feature teams and call them “product teams.” This is not a criticism — it is a structural observation. There are specific reasons it happens here.
Founder authority is strong. Indian tech companies tend to concentrate decision-making at the top. The founder or CTO decides what to build. PMs execute. In a 50-person startup, this can work — the founder often has the best product instincts. In a 500-person company, it becomes a bottleneck that produces mediocre products at scale.
Sales-driven roadmaps dominate. Especially in B2B, the sales team controls the product roadmap. Every enterprise deal comes with a list of feature requests. The PM becomes a translator between sales and engineering rather than a strategist who decides which problems are worth solving.
Services-adjacent culture. India’s IT services industry trained two generations of tech workers to take requirements and deliver against them. That mindset does not disappear when someone moves from TCS to a product company. The muscle memory of “receive spec, deliver spec” runs deep — in PMs, in engineers, in leadership.
Hierarchy inhibits bottom-up ownership. When the default response to a senior leader’s idea is “yes sir,” empowered teams cannot function. Empowerment requires that a PM can push back on the VP’s feature request with data and be respected for it. In many Indian orgs, that conversation does not happen.
Quarterly planning at a Series C SaaS company in Bangalore. The PM is proposing a shift from feature roadmaps to outcome-based OKRs.
PM: “Instead of committing to shipping 12 features next quarter, I want to propose we commit to three outcomes. Reduce churn by 15%. Increase activation rate to 40%. Grow enterprise pipeline by 20%.”
CEO: “That sounds nice in theory. But our board wants to see a roadmap. Our sales team has committed features to three enterprise clients. We cannot go back and say we are doing OKRs now.”
PM: “I am not saying we abandon commitments. I am saying we let the team figure out the best way to hit those numbers. Maybe the churn problem is not about the features sales promised — maybe it is about onboarding friction.”
CEO: “And if the team picks the wrong approach and we miss the quarter?”
PM: “Then we learn and adjust. Right now we ship every feature on time and still miss our retention numbers. Shipping is not the problem. Solving is the problem.”
The CEO paused. He was not convinced. But for the first time, someone had named the pattern out loud.
The PM identified the core issue: output is not the same as outcome. But changing a company's operating model is a multi-quarter effort, not a single conversation.
Moving toward empowerment (when you cannot flip a switch)
You do not transform a feature team into an empowered team overnight. If you try, you will get fired or ignored. The shift is incremental, and it starts with earning trust through results.
Step 1: Earn autonomy on one problem. Pick a metric that leadership cares about but nobody owns. Churn rate. Activation. Support ticket volume. Volunteer to own it. Do not ask for permission to do discovery — just do it alongside your feature work. When you find an insight that the roadmap missed, present it with data.
Step 2: Propose a pilot team. Once you have demonstrated that discovery produces better outcomes than just shipping the roadmap, propose a time-boxed experiment. One team, one quarter, measured on outcomes instead of output. Make it low-risk for leadership — pick a problem where failure is survivable.
Step 3: Use OKRs to shift the language. OKRs are a Trojan horse. When leadership defines objectives (what we want to achieve) and teams define key results (how we will measure progress), you have created the structure for empowerment without ever using the word. The team now owns the “how.”
Step 4: Build the product trio. Start working closely with one designer and one tech lead as a unit. Make decisions together. Present together. When leadership sees that this trio produces better work than a PM working alone, the model spreads.
None of this requires a mandate from the CEO. It requires a PM who is willing to demonstrate, not just argue.
The operating model spectrum
Feature teams and empowered teams are not a binary. Most organisations sit somewhere on a spectrum, and different teams within the same company can sit at different points.
Delivery mode. The team receives fully specified features and delivers them. The PM is a project manager. Discovery is zero. This is the left end of the spectrum.
Discovery mode. The team receives a problem area and has some freedom to explore solutions, but leadership still approves the final approach before engineering starts. The PM does discovery but needs sign-off on every decision.
Outcome mode. The team receives an objective and a metric. They own the discovery, the solution design, and the delivery. Leadership reviews progress on the metric, not the feature list. This is the right end of the spectrum.
Most teams I see in India operate between delivery mode and discovery mode. They do some user research, maybe run a survey, but the final roadmap still comes from the top. Moving from discovery mode to outcome mode is the hardest jump — it requires leadership to trust teams with real autonomy.
When feature teams are the right call
Empowered teams are not universally correct. There are situations where feature teams are the right operating model.
Early-stage startups where the founder has the vision. A pre-product-market-fit startup does not need empowered teams. The founder is the product person. They have the conviction and the user intuition. What they need is a team that can execute fast. Imposing outcome-based autonomy on a 10-person team where the founder knows the market better than anyone is overhead, not empowerment.
Regulated industries with compliance requirements. If you are building for banking, healthcare, or government, many of your features are mandated by regulation. There is no discovery to do — the RBI or SEBI tells you what to build. A feature team that executes compliance requirements well is doing exactly what it should.
Acqui-hire integration. When a company acquires a team and needs to integrate their product, the first 6-12 months are execution-heavy. The acquired team needs to align with the parent company’s architecture, standards, and roadmap. Empowerment comes after integration.
Platform teams building infrastructure. Internal platform teams that serve other product teams often work best in delivery mode. Their “customers” are internal engineers who know what they need. The platform PM’s job is to prioritise and deliver, not to discover.
Feature teams are not a disease. They are a tool. They become a problem when applied to product-led companies that need discovery to compete — and when the entire organisation runs on feature teams with no path to empowerment.
The career impact nobody talks about
Your operating model shapes your career more than your title does.
A PM on a feature team develops execution skills. You learn to write specs, manage timelines, coordinate cross-functional teams, handle escalations, and ship reliably. These are real skills. They will make you a strong project-oriented PM. They will not make you a product strategist.
A PM on an empowered team develops strategic skills. You learn to define problems, run discovery, design experiments, interpret data, make trade-offs, and defend your decisions to leadership. These are the skills that get you to senior PM, director, and beyond.
If you have spent three years on a feature team and you want to grow into a strategic PM role, you have a gap. Not a character flaw — a gap in your operating environment. You can close it by doing discovery work outside your official scope, by moving to a company that runs empowered teams, or by creating a pilot within your current org.
If you are choosing between two job offers and one company runs feature teams while the other runs empowered teams, the operating model should weigh heavier than the salary difference. Two years on an empowered team will accelerate your career more than a 30% pay bump on a feature team.
You are a PM at a mid-stage B2B SaaS company in India. Your VP has handed you the Q2 roadmap: five features, all committed to enterprise clients by the sales team. You have done your own research and believe two of those features will not move your team's activation metric — the clients asked for them, but the underlying problem is onboarding friction, not missing features.
Sprint planning is next Monday. Engineering is ready to start on the five features. Your VP expects a delivery timeline.
your path
You joined Zerodha's product team six months ago as a PM. The engineering team is highly autonomous — they ship without detailed specs, move fast, and push back on feature requests that do not have clear user evidence. Leadership says the team is 'empowered.' But in practice, you notice the CEO reviews every major design decision before it ships, and in three separate instances this quarter a feature was redirected mid-sprint because of a CEO walkthrough. The team calls themselves empowered. The process says otherwise.
The call: You are about to kick off discovery for a new investing onboarding flow. Do you proceed with the standard empowered-team process (define outcomes, run discovery, propose solutions), or do you first seek clarity on decision rights — specifically, who has final say on the design before engineering starts?
You joined Zerodha's product team six months ago as a PM. The engineering team is highly autonomous — they ship without detailed specs, move fast, and push back on feature requests that do not have clear user evidence. Leadership says the team is 'empowered.' But in practice, you notice the CEO reviews every major design decision before it ships, and in three separate instances this quarter a feature was redirected mid-sprint because of a CEO walkthrough. The team calls themselves empowered. The process says otherwise.
The call: You are about to kick off discovery for a new investing onboarding flow. Do you proceed with the standard empowered-team process (define outcomes, run discovery, propose solutions), or do you first seek clarity on decision rights — specifically, who has final say on the design before engineering starts?
Diagnosing your team’s operating model
Most PMs cannot accurately describe their own operating model. They use the language of empowerment because their company’s job posting used it. The following exercise cuts through the language to the reality.
Answer these five questions honestly about your current team. Score each one.
1. Where does your roadmap come from?
- (A) Leadership or sales hands it to me — I execute it
- (B) I propose items, but leadership decides what makes the cut
- (C) I own the roadmap based on problems my team has identified
2. How is your team’s success measured?
- (A) Features shipped on time
- (B) A mix of delivery milestones and business metrics
- (C) Business outcomes — the feature list is a means, not the measure
3. How much discovery does your team do?
- (A) Minimal — we validate designs, not problems
- (B) Some — we do user research but solutions are often pre-determined
- (C) Continuous — discovery runs in parallel with delivery every sprint
4. Can you kill a feature that leadership requested?
- (A) No — what comes down, gets built
- (B) I can push back, but it rarely changes the outcome
- (C) Yes — if data shows it will not work, the team decides
5. Who defines the solution?
- (A) It is defined before it reaches my team
- (B) I define it with input from design and engineering
- (C) The product trio — PM, designer, tech lead — defines it together
Scoring:
- Mostly A: You are on a feature team. Your growth path is to earn autonomy through results.
- Mostly B: You are in discovery mode. Push for outcome ownership on one initiative.
- Mostly C: You are on an empowered team. Protect that autonomy — it is rarer than you think.
The operating model is your responsibility
You cannot control whether your company runs feature teams or empowered teams. But you can control how you respond to the model you are in.
If you are on a feature team, stop complaining about it in Slack threads and start demonstrating what discovery can produce. One insight that the roadmap missed. One experiment that outperformed a committed feature. One quarter where your metric moved because you did the work nobody asked you to do.
If you are on an empowered team, do not take it for granted. Empowerment can be revoked the moment a team misses its numbers two quarters in a row. The price of autonomy is results.
And if you are a leader building a PM team — the operating model is the single highest-impact decision you will make. Not the hiring bar. Not the process. Not the tools. The model. Get it right and average PMs will produce above-average products. Get it wrong and your best PMs will leave for companies that let them do the job.
Where to go next
- Understand the company types that shape operating models: What Is PM
- Build the execution skills that earn autonomy: Working with Engineering
- Design a PM org that supports empowered teams: Building a PM Team
- Navigate the transition from executor to strategist: IC to Senior