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
- Asana ≈ 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 reusable library 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, so I'd weight capacity and health by product-mix complexity, never punishing 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
- Make the in-flight Docs build safe
- Productize the repeatable motions with internal frameworks and governance, right-sized to where the team is today
- Instrument capacity for the future headcount case
- Bring in partners only once the internal model is defined: roles, responsibilities, handoffs
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, so how we stand it up is itself a strategic fork. My instinct: a deliberate incubation to 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. 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, and I won't let efficiency metrics quietly borrow from future churn.
- Lagging (NRR, retention) takes up to 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
- Build the deliverable muscle early, before paid motions get rigorous
- 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.
Time-to-value is the throughline across all three.
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 had me go deep on what I'd build and how I'd measure it. The question I'd put at the center is the who: how do I earn a team's trust mid-build, keep the best of them through a leadership change, and still ask them to change how they work? None of the strategy happens if the team doesn't come with me.