1. The Role, Economics & Rhythm

Which title lands on your badge depends on where your company draws the line between product, engineering, and sales — but the accountabilities genuinely differ, and this curriculum sits on the FDPM/FDE pairing specifically, so it's worth being precise about what each half owns.

An embedded product leader who owns deployment outcomes from the product side. Not advisory, not pre-sales — accountable for whether the AI product actually reaches production at a given account and delivers measured value, and for what gets built, declined, or escalated to the core platform team along the way.

The defining trait is engineering ownership inside the customer's environment — writing and debugging code directly on customer infrastructure, building custom integrations, and feeding field learnings back into the core product. This is a harder bar than 'leans toward build' — it's accountability for making customer-specific technical work actually function in production.

Primarily advisory and pre-sales. The accountability is proving or explaining the product — SEs rarely write code on customer infrastructure and typically stop at proofs-of-concept. Their mandate ends roughly where FDPM/FDE mandate begins: at or before the signature.

Owns problem framing, stakeholder navigation, and the operational path to value — but this title is less standardized across companies than the others. Technical depth varies widely (sometimes highly technical, sometimes closer to implementation strategy), and no source puts it head-to-head against FDPM with a fixed definition. Treat it as a company-specific variant rather than a distinct, stable role.

Extend that logic to FDPM: if a role is accountable for the product outcome and build decisions at an account — independent of who writes the code — it's FDPM.

Same account, paired team, two different accountabilities. The FDE owns the code. The FDPM owns the product decision and the outcome — what ships, what's declined, what gets escalated to platform teams as generalizable signal. Neither role outranks the other; they're two halves of one deployment.

1. Who you report to — product, sales/CS, or engineering pulls your instincts toward generalization, account health, or technical correctness respectively, even with an identical title.
2. What you're measured on — accounts live, ARR influenced, product tickets generalized, adoption score — the metric shapes which trade-offs you default to.
3. How much authority you have to say no — the clearest real signal of seniority in this function, more than the title itself.

The model runs in three phases: land, expand, compound. You land by picking one messy, mission-critical operational problem and shipping a working, customized solution in weeks, not quarters. A good land phase doesn't just solve problem one — it builds reusable foundation so the next use case doesn't start from zero.

Pick one messy, mission-critical operational problem the customer already has. Ship a working, customized solution fast — small team, limited scope, prove value before asking for a large commitment. This is the entry point, not the business model.

A well-run land phase builds reusable foundation while solving the first problem. The second use case reuses that foundation instead of starting over — a manufacturer that solved a quality problem can reuse the same data infrastructure for supply chain or predictive maintenance next.

Integration work that used to be bespoke becomes automated and reusable across deployments. Each subsequent engagement — at this account and others — gets faster and cheaper to deliver. This is what allows the revenue mix to legitimately shift toward product.

If services stay flat or grow indefinitely on a mature account, that account has quietly become a consulting engagement wearing a software company's branding.

SaaS historically kept services to 8–10% of revenue because services carry lower margins. AI breaks that — it isn't plug-and-play, needs per-enterprise customization, and frontier labs are building services layers themselves. Everest Group projects services rising to 10–15% of software revenue by 2030. The services layer that used to sit outside the product now has to be built into it.

1. Every deployment decision either builds reusable foundation (land → expand) or creates one-off work (stuck in land).
2. Track deployment hours per account over time — declining hours is the earliest honest signal the model is working.
3. Early "suboptimal" margins are a legitimate bet only if it's a tracked bet, not a hope. Week 10 (Generalization) returns to this exact lens.

Two independent sources converge on the same split: about 80% embedded with the customer, 20% internal. That ratio is the single most important fact about this role's rhythm — it tells you that being in the customer's environment isn't an occasional trip, it's the default state, and that internal work is the minority slice you have to actively defend.

The 20% internal time is where product input, generalization, and reusable assets get made — the work Week 10 is entirely about. It's also the first thing sacrificed when an account gets hot. If your 20% consistently collapses to zero, you're still delivering for the customer but you've stopped feeding the platform, which is precisely the 'perpetual services' failure mode from the deployment economics lesson. Protecting that slice isn't self-care; it's the job.

FDPM postings frame travel as 'willingness to travel to client deployment sites to embed directly with operations when critical milestones dictate' — a different pattern from the always-on-a-plane FDE stereotype. The load is lumpy: intense during discovery, launch, and recovery moments; lighter between them. Planning your recovery around the milestone calendar, rather than expecting an even weekly rhythm, is the practical version of this.

FDPM roles routinely require collaborating 'across highly distributed international time zones — North America, Europe, and Asia hubs.' This is a cost the travel conversation usually misses: even when you're not flying, the working day stretches at both ends to cover the customer on one side and your platform team on the other. Left unmanaged, it silently converts an eight-hour day into a twelve-hour one without anyone deciding it should.

Structurally, this role exists to absorb pressure so it doesn't reach the executive relationship or the platform team unfiltered. That means interrupt-driven work is not a sign the week went wrong — it's the design. The sustainability question isn't how to eliminate interruptions; it's how much absorbed pressure you can carry before your judgment degrades, and noticing that line before you cross it.

1. Who protects your 20% — you, your manager, or no one — determines whether generalization work ever actually happens.
2. FDPM postings ask for "extreme autonomy in flat, fast-paced" environments. Autonomy means no one else is scheduling your recovery either.
3. Industry leaders note many companies replicate this model as "a half measure" — importing the embedded expectation without building the rotation, coverage, or recovery infrastructure that makes it survivable.