Free Webinar
How to Scale Effective RGM Organizations with Nestlé
.png?width=1600&height=900&name=20250910%20Webinar%20Scale%20RGM%20with%20Nestle%20Banner%20(1).png)
Scaling RGM breaks when it stays a specialist team instead of becoming the business operating system
When “RGM value” becomes a side scorecard
Most organisations can stand up an RGM function. The harder part is what comes next: making it the default way commercial teams plan, review, and decide, rather than a parallel workflow that needs constant justification.
Colin McQuay shares what Nestlé USA learned moving from initial capability build to broad embedment. The focus is the real scaling work: shifting operating model, integrating into planning rhythms, evolving KPIs, redesigning analytics for non experts, and managing behaviour change without letting the programme get swallowed by complexity.
What You'll Learn
- Stop treating operating model as an org chart choice and start treating it as a scaling constraint.
How centralised, hybrid, and decentralised models each create different failure modes, and why most teams move left to right as category pull increases. - Use hybrid to create category centricity, then protect your team’s time like capital.
How Nestlé’s hybrid setup increases adoption while creating boundary and burnout risks, and what to watch so SRM does not become a general scenario modelling service. - Make process integration the anchor, because it forces every other decision to line up.
Why embedding into the business rhythm is harder than building tools, and how short, mid, and long term planning create the clearest connection points. - Move KPIs from “value tracked by SRM” to “business metrics owned by everyone.”
How dollar based scorecards can keep SRM labelled as a project, and how multi metric approaches build shared ownership without creating KPI sprawl. - Democratise analytics with persona design, not training volume.
How shifting from SRM expert tools to end user journeys changes adoption, and why simplicity, speed to answer, and clear competency mapping matter more than advanced features.
Meet The Speaker
 |
Colin McQuaySenior Director, Head of Strategic Revenue Management at Nestlé |
Colin McQuay is Senior Director & Head of Strategic Revenue Management at Nestlé USA. With 16+ years of experience in pricing, PPA, and organizational scale-up, he brings practical expertise in building and embedding RGM as a global growth driver.
Session Highlights
Centralised teams build expertise fast, but they struggle to feel native to the business.
Colin describes why many RGM teams start centralised, then face pressure for category fit and day to day relevance that the model cannot fully satisfy. [02:29]
Hybrid increases adoption by putting SRM closer to business units, but boundaries become the risk.
When SRM heads are dedicated to businesses, stakeholder demand rises quickly. The upside is partnership, the risk is dilution into ad hoc requests and burnout if priorities are not protected. [03:32]
Decentralised does not mean no SRM team, it means SRM owns capability while the business owns execution.
In the target state, the SRM group shifts to owning tool evolution, process discipline, and adoption mechanisms, while business units run SRM as part of normal work. [08:52]
A single source of truth is not a data project, it is a decision efficiency play.
Without one way to view promotions, teams spend energy debating the past instead of improving the next plan. In a decentralised model, the central SRM team must still own this foundation and its communication. [09:31]
Process integration is where scaling either becomes real or stays theoretical.
Colin argues the toughest work is not identifying where SRM fits, but making it function in the rhythms of planning and review because it pulls in KPIs, analytics, education, and change management together. [21:39]
Trust grows faster when you show accuracy, show evidence, and admit uncertainty.
He outlines practical ways to build confidence in analytics, including exposing prediction accuracy, sharing repositories of what worked, and being explicit where the model is not confident so teams can test rather than pretend certainty. [40:43]
Q&A
1) Which operating model actually scales best: centralised, hybrid, or decentralised?
Colin frames this as a progression rather than a one time choice. Centralised is often the fastest way to build initial expertise, hybrid improves category centricity and adoption, and the long term goal is decentralised execution with a central team still owning capabilities and evolution. [02:29]
2) In a decentralised model, who owns capability upgrades and tool improvements?
Colin is clear that decentralised does not remove the SRM team. The central group still owns the roadmap, one source of truth standards, tooling evolution, and communication that connects improvements to how decisions must change. [08:52]
3) How do you stop hybrid SRM from becoming a request queue for every modelling question?
He welcomes broad stakeholder demand as a signal of value, but warns about time dilution and burnout. The implication is that hybrid requires explicit boundary management so SRM time is spent embedding SRM into how the business runs, not chasing one off rabbit holes. [04:43]
4) What makes process integration so difficult compared to building an SRM team?
Colin argues standing up a team is comparatively straightforward. The hard part is changing other teams’ work plans, structures, KPIs, and routines so SRM is embedded in month to month, quarter to quarter rhythms. [05:56]
5) How do you integrate SRM into planning rhythms without overcomplicating everything?
He recommends anchoring on a few clear connection points across time horizons: promotions in the short term, price strategy in the mid term, and pack architecture in the long term. Even those three, embedded well, make SRM meaningfully part of how the business is run. [22:18]
6) Is there a silver bullet to build trust in analytics and recommendations?
Colin says no, it is brick by brick. What accelerates trust is transparency: show accuracy scores, share concrete examples of what happened when you tested a change, and be open about where confidence is low so the organisation can learn through testing rather than being sold certainty. [40:39]