# Forward Deployed Iteration Loop

> Rapidly solve complex enterprise problems by embedding technical talent directly into customer environments. Use this when launching high-stakes enterprise pilots, solving "messy" real-world data problems, or trying to bridge the gap between core product and custom customer needs.

- Skill: `samarv/forward-deployed-iteration-loop` (Agent Skill)
- Install (CLI): `npx skillmds@latest add samarv/forward-deployed-iteration-loop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/samarv/forward-deployed-iteration-loop/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: samarv (https://skillmd.com/u/samarv)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/samarv/forward-deployed-iteration-loop

---


# The Forward Deployed Iteration Loop

The Forward Deployed Engineer (FDE) model is designed to solve high-stakes, "messy" real-world problems by embedding builders directly with users. Instead of traditional "customer interviews," the goal is to live the customer's problems and execute 4-5 rapid iteration cycles per week to build software that achieves specific business outcomes (e.g., increasing factory production or finding fraud).

## The Weekly FDE Rhythm

Follow this specific schedule to maximize trust and iteration speed:

1.  **Monday (On-Site Integration):** Arrive at the customer's office. Get a desk inside their building. Attend their internal meetings. Identify the "burning problem" that the CEO or COO cares about most.
2.  **Monday Night (The Build):** Stay late to build a prototype or feature that addresses a specific pain point discovered during the day.
3.  **Tuesday (The Feedback Loop):** Show the build to the actual users (e.g., factory floor managers or analysts). Observe them using it.
4.  **Tuesday Night (The Iteration):** Refine the code based on the day's feedback.
5.  **Wednesday - Thursday:** Repeat the Cycle. By Thursday afternoon, you should have executed 4 full iterations before leaving the site.
6.  **Friday (Core Synthesis):** Return to the home office. Synthesize what you built into a generalizable product feature.

## The Murder Board Ritual

Before starting or pivoting a major project, conduct a "Murder Board" to stress-test the strategy:

1.  **Prepare the Doc:** Write a 2-page plan including the vision, goals, and specific tactics for the next three months.
2.  **Define Principles:** Include 2-3 principles that are *disagreeable*. (Avoid "Move Fast"; use something like "Prioritize data ingestion over UI polish").
3.  **Invite the Killers:** Bring in 3-4 smart peers who have no context on the project.
4.  **The Session:** Their sole job is to "tear apart" the plan, questioning every assumption, frame, and tactic. 
5.  **Outcome:** Refine the plan based on the holes they poked, or abandon the project if the core logic fails.

## Mapping the "Ontology" (Alien to Human)

Large organizations often store data in "alien language" (e.g., SAP table `S3_F1_Z`). Your job is to translate these into a human-legible "Ontology":

1.  **Identify the Core Concepts:** What are the 3-5 things the business actually talks about? (e.g., "Aircraft," "Part," "Work Order," "Oil Well").
2.  **Extract and Join:** Pull the raw, messy tables from the client's disparate systems.
3.  **Map to Humans:** Create a layer where the user can query "Where is Aircraft 79?" instead of joining 15 tables with cryptic names.
4.  **Build UI on Top:** Only build UI once the data mapping (the "Ontology") reflects the real-world operation.

## Examples

**Example 1: Manufacturing Production**
*   **Context:** A plane manufacturer needs to ramp up production from 4 to 16 planes per month.
*   **Application:** The FDE embeds in the factory, identifies that "work order carryover" is the bottleneck. They map the SAP data for "parts" and "stations" into a unified dashboard.
*   **Output:** A "Project Management" tool (similar to Asana for planes) that allows station managers to see exactly what work is remaining and where the parts are physically located.

**Example 2: Public Health Response**
*   **Context:** A government agency needs to coordinate vaccine distribution during a pandemic.
*   **Application:** The FDE sits with civil servants and clinicians. They build a data adapter that pulls real-time inventory from thousands of pharmacies into a single "Source of Truth."
*   **Output:** A supply chain visibility platform that allows the agency to reallocate doses based on daily demand spikes.

## Common Pitfalls

*   **Acting as a "Solutions Architect":** FDEs must be empowered to write code and ship new products. If the person is only "listening" and "architecting" without building, the loop breaks.
*   **Solving the Wrong Problem:** Customers often ask for "better data infrastructure." Usually, they actually need a specific business outcome (e.g., "lower wait times"). Always anchor to the outcome, not the tech stack.
*   **Remote Disconnection:** Trust is built over dinners and shared desks. Attempting this model via Zoom loses the "vibe check" and the ability to see the non-verbal frustrations of the users.
*   **Generic Principles:** Using principles like "Move Fast" during a Murder Board. If no one can reasonably disagree with your principle, it isn't a principle; it's a platitude.