Dual Transformation: Running Two Clocks
Two cadences, three talent categories, six CEO scoreboard numbers, three rituals. The operating model that runs legacy and successor cleanly.
The cannibalization decision is the strategic call. Dual transformation is what you actually run after the call.
This chapter is the operating model. Two cadences, three talent categories, six CEO scoreboard numbers, three rituals. The companion essay The Dual Transformation Operating Model carries the rhetoric. This chapter is the operating practice you can put on the wall.
The two clocks
The legacy clock (six-week cycle)
This is what the legacy product was probably already doing. Don't change it.
| Week | Activity |
|---|---|
| 1 | Planning, release prep |
| 2 | Build |
| 3 | Build |
| 4 | Build |
| 5 | Stabilize, customer pilot |
| 6 | Release, retro, customer health review |
Quarterly: OKR planning, NRR reviews with sales, pricing review. Annual: strategy review, customer advisory board, comp plan.
The legacy product is paying payroll. Predictability is its job. Resist the temptation to "modernize" the legacy cadence. It works. Leave it.
The successor clock (one-week cycle)
This is dramatically tighter than the legacy cadence. It needs to be. Agent products are non-deterministic, inference economics move, and the buyer is still teaching you what they want.
| Day | Activity |
|---|---|
| 1 (morning) | Eval review (overnight runs, drift, regressions) |
| 1-3 | Build, with continuous deploy to staging |
| 3 | Outcome cohort review (last 7 days, dispute reviews) |
| 4-5 | Ship to production behind quality gates |
| 5 | Weekly outcome retro |
Monthly: pricing experiments, agent department reviews, NPS on the successor. Quarterly: strategic review, gross margin review per outcome, hiring plan.
Cross-team rituals on alternating weeks
The danger of two clocks is that the teams stop talking. Fix: one architecture review, one security review, one infrastructure review, one customer escalation review per fortnight, alternating between the teams' weeks.
| Even weeks | Odd weeks |
|---|---|
| Legacy customer escalation | Agent customer escalation |
| Agent infrastructure review | Legacy architecture review |
Both teams are in both rituals (with rotating leads), so context flows. Neither team has to be in two same-day standups.
The three talent categories
Hard fences. No rotation. This is the highest-leverage decision in dual transformation.
Maintenance team (5-15% of engineering)
Dedicated to the legacy product. Keep the lights on, fix critical bugs, support escalations, maintain infrastructure. Do not ship features. Mandate is stability and migration tooling, not feature velocity. Bonus rewards uptime, dispute-rate reduction, and migration tool adoption.
Successor team (60-75%)
Dedicated to the agent-native product. Build, evaluate, ship. Includes agent specialists, ML engineers, prompt engineers, design engineers, FDEs working with early customers. Bonus rewards customer outcomes, eval quality, shipping velocity.
Bridge engineers (5-10%)
Senior ICs who own integration points: shared data, auth, identity, infrastructure, observability. Report to CTO or VP Eng directly. Sit in both teams' rituals on alternating weeks. The only people writing code that affects both products. Bonus tied to migration percentage (so they care about successor success) and to legacy uptime (so they don't break payroll).
The rotation mistake
Quarterly rotation of engineers between legacy and successor sounds fair. It destroys both teams' momentum. Engineers in motion lose context on what they were building. Engineers staying lose teammates and slow down. Six months in, both products are slow and the team is exhausted.
Hard fences. People know which team they're on for the next 12-24 months. They can opt to move, but the move requires a clean cutover, not a partial allocation. Bridge engineers exist precisely so that rotation isn't necessary.
The CEO scoreboard
Six numbers, every week, side by side.
Legacy:
- Revenue
- NRR
- Gross margin
Successor:
- Outcome volume
- Gross margin per outcome
- Percent of legacy revenue migrated
The blended margin is calculated and shown but it's not the headline. The headline is the migration percentage.
Why this set? Each number is owned by a different person, and the contradictions between them surface the operational tensions that are otherwise invisible. NRR on legacy and migration percentage will move in opposite directions if the transition is working. Gross margin per outcome will be low and gradually rising. Revenue on legacy will gently decline; outcome volume on successor will exponentially climb. The blended margin will dip into the trough and recover.
Show all six together every week. Don't average them.
The three rituals
Beyond cadences and talent rules, three rituals do most of the work in keeping the clocks from colliding.
Ritual 1: The Friday Read-Out
15 minutes, every Friday. Each team's lead presents three things: what shipped this week, what's blocked, what changed in customer signal. CEO and CPO are in the room. Everyone else is optional.
The point is not status reporting. The point is to surface mid-week conflicts before they harden into Monday all-hands disasters.
Ritual 2: The Sunset Drumbeat
Once a month, the CPO writes a short memo to the entire company titled "Sunset Drumbeat." Three sections: where we are on migration percentage, what's working, what's hard. Named call-outs (engineer who shipped a great migration tool, salesperson who closed a successor deal). Short, public, signed.
The point is keeping the sunset visible. Without this drumbeat, the legacy team and the successor team start to feel like separate companies.
Ritual 3: The Quarterly Reality Check
Once a quarter, the CPO does an honest review of the two clocks with the leadership team. Three questions:
- Are the cadences still right?
- Is the talent allocation still right?
- Are we still on the published sunset date?
The reality check is hard because it forces the team to admit when something isn't working. The cost of avoiding it is higher.
What I have learned by getting this wrong
Three failures, kept here so you don't repeat them.
One: I tried dual transformation without naming it as dual transformation. Internally we called it "evolving the product." The team didn't know they were on two clocks. Naming the model is a leadership move, not a labeling exercise. Tell the team. Show them the cadences. The clarity buys you four months of execution speed.
Two: I let bridge engineering be a side activity for senior people instead of their main job. It got staffed with rotating volunteers. Predictably, it became nobody's job. Integration broke. Auth broke. Observability gaps showed up in customer escalations. Bridge engineering needs to be an explicit role with explicit owners and explicit calendar time.
Three: I underestimated the political weight of the legacy product team. They had been the company's identity for years. Treating them as "maintenance" felt insulting, even when the work was honest. Fix that worked: I asked the legacy team's senior engineers to own the migration tooling itself. They became the people who built the bridge customers crossed to get to the successor. That gave them a heroic story to tell about their last 18 months on the legacy product.
What to do this week
Take any one weekly ritual on your legacy product (sprint review, weekly customer health review). Write down its current cadence in plain English. Then imagine running the same ritual for an agent-native product where eval drift can happen daily. What would change in frequency, content, decision rights?
The gap between those two answers is your dual transformation problem in miniature. If you can't reconcile the gap with one ritual, you cannot reconcile it for the whole product line on one clock.
Have the conversation with your CTO or VP Eng about hard fences vs. rotation. If you've been rotating engineers between products quarterly, the next 90 days are a window to stop. Set fences. Define bridge engineering. Publish the sunset date if it isn't already published.
The two-clock model is not glamorous. It is the difference between a transition that works and one that quietly fails for six quarters before being declared a strategic pivot.
The companion blog essay is The Dual Transformation Operating Model. The Operating Cadence template is at /toolkit/dual-transformation-operating-cadence. For the strategy that precedes this operating model, see /handbook/cannibalization-decision-framework.
Frequently asked
Why two clocks instead of one?+
Because the businesses operate at different speeds. Legacy SaaS runs on six-week release cycles, quarterly OKRs, seat-based forecasting. Agent-native runs on daily prompt iteration, weekly eval gates, monthly outcome accounting. Forcing both onto one clock means either the legacy slows the new product or the new product disrupts the legacy's predictability.
What is the legacy clock?+
Six-week cycle: Week 1 planning, Weeks 2-4 build, Week 5 stabilize, Week 6 release. Quarterly: OKRs, NRR reviews, pricing review. Annual: strategy, customer advisory board, comp plan. Don't change it; the legacy is paying payroll and predictability is its job.
What is the successor clock?+
One-week cycle: Day 1 eval review, Days 1-3 build with continuous deploy to staging, Day 3 outcome cohort review, Days 4-5 ship behind quality gates, Day 5 outcome retro. Monthly: pricing experiments, agent-department reviews, customer NPS. Quarterly: gross margin per outcome, hiring plan.
What is the talent allocation rule?+
Three categories with hard fences. Maintenance team (5-15% of engineering) dedicated to legacy. Successor team (60-75%) dedicated to agent-native. Bridge engineers (5-10%) own integration points: data, auth, identity, infrastructure. The mistake: rotating people quarterly. That destroys both teams' momentum.
What are the six CEO scoreboard numbers?+
Legacy: revenue, NRR, gross margin. Successor: outcome volume, gross margin per outcome, percent of legacy revenue migrated. Shown side by side every week. The blended margin is informational; the migration percentage is the leading indicator that says whether the transition is working.
What are the three keystone rituals?+
(1) The Friday Read-Out: 15 minutes weekly, each team's lead presents what shipped, what's blocked, what changed in customer signal. (2) The Sunset Drumbeat: monthly memo from the CPO to the whole company on migration progress. (3) The Quarterly Reality Check: honest review of cadences, talent allocation, and sunset-date adherence with the leadership team.
What kills dual transformation most often?+
Treating it as one transformation. CPOs who try to evolve the legacy gradually into the successor end up with one product that is bad at both jobs. The right model is two products on two clocks with a published sunset on the legacy. The successor is not a refresh of the legacy; it is the replacement.
Related reading
Deeper essays and other handbook chapters on the same thread.
The Dual Transformation Operating Model
Two clocks, one product org. Run a legacy SaaS on a six-week rhythm and an agent-native successor on a one-week rhythm without tearing the team apart.
The Triad Is Dead. Pods Are Dead. Agent Departments Now.
Forrester still talks about human-with-agent teams. Wrong unit. Agents form their own departments and interface with human departments on exception.
Why "Soft Pivots" Always Become Two Companies in One Office
Every CPO running a 'gradual transition' to AI ends up running two companies inside one org chart. The five patterns and how to escape them.
The Deprecation Playbook
Feature death is the most under-written topic in PM. Kill on signal, not politics, and your team ships faster than the team that hopes politely.
Continuous Discovery Doesn't Scale for AI-Native Products
Teresa Torres' continuous discovery is the right answer for human-centric SaaS and the wrong answer for agent products. The punctuated discovery alternative.
The Guerrilla PM Playbook
You don't have a research team. You don't have a data analyst. You don't have design support. Here's how to run world-class product management anyway - with AI, scrappiness, and 2 hours a week.