From tickets to outcomes: building product thinking in a GCC

Many GCC teams can tell you exactly how many tickets they closed last sprint. Far fewer can tell you whether the product got better for the people who use it. That gap is the difference between a delivery team and a product team, and it is one of the clearest signals HQ uses to decide who owns what.

As global organisations move whole products to their India centres, the expectation changes. Teams are no longer judged only on whether they built what was asked. They are judged on whether they understood the problem well enough to build the right thing.

Why the shift is hard for GCC teams

Many centres began with a clear division of labour. Product decisions were made at HQ; India received a backlog and delivered it well. Engineers learned to estimate, build and test precisely, and were rewarded for predictability.

Those are valuable skills, but they can make the shift to product ownership uncomfortable. When the backlog stops arriving fully formed, teams used to clear specifications can feel exposed. Without help, they often recreate the old model by asking HQ for more detailed requirements.

The shift also needs access. Product thinking is impossible without contact with users, data on how the product is used and visibility of the commercial goals behind it. Centres that keep India teams away from customers and data will struggle, however good the training.

---

What product thinking looks like in practice

Product thinking is not a job title. It is a set of habits that product owners, engineers, designers and analysts can all practise.

Five product thinking practices

2. 1Understand usersTalk to them, watch the data
3. 2Frame the problemBefore choosing a solution
4. 3Prioritise openlyClear trade-offs and evidence
5. 4Measure outcomesNot output or effort
6. 5Experiment smallLearn before building big

Better products, owned in India

Understand users and the business

Teams that understand who uses the product, what they are trying to get done and how the product makes money make better decisions at every level. Even a few customer conversations a quarter, or regular reviews of usage data, change how engineers think about their work.

Frame the problem before the solution

A good problem statement describes who is affected, what they struggle with and why it matters, without naming a feature. It opens up options. “Users abandon onboarding at the identity check” invites several possible fixes; “build a new identity screen” invites one.

Prioritise with visible trade-offs

Every roadmap is a set of choices. Product-minded teams make those choices explicit: what we are doing, what we are not doing, and why. That transparency is what lets HQ product leaders trust India teams with prioritisation.

---

From output to outcome

The most practical change a centre can make is in what it measures. Output metrics, such as tickets closed, story points or features shipped, tell you how busy a team is. Outcome metrics tell you whether the work mattered.

Output focus

Outcome focus

• How many tickets did we close?Did the change improve the user’s task?
• Did we hit the release date?Did the release move the metric we targeted?
• What does HQ want next?What problem should we solve next, and why?
• Is the spec complete?Do we understand the problem well enough?
• Was the estimate accurate?What did we learn, and what will we change?

Outcome metrics do not replace delivery discipline. A team still needs to ship predictably. But when every piece of work is linked to an outcome, conversations with HQ change. India teams start proposing work rather than waiting for it.

Run small experiments

Product thinking thrives on learning cheaply. Instead of building a large feature on assumption, teams test the riskiest idea first: a prototype, a limited rollout, a simple data check. Small experiments reduce waste and build the evidence that persuades stakeholders.

---

How to start in your centre

Changing how a whole centre works takes time. A focused pilot is more effective than a broad mandate.

1. Choose one product team with a supportive HQ product leader and reasonable access to users or data.
2. Agree one outcome metric with that leader, something the team can influence within a quarter.
3. Train the whole team together, including engineers and testers, not just the product owner. Product thinking is a team habit.
4. Hold a monthly outcome review where the team presents what it learned and what it will change, rather than a status update.
5. Share the story. When the pilot team moves its metric, use it to make the case for extending the approach to other teams.

Over time, the centre’s reputation shifts. HQ product leaders stop sending specifications and start sending problems, which is exactly what ownership looks like.

---

What HQ product leaders need to do

Product thinking in India does not develop on its own. It depends heavily on how HQ product leaders work with their India teams, and the centre’s leadership has a role in making that relationship work.

Share the why. Teams cannot think about outcomes if they do not know what the business is trying to achieve. HQ product leaders who share strategy, customer research and commercial goals give India teams the context they need.

Share problems, not just solutions. When product leaders hand over a fully designed feature, they get delivery. When they hand over a problem with clear constraints, they get ideas. Many HQ leaders welcome this shift once they see the quality of thinking that comes back.

Open access to users and data. Even occasional involvement in customer interviews, usability sessions or analytics reviews changes how engineers see their work. Where data access is restricted, agree a safe route rather than keeping teams in the dark.

Include India in decisions. Roadmap reviews and prioritisation discussions are where ownership is visible. Including India product owners and tech leads, even if time zones make it inconvenient, signals that the centre is part of the product team rather than a supplier to it.

The centre’s leadership can help by raising these expectations with HQ sponsors directly, and by showing evidence that India teams are ready for more involvement. A pilot team that has moved an outcome metric is the most persuasive evidence there is.

Signs it is working

You will know product thinking is taking hold when India teams start pushing back on requirements with better alternatives, when engineers ask about usage data unprompted, and when HQ product leaders begin sending problems instead of specifications.