The trigger for introducing a Change Advisory Board wasn’t a single incident. It was a pattern that became impossible to ignore.
Feature requests were arriving from multiple directions — some with clear context and ownership, others more informal. A pain point someone had noticed, a process they found inefficient, an idea that seemed worth improving. At a company growing its digital product function, this is normal. The volume of demand always increases before the structure to manage it does.
Over time, a few things started to surface. It wasn’t always straightforward to trace a feature back to a specific business need. Requirements sometimes clarified during development rather than before it. Teams occasionally moved in parallel without full visibility into each other’s work — not through any fault, but because there was no structured moment for that visibility to happen before the build began. And some of the most valuable initiatives — the ones that required coordination across marketing, commercial, and product — were the hardest to prioritise alongside simpler, more self-contained requests.
None of this was unusual. It’s what scaling looks like before the governance catches up.
The Change Advisory Board was my response to that gap.
What the CAB is — and what it isn’t
The CAB isn’t a gate designed to slow things down, and it’s not a committee where decisions get deferred indefinitely. It’s a formal intake point — the moment where an idea becomes something the organisation has reviewed and chosen to act on.
Every feature request now goes through the CAB before it enters the development queue. We look at three things: whether there’s a clear business case, whether the requirements are defined enough to build from, and whether the work aligns with or conflicts with existing priorities. The output is a decision — build it (and when), defer it, or decline it.
That third option matters more than it initially sounds. Having an explicit way to decide what not to build is what keeps the backlog from becoming a list of things that were once requested, rather than a reflection of what the business actually needs.
Why this shifted the dynamic
Requiring a business case changed the nature of what came through. Not because it filtered out genuine needs — it’s that it encouraged people to articulate those needs in terms of value and timing rather than urgency alone. A well-framed request is easier to prioritise, easier to scope, and easier to build than one that arrives as a general direction.
The visibility shift was equally significant. Before the CAB, teams could move forward on parallel work without always seeing the full picture. Now, the same discussion happens in one place, with shared context, before development begins. The moments where two teams might have built adjacent or conflicting things now surface as a conversation in the room — not as a problem in production.
For the development team, the practical change was immediate: clearer requirements, defined ownership, and a prioritised queue rather than a continuously shifting set of competing asks.
What made it a process rather than just a meeting
Three decisions determined whether this became a working system or an ignored formality.
The first was consistency. Every request goes through the CAB — there’s no alternative route into the development queue. A process with easy exceptions trains people to find the exceptions rather than engage with the process.
The second was making decisions visible. Build, defer, or decline — each outcome is recorded and accessible. This creates accountability and prevents the same ground being relitigated when a request comes back around.
The third was authority. The people in the room have to be the people who can stand behind the decisions being made. A review board where attendees can observe but not decide produces theatre, not outcomes.
What it changed for me
The CAB shifted how I work as a Product Owner. Rather than responding primarily to work already in motion, I now have genuine influence over what enters the queue in the first place. That’s a different kind of product ownership — less reactive, more deliberate.
It also created something I’d underestimated: a regular, structured moment for cross-team alignment that doesn’t depend on anyone remembering to have the conversation. Marketing, commercial, and operations now share a common view of what’s being built and why — not because I send them a roadmap update, but because they’re in the room when the decisions get made.
The practical takeaway
If the work your development team is delivering feels increasingly disconnected from business value, or if what determines priority is closer to access than to impact, the fix is rarely a team-level one. It’s usually a signal that the intake process isn’t defined — that there’s no formal point where demand is evaluated before it becomes commitment.
A Change Advisory Board doesn’t slow delivery down. It changes how commitments are made. And that, in practice, changes what gets delivered.
