Rather than restructure the whole organization at once, Palace Hotels' transformation began with a single pilot team — a future PM, a designer, and engineers — assigned to a customer-facing but non-critical area, coached directly by an external coach (Gabby) for at least 1.5 hours a week.
The bar for the pilot was explicitly political as well as technical: leadership had to be amazed, and floor staff had to want to join the team. A successful pilot is a persuasion device, not just a delivery unit — it converts skeptics by example rather than argument. At Palace, this pilot (a booking-experience team) is the source of the Discovery (Product Discovery Process) case study that led to abandoning a planned booking app.
Because a single pilot's success 'couldn't scale' on its own, it had to be followed by structural investment — hiring product/data/engineering leadership and changing how funding worked (see VC Seed-Funding Model vs. Corporate Project Model). Contrast with Multi-Team Parallel Assignment for Critical Bets, which assigns multiple teams to a bet already believed critical; the pilot pattern instead uses one low-stakes team to earn that belief.
At Palace Hotels, the pilot team's proving ground was online booking recovery: routing abandoned online bookings into call-center leads rather than losing them. In about two months this produced $600,000 in recovered bookings and, in the process, surfaced a friction point — guest hesitation over entering payment details online — that fed directly back into improving the self-serve booking flow.
This is the concrete "wow" result the pilot-team methodology is built around: a customer-facing but non-critical domain, staffed with strong people, produces a fast and legible win that justifies expanding the model to more teams. See Product Model (vs. Roadmap Model) for the longer-run outcome this fed into (booking-engine conversion rising from under 1% to over 5%), and Product Vision for how the resulting reaction was deliberately cast as recruiting fuel for the next teams.
Rolling the product model out organization-wide before it's proven triggers internal resistance — described as the organization producing 'antibodies' against the change. Piloting with one or two teams first, before any wider mandate, avoids this immune response.
Pilot participants must also opt in voluntarily: assigning unwilling people to the pilot guarantees failure, since the pilot's entire value is demonstrating what the model looks like when people actually want to work that way.
The pilot works as an internal A/B test only if staffing is deliberate: pick one or two teams, staff them with people who already want to work this way and opt in voluntarily, and pair the team with a leader who will actually support the model rather than quietly reverting to status-checking. 'You will not be successful if you have people who don't want to work this way' — coercing skeptics into the pilot poisons the read on whether the model itself works.
A complication for staging a wider rollout: once someone has worked inside the product model, it is reportedly hard for them to go back to being told what to build. That one-way preference shift is a reason to treat the pilot's people carefully — they may not tolerate being rotated back into a directive model once the pilot ends, which raises the stakes of promising 'trial' participation that turns out to be permanent.
Pilot teams should be given room for both new-value and existing-value work (see Three Buckets of Product Work: New, Existing, Protect Value), not just innovation — the point of the pilot isn't only to prove the model can ship features, but to test whether it fits the organization's culture before a company-wide rollout.
Cagan gives concrete selection criteria for the pilot team: pick one to three teams with the right skills, an ambitious-but-achievable goal, and — critically — no blocking cross-team dependencies (see Cross-Team Dependency Pre-Alignment Cycle), so the pilot can't be stalled by parts of the org that haven't bought in yet. A cited example: a Mexican pilot team drove a 40% revenue boost in a single quarter, which was then used to build political support for the wider transformation.
The framing is explicitly time-pressured: a transformation has a "clock" — political patience and executive sponsorship run out — so the pilot must produce demonstrable results before that clock runs out, not just prove the model works in principle.
Choosing which team(s) run the pilot is itself a decision with a checklist, not a default to the organization's 'favorite' or most visible team:
Missing any of these turns the pilot into a false negative (or false positive) about whether the transformation model itself works, independent of the chosen team. See Cross-Team Dependency Pre-Alignment Cycle for the related discipline of clearing dependencies before committing a team.
Cagan describes transformation spreading in discrete stages, each earning more trust from leadership before the next unlocks: pilot team → tribe/group → business unit → company. The pilot isn't just an isolated proof of concept — its success is the currency that buys permission to expand to the next stage. See Bank of Trust, Believers vs. Doubters (Transformation Stakeholder Split).
Cagan frames the multi-level transformation as unlocking levels in a game: a single pilot team proves the model works, then the practice spreads to a tribe/group, then a business unit, then the whole company — never attempted all at once. He calls a pilot team a "gentle deployment mechanism," likening it to "an A/B test in a company": it lets skeptics see results before being asked to change. The staffing detail matters — a pilot team must be staffed with people who already have empowered-team skills (hired in, or brought in via an external coach); staffing it with people who don't yet have those skills is, in his words, "a recipe for failure."
Из тем: Transformation in Practice