Ben Ratcliff
Turn momentum into a repeatable, scalable delivery model
- C-suite lens: retention, expansion, time-to-value at scale
- Team lens: the ground-level build — and someone you'd build with
- Asana: built the delivery org from a standing start
- Same three motions — behavior change · workflow/agent · enterprise
- Canvas ≈ Docs · workflows+AI ≈ Go · parallel rollouts ≈ multi-product
Four areas — jump in anytime
My read on the products and the delivery risk in a multi-product world.
Inputs, sequencing, 30/60/90 — building without slowing delivery.
What I'd measure while the function matures, and how it lands with the C-suite.
How I actually work with AI, and how I'd build it into the team.
A Superhuman Docs metrics doc goes deeper — shared ahead. Room for conversation over coverage.
Three delivery motions, not one per product
My read after living in the products — and the delivery risk that matters most.
Organize delivery by onboarding archetype, not by product
More than two products — but three change problems. The motion, not the product, is the unit I'd build around.
Habit formation, one user at a time. Delivery: scaled + productized, selective white-glove.
"Learning to think in the tool." Delivery: consultative, discovery-led, repeatable templates.
Governance, champions, phased change management. Delivery: high-touch, EM-led.
Already staffed — Zach's Onboarding Managers, Alex's Solution Architects, Victoria's Engagement Managers. I'd name the model forming, not impose one.
Each product onboards differently
- Bundled, not yet sold or delivered — early pull is custom agents
- Delivery = workflow discovery + custom builds; bespoke until marketplace matures
- Open Q: how fast we productize into a reusable library
- "Learn to think in the tool," not a finished system
- Adoption needs champions — change mgmt, enablement, governance
- Docs AI lowers the floor; AI Views, GA MCP, Databases add surfaces
- Like Grammarly — behavior change at scale
- Enterprise challenge = governance: security review, style, tone
- Real move: onboard the admin team, not just end users
The multi-product risk — and what I'd pressure-test first
- Not any one product — the seams between them
- Two specialist teams, two parallel plans, one customer
- Resourcing conflicts; one sponsor over disconnected teams
- Blended health can hide a stalled product → missed churn
- One named owner for the whole outcome (the EM bridge)
- A single milestone plan, even when staffed separately
- Deliberate sequencing — lead with fastest time-to-value
- Test: Docs-first or Mail-first? How many multi-product yet?
A multi-product customer genuinely needs more touch — I'd weight capacity and health by product-mix complexity, never punish the most valuable customers with a flat metric.
Stabilize what's in flight, then scale
How I'd build the model without slowing a team that's already delivering.
First gather, then sequence — stabilize before scale
Inputs first: the three leads and every IC, utilization data, in-flight deliveries, and cross-functional context — strategy, roadmap, revenue, sales/SE, CS, pricing, partners.
- Define "good" per archetype
- Stand up the EM function — scoping-vs-delivery split, conversion tracking
- Outcome-framed scoping (no SOWs yet)
- Make the in-flight Docs build safe
- Productize the repeatable motions
- Instrument capacity for the future headcount case
- Partners only after the internal model — roles, handoffs
- Internal-first
A thin one-page playbook per archetype, phased in at a pace the team can sustain — and co-built, so they own it.
What "good" looks like at 30 / 60 / 90 — depends on who's asking
Same plan, two truths — I'd hold both at once.
Standing up the Go motion — a deliberate incubation, not a factory
Go isn't delivered yet — how we stand it up is itself a strategic fork. My instinct: find the shape before industrializing it.
- A consistent pod of representative roles
- Early custom builds with a few early adopters
- Find the shape, then teach the rest of the org
- Develops more than delivery — metrics, product feedback, sales messaging
- Could sit inside Delivery, or go cross-functional as a GTM pod
- Assume consumption pricing is being considered
- Keep the motion ready to flex to it
- Consumption → a forward-deployed-engineer model gets real legs
A strategic fork I'd want to align on early — not a settled plan.
Where AI fits in delivery — near-term, and in sequence
The order matters as much as the tools — I'd build the foundation before the fleet.
Synthesize what's known about the customer into a day-one kickoff. The biggest time-sink; the highest-leverage first move.
Standardize delivery tracking on a best-in-class, AI-native tool — Wrike today. Bias: make Docs the vehicle if it earns it.
On that foundation: risk and health, capacity and forecast, QBR. Not a fleet on day one.
Where it fits, we deliver on our own product — this deck's metrics doc runs on the Docs MCP, which is GA.
Measure the signals that predict durable revenue
The judgment behind what I'd measure — and when — while the function is still maturing.
Lead the signals that predict revenue — before lagging metrics are trustworthy
Onboarding owns the front end of the retention machine — I won't let efficiency metrics quietly borrow from future churn.
- Lagging (NRR, retention) takes 2–4 quarters — the function is early
- Watch: kickoff timeliness, time-to-value, activation, burn-vs-progress, risk aging
- A leading indicator is a hypothesis until it correlates — instrument that first
- Time-to-value = the value moment, not go-live
- Pair every efficiency metric with a quality guardrail
- Won't celebrate a speed gain that degrades its pair
- Complexity-weight the metric — no flat bar for multi-product
- Monetize the complexity — more touch is often where paid services enter
- Value, not a penalty
Translate delivery into the language of revenue, retention, growth
The frame: revenue-at-risk protected, and expansion enabled, per dollar of delivery investment.
One source of truth, leading-before-lagging, complexity-weighted — plus a maturity view of what I measure now, what I don't yet, and when.
Accelerator, not crutch
How I actually work with AI — and how I'd build it into the team.
How I actually used AI — and where my judgment governed
AI as accelerator, not crutch — the skilled experts stay central; AI lets them scale more value.
- Write on an open canvas — find the points and structure
- Walk and dictate a first version out loud (the elevator test)
- AI synthesizes it into a tighter structure — it just accelerates a process I've always used
- Context files: the company, what I learned from the team, my own background
- Tweaked existing skills to build the deck
- Used your published brand guidelines to approximate the template
- Built the metrics doc on the Coda MCP
- AI misread me on paid services — I caught it
- Overrode its calls on what mattered, slide by slide
- Max time on the points, minimum on formatting
How the team uses AI in delivery — and the one rule
Use AI aggressively — but own the output
If it's obvious you don't understand it, or never reviewed it, it's a waste of everyone's time. AI drafts the breadth; the person forces the distillation to the single biggest win, challenge, and blocker.
- Prioritize the workflows that free the most delivery time first
- Go agents — delivery expertise becomes agent-building expertise
- AI-assisted data migration (bigger as Databases lands)
- Scaled assets — how-to videos and tailored pre-kickoff materials
- Start with the team's biggest pain points; make them co-creators
- Shift from admin-heavy weeks to customers and outcomes
- Like giving everyone a chief of staff
- A multi-quarter journey, not a weeks-long project
The question you didn't ask — and mine for you
The question you didn't ask
You asked deeply about what I'd build and how I'd measure it — almost nothing about the people who'll build it. How do I earn the trust of a team mid-build, and keep the best of them through a leadership change, while asking them to change how they work? None of the strategy happens if the team doesn't come with me.