How Forward Deployed Engineering is done at Ramp — Leo Mehr

Actionable Insights

• Create an FDE intake agent that refuses to write a spec until key scoping fields are present. Ramp’s example uses Slack/Notion intake and an agent that asks follow-up questions before generating a spec. Build a template with required fields: customer, ARR/strategic importance, deadline driver, user persona, platform/environment, workaround tried, success metric, affected pipeline, and “who else needs this?” First implementation can be a Notion Custom Agent or Slack bot connected to a Notion database. Evaluate by response latency, percentage of requests with complete scope, engineer-days avoided, and requester satisfaction.
• Adopt an “always be scoping” checklist before touching code. For each urgent enterprise request, ask: who is driving urgency, what happens if we do nothing, is the platform/API already enough, can the customer self-serve, is a manual bridge acceptable, and does the same need appear in pipeline/customers? Leo’s SAP S/4HANA example at 3:11–4:42 shows why the default reflex—opening API docs and building—is often wrong. Caution: scoping is not stonewalling; it is how you say yes to the right outcome.
• Prevent wasted builds by validating obvious assumptions explicitly. The iOS/Android reimbursement story is the canonical failure mode: the team built both mobile platforms before learning the customer only used iOS. Add an “assumption kill sheet” to every FDE spec: platform, integration system, permissions, beta users, data availability, rollout environment, compliance constraints, and customer technical owner. Do not start implementation until each assumption has an owner and evidence.
• Decompose FDE work into an agent factory: intake → clarification → spec → implementation → eval → human judgment. Leo says each stage of gathering context, scoping, spec writing, and implementation can be replaced or accelerated with agents. Start with the narrowest stage—intake clarification—because it has low blast radius and immediate latency gains. Then add spec generation with rubrics, then implementation only when tests/evals exist. Keep humans responsible for taste and final output.
• Consolidate knowledge before expecting agents to work. Ramp’s Notion customer story says teams moved work into Notion, cut productivity-tool costs by roughly 70%, and deployed 300+ custom agents. Notion’s Custom Agents docs support triggers from Notion/Slack, scoped access, activity logs, and version history. First step: centralize FDE requests, product docs, API docs, customer context, and past decisions into a system of record; otherwise agents will hallucinate missing context.
• Measure scoping quality, not just agent volume. Track avoided builds, scope-cycle time, request completeness, spec acceptance rate, PR rework, and downstream customer impact. A “token maxing slop cannon” is what happens when an agent factory runs on poorly scoped requests. Use human feedback, eval rubrics, and postmortems for requests that produced unused work.

Core thesis

Ramp’s FDE practice rests on two principles: always be scoping, and scale with tokens. FDEs should not blindly say yes to customers; they should discover the smallest correct path to customer value. But in the AI era, they also need to automate their own lifecycle with agents or be outpaced by agent-native competitors.

Big ideas / key insights

• FDE at Ramp lives inside engineering. The role is not just sales engineering; it builds core product and agentic features for enterprise customers.
• Scoping is the primary leverage point. The best engineering work may be avoided, simplified, or generalized before coding begins.
• Agentic automation should start in low-risk workflow stages. Ramp began with intake clarification, not full autonomous implementation.
• Human taste remains the final control. Leo explicitly keeps FDEs responsible for judgment over final output.
• Bad scoping plus powerful agents creates waste faster. Tokens amplify process quality—good or bad.

Best timestamped moments

• 2:10 — The two principles are introduced: always be scoping and scale with tokens.
• 3:11–4:42 — SAP S/4HANA integration scenario illustrates the need to question urgency, workaround, API options, and broader demand.
• 5:12–6:16 — Mobile reimbursement story shows a preventable assumption failure: Android was unnecessary.
• 7:19–8:50 — Leo maps the FDE lifecycle from context gathering to spec to implementation and says each stage can be agent-assisted.
• 9:21–10:22 — Notion agent intake reduced reply latency from hours/days to seconds and reportedly saved around 20% of scoping time.
• 12:25–13:26 — Closing warning: scoping without tokens falls behind; tokens without scoping produces slop.

Practical workflow

1. Put all FDE requests into one database/channel.
2. Require the intake agent to collect missing fields before escalation.
3. Generate a draft spec only after required evidence is present.
4. Run a scoping review: reduce, workaround, generalize, or build.
5. If building, attach tests/evals and a rollout owner.
6. Review post-ship whether the request was correctly scoped and whether the solution generalized.

Comment insights

No comments were extracted for this video, so there is no comment-derived practitioner feedback. This analysis therefore relies on transcript, screen evidence, and external research rather than audience discussion.

Deep research

• Support: Ramp’s public FDE writeup matches the talk. Ramp Builders describes FDE as a strategic unlock for B2B companies, says Ramp’s FDE team sits close to enterprise customer outcomes, and names “Always be scoping” as a core principle. It also emphasizes talking directly to customers, questioning requirements, finding workarounds, and generalizing work.
• Support: Notion Custom Agents can implement the workflow shown. Notion’s help docs say Custom Agents can read Notion pages/databases, run on Notion or Slack triggers, post/update records, use scoped access, provide activity logs, and support version history. That aligns with Ramp’s intake-agent pattern.
• Support: Ramp’s Notion customer story gives broader context. Notion reports Ramp centralized work in Notion, reduced productivity-tool costs by ~70%, moved about 3x faster, and deployed 300+ custom agents. Treat these as Notion/Ramp-reported claims, not independent productivity proof.
• Contradiction/caution: AI workflow automation can accelerate bad inputs. METR’s 2025 RCT found experienced developers took 19% longer with early-2025 AI tools in a realistic open-source setting. While not an FDE-intake study, it cautions against assuming AI automatically improves productivity without task fit, scaffolding, and measurement.
• Caution: FDE can become bespoke-services drag. Ramp’s own writeup notes tension between reducing scope for a customer and generalizing work for many customers. The right answer requires taste, product strategy, and willingness to say no.

Verdicts on major claims

• “FDEs should not just say yes.” — Agree, high confidence. The transcript examples and Ramp writeup strongly support this. Practical takeaway: scoping is a first-class engineering activity.
• “Each FDE lifecycle stage can be replaced with agents.” — Mixed, medium confidence. Intake and clarification are strong early candidates; implementation and product judgment need tests, context, and human review. “Replaced” is overclaimed; “augmented and partially automated” is safer.
• “Scaling with tokens is mandatory.” — Agree with caveat, medium confidence. Teams that do not use AI for repetitive knowledge work will likely lag, but tokens are not the metric—quality-adjusted output is.
• “The future of FDE needs both scoping and tokens.” — Agree, high confidence. The two principles are complementary: scoping controls direction; agents provide leverage.

Screen-level insights

• 0:32 — Opening slide/stage context; Leo introduces Ramp FDE growth from two engineers to a broader org.
• 1:06 — Meme slide frames FDE as often confused with sales engineer/TAM/solutions roles; Leo uses it to reject the “technical GTM boss mode” simplification.
• 3:41 — SAP S/4HANA/enterprise-fire meme appears near the urgent integration story, visually reinforcing messy enterprise pressure.
• 6:47 — “Falling behind / scaling with model capabilities” meme supports the second principle: FDEs must reinvent workflows as models improve.
• 7:49 — Dark-mode Slack/Notion thread screenshot shows the operational intake workflow: request metadata, “Open in Notion,” and an FDE Intake Agent asking clarifying questions.

My read / why it matters

This is the most immediately operational FDE talk in the batch. The highest-value idea is simple: put an AI gate in front of engineering work that improves the request before humans spend time on it. The trap is also clear: if the gate rewards speed over clarity, you automate confusion. The right FDE system makes ambiguous enterprise demand legible, scoped, and testable before code starts.

Verification notes

Checked transcript, frame analysis, Ramp Builders FDE article, Notion Custom Agents documentation, Notion/Ramp customer story, and METR’s 2025 productivity RCT as a cautionary counterpoint. Source/evidence audit labeled Ramp/Notion productivity numbers as company-reported. Transcript/comment/frame fidelity audit matched the SAP, scaling, and intake-agent slides to nearby transcript. Hallucination/overclaim audit avoided adding nonexistent comment insights and softened “replace” claims to staged automation. Actionable Insights audit confirmed the top section includes concrete workflow fields, tools, metrics, cautions, and rollout sequence. Residual uncertainty: no comments were available and some slide text was partially unreadable.