G3
Scoped to the brand count
Drop
G3 - Multi-Brand Scale enforces one design system across every brand and market you run, with the line between locked and flexible written into the code. Your portfolio acquires brands faster than anybody can reconcile the design languages inside them, so the argument between local flexibility and brand coherence repeats every quarter, and your unification plan fails because it rests on goodwill that a deadline dissolves. With the Multi-Brand Scale module, we set brand-locked zones the centre owns against flexible zones the region owns, give every brand its own check and threshold, and put drift by brand and market on one portfolio view.
Over a twenty-day pilot in one brand, I proved the boundary holds, and nothing turns on across the portfolio before it does. You keep those zones enforced automatically, and semantic tokens that let a brand switch without breaking the link to the shared library.
Every unification plan I have seen is enforced by agreement, which decays under a deadline. The person who breaks the system is rarely being difficult, and they are usually shipping something on a date somebody senior gave them.
So the system loses to the date, quietly, in a repository nobody outside that team reads until the following quarter.
Enforcement in code changes what has to be true for the system to hold. The boundary between what the centre owns and what the region owns stops being a convention people remember and becomes a condition a change has to satisfy.
Nobody has to police it, and nobody has to be the person who told a regional team their component was wrong.
I built the zoned version of this by hand before it was enforceable in code. At a global carmaker, it was a global-locked brand zone above the fold and a regionally flexible zone below it. That drove 85 per cent shared component reuse across more than thirty markets.
At a merged UK telco, two legacy brands ran from a single dual-brand library, and the newly merged design team used it for every day-one launch.
Two things define the scope, and you already have both. Send me the brand list and one repository per brand, and I will review them before anything else happens.
| Phase | Activities |
|---|---|
| Pilot | The same twenty-day pilot, run against one component family in one brand |
| Zones | Brand-locked zones the centre owns, flexible zones the region owns, boundary enforced in code |
| Tokens | Semantic tokens, so brands switch without breaking the link to the shared library |
| Validation | Each brand given its own check and its own thresholds against a shared core |
| Reporting | Drift by brand and market, in one view, refreshed on every change |
The pilot comes first, and it is the same twenty days that open every other Drop module, not a second one. It establishes the cost of enforcement on a scale you can still walk away from.
Validation and reporting close the sequence in that order. Each brand needs its own checks and thresholds before anything can be reported.
The portfolio view is only worth reading once every brand is measured consistently. That view then refreshes on every change, so drift by brand and market stops being a quarterly discovery.
| The problem | What the enforcement settles |
|---|---|
| Post-merger with several brands and one intended system | One system enforced across every brand, with the boundary between locked and flexible written into the code |
| Global and regional teams disagreeing about flexibility every quarter | Brand-locked zones the centre owns and flexible zones the region owns, enforced automatically |
| A previous unification held for two quarters then unravelled | Enforcement that does not depend on anybody remembering the agreement under a deadline |
| You need one view of consistency across the whole portfolio | Drift by brand and market in one view, refreshed on every change |
When you enforce one system across brands, you surface disagreement that was previously invisible, and that feels worse before it feels better. In the first month, you will see how far apart the brands are, and some of that will be uncomfortable to read.
It is also exactly the information you have been missing. The argument repeats every quarter precisely because nobody has ever had the numbers in front of them while having it.
That said, Drop cannot settle the governance argument for you. Where the boundary sits between locked and flexible is an executive decision, and I own that call under Product Portfolio Consolidation.
The technical answer follows from that call, and Drop holds the line afterwards, a different job entirely.
This is one of three modules under Drop, which carries the offer, the escrow position and the price. The same pilot opens all three.
If your problem is a system several brands agreed to but nobody enforces, this module is for you. It opens with the same pilot as every other Drop module.
If you do not yet know how far the brands have already drifted, that pilot is sold on its own as Design Drift Remediation. Start there.
If the portfolio has no defined system to share yet, then Design System Unification is for you, and it comes before this one.
If the boundary between locked and flexible is still an open executive question, then Product Portfolio Consolidation is for you, and it belongs ahead of all of them. Once you make that call, and nothing measures whether it holds, Design Governance and Assurance is the one you want.