Dual transformation is the operating model you run after you have made the strategic call to build an agent-native successor to your legacy product. It is not a gradual evolution of the old product. It is two products on two clocks, with a published sunset on the legacy. Try to evolve the legacy slowly into the successor and you end up with one product that is bad at both jobs.
Two clocks
The legacy clock is a six-week cycle: a week of planning, three of build, one to stabilize, one to release, with quarterly OKRs and NRR reviews. Do not modernize it. The legacy is paying payroll and predictability is its job.
The successor clock is a one-week cycle: eval review Monday morning, build with continuous deploy through midweek, an outcome cohort review, ship behind quality gates, and a weekly outcome retro. It has to be this tight because agent products are non-deterministic, inference economics move, and the buyer is still teaching you what they want.
Three talent categories and six numbers
Hard fences, no rotation. Maintenance keeps the lights on and builds migration tooling. The successor team builds, evaluates, and ships. Bridge engineers are senior ICs who own the integration points and sit in both teams' rituals on alternating weeks. People know which team they are on for the next 12 to 24 months.
The CEO sees six numbers every week, side by side: legacy revenue, NRR, and gross margin next to successor outcome volume, gross margin per outcome, and percent of legacy revenue migrated. The blended margin is shown but is not the headline. The migration percentage is.
What I got wrong
Three failures I keep on the wall. One, I ran dual transformation without naming it, and the team did not know they were on two clocks. Naming the model bought four months of execution speed once I did it. Two, I let bridge engineering be a side activity for rotating volunteers, so it became nobody's job and integration broke. Three, I underestimated the political weight of the legacy team. The fix that worked was asking the legacy team's senior engineers to own the migration tooling, so they became the people who built the bridge customers crossed.
What to do this week
Take one weekly ritual on your legacy product and write down its cadence in plain English. Then imagine running the same ritual for an agent-native product where eval drift can happen daily. The gap between those two answers is your dual transformation problem in miniature. Then have the hard-fences-versus-rotation conversation with your CTO, and if you have been rotating engineers quarterly, use the next 90 days to stop.