FDE and Lean Startup Produce the Same Thing. They Start From Opposite Questions.

A founder once told me he wanted to run an "MVP engagement" — embed me inside his company, have me figure out what was broken, and ship something in six weeks. When I asked what hypothesis we were testing, he looked at me like I'd asked the wrong question.

He had. The wrong framework was the clue.

What he needed wasn't an MVP. He had a paying business with a defined operational problem. He needed a Forward Deployed Engineer. The engagement model was right. The vocabulary was wrong.

Both methods end in the same place: working software, deployed, in use. But they exist to answer entirely different questions. Blurring them doesn't just muddy the vocabulary — it sends you into the wrong engagement with the wrong success criteria, and you'll feel like you failed even if you built something real.

The question each method answers

Lean Startup / MVP: Should we build this at all?

The MVP model — Eric Ries' Build-Measure-Learn loop, the "minimum viable product" as a learning instrument, the whole apparatus around it — is fundamentally a tool for managing market risk. You don't know if anyone wants what you're building. The hypothesis hasn't been validated. The MVP exists to test that hypothesis with the smallest possible investment before you commit to a full build.

The question is: does this problem exist, and will people pay to have it solved?

Forward Deployed Engineering: How do we build this, here, for you, right now?

The FDE engagement starts from a different premise. The customer exists. The problem is real — it's been costing them money or time long enough that someone signed a contract to fix it. The market question is settled. What remains is the delivery question: can you get inside how they actually work, understand what's genuinely broken, and ship something that fixes it?

The question is: what do we build, exactly, and how do we build it so it keeps running after we leave?

Same artifact. Different question.

What they genuinely share

The overlap is real and it's not superficial.

Both reject the waterfall assumption. A Lean Startup practitioner won't spend six months designing a product before testing it with real users. An FDE won't spend six months writing requirements documents before touching the client's environment. Both methods start from the same critique: you can't plan your way to a working product. You have to build, test, and adjust.

Both treat working software as the only real output. Not slides. Not a spec. Not a prototype in Figma. A system that runs, on real infrastructure, used by real people. An MVP that generates no learning from real usage isn't an MVP — it's a mockup with a business plan attached. An FDE engagement that delivers documentation and recommendations rather than a deployed system hasn't delivered. The accountability in both cases is the same: does it run?

Both resist building features nobody asked for. The Lean Startup model defines the MVP by subtracting until you reach the minimum that honestly tests your hypothesis. The FDE model defines the scope by what's actually broken in this specific environment — not what might be useful eventually, not what the client asked for until you've watched how the work actually moves. Both disciplines apply pressure against over-building.

Both treat real user feedback as the primary learning mechanism. You can run user interviews. You can do discovery workshops. You can survey stakeholders. All of that is useful preparation. Neither method treats it as sufficient. The Build-Measure-Learn loop only starts the "measure" phase when something is actually running. An FDE's diagnosis becomes accurate when they've watched the operational reality — not interviewed people about it.

Those shared commitments aren't coincidental. Both methods emerged from watching what happens when you don't follow them: expensive software nobody uses, built to a specification nobody validated, delivered too late to matter.

Where they fundamentally diverge

The shared commitments produce different operational realities, because the starting conditions are different.

Who the user is. In a Lean Startup context, the user is unknown. That's the whole point. You're trying to find them, understand them, and test whether they'll change behavior to get the value you're offering. In an FDE engagement, the user is in the room. Or the next office. Or showing you how their current process works in real time. The discovery isn't about finding users — it's about understanding what users who already exist actually need.

What "discovery" means. For an MVP, discovery is market research: who has this problem, how bad is it, what do they currently do about it, will they pay for something better? For an FDE, discovery is operational observation: how does work actually flow through this team, where does it get stuck, where are the workarounds and tribal knowledge and manual steps that have baked themselves into the muscle memory of people who've stopped noticing them?

These look similar from the outside — both involve talking to people, watching how they work, generating insight before building. But the signal you're looking for is completely different. Market discovery asks "does this problem exist?" Operational discovery asks "where exactly does this process break, and why?"

What "viable" means. An MVP is viable if it tests the hypothesis cleanly enough to produce a real signal — yes or no, keep going or pivot. A support dashboard with one feature set and zero polish can be viable if it tells you whether support teams will actually use a dashboard. An FDE system is viable if it solves the specific operational problem for this specific client and runs without the engineer's ongoing presence. Those aren't the same bar.

The risk being managed. Lean Startup manages market risk: will anyone buy this? FDE manages delivery risk: can we build the right thing for this client, in this environment, on this timeline? A startup running Lean Startup methodology knows the market risk is real — that's the problem. An FDE engagement has already cleared the market risk; the client has signed and paid. What's left is execution.

The feedback loop that runs between them

Here's the thing that makes this more than an academic distinction: FDE work, done at scale, eventually generates the same kind of signals that MVP testing is designed to produce.

Palantir's product history makes this concrete. The company spent years embedding engineers at government and enterprise clients, building custom integrations, discovering what the actual operational problems were inside each environment. Those engagements weren't MVPs — each one was a bespoke delivery engagement for a paying client. But after enough of them, patterns emerged. The same data pipeline problems kept appearing. The same integration challenges. The same operational gaps. That repetition was signal. Foundry — Palantir's data integration platform — is what happens when you recognize that many separate FDE engagements were solving the same underlying problem.

In Lean Startup terms, those FDE engagements collectively validated the hypothesis that Foundry was built to test. The difference is that the validation came from paying engagements, not experimental MVPs. And the product that emerged wasn't an MVP — it was a generalized version of something that had already been proven to work, repeatedly, in production.

That feedback loop runs in one direction: FDE work generates productization signals over time. When the same custom system gets rebuilt for the fifth different client, that's a product waiting to be extracted from the custom work.

I've seen this at smaller scale in my own work. The pattern I built for RealEstateCRM — listings, client pipeline, status tracking, all in one environment tuned to how a specific agency actually worked — isn't dramatically different from what half the real estate agencies in the market need. One FDE engagement. The foundation of a generalizable product, if you wanted to build one. The MVP question — "would a real estate agency pay for this tool?" — was answered by the fact that the client was already paying for the specific version of it.

Applying MVP discipline inside an FDE engagement

The two methods diverge at the strategic level. But at the tactical level, a good FDE applies MVP-style discipline constantly.

The temptation in an FDE engagement is to solve the whole problem immediately. You've spent enough time inside the operational environment to see all seventeen broken things. You could fix all seventeen. The client would probably let you.

That's the wrong move.

The right move is to identify the one broken thing whose fix would produce the clearest signal — not a signal about whether to build (you're past that), but a signal about whether you've understood the problem correctly. Build the smallest slice that proves that your diagnosis was right. Deploy it. Watch whether it actually helps. Then expand.

With Automator, the operational reality was a seventeen-step publishing process that took four hours daily. I didn't automate all seventeen steps first. I mapped the workflow, identified the highest-friction point — the file renaming and folder organization steps that were the most manual and the most error-prone — and built a working version of just that part. Once I could see that my understanding of the process was correct, the rest of the automation followed quickly.

That sequencing is MVP discipline applied within a delivery engagement. Not "should we build this?" but "have we built the right thing?" The feedback loop is tighter. The stakes are different. But the underlying logic — ship small, validate the understanding, then expand — is the same.

The FDE manages delivery risk the same way the MVP manages market risk: by making the first version small enough that you can see if you're wrong before you've committed to being wrong everywhere.

Why the distinction actually matters

You could read all of this as definitional housekeeping — interesting to people who think about methodology, irrelevant to people who just need software built. That's not right.

The distinction matters because the success criteria are different, and the wrong success criteria will make a genuinely successful engagement look like a failure.

An MVP engagement succeeds if it produces a clear signal. A product that launches and nobody uses is a successful MVP if you now know that nobody wants it and you didn't spend $400,000 finding out. The MVP succeeded at its job. The business idea failed, but the method worked.

An FDE engagement succeeds if the system runs. A bespoke integration that solves the client's exact operational problem but couldn't scale to a second client isn't a failure — it was never meant to. It was meant to solve this problem, here, for this client, and run without you once you leave. If it does that, the engagement succeeded.

Applying MVP success criteria to an FDE engagement gets you stuck asking "but is this scalable?" and "how do we know there's a market?" for a system that already has a customer, already has a deployment, and already runs. Applying FDE success criteria to an MVP gets you building something highly optimized for one specific user's workflow before you know whether the problem is real for anyone else.

Both questions are right. They just belong to different moments.

What the two methods have in common, stated plainly

If there's a single thing both methods are fighting against, it's this: software built without contact with operational reality.

The Lean Startup methodology emerged as a response to waterfall product development — the pattern of specifying everything upfront, building in isolation for months or years, and discovering at launch that the market doesn't work the way you thought it did. MVPs exist to compress that gap between assumption and reality.

FDE work exists for the same reason but at the enterprise delivery layer. The pattern it's fighting against is the consultant who produces a 200-page report on what the organization should build, the contractor who implements a specification that was never validated against how the work actually happens, the off-the-shelf software that solves 80% of the problem and leaves the other 20% — the hard, operational 20% — running on spreadsheets and tribal knowledge.

Both methods say: get something real in front of real users, in their real environment, as fast as you can. Let contact with reality shape the next step.

The working product isn't the goal. The working product is the proof that you understood the problem.

If you're facing an operational problem that software should have already solved — a workflow that runs on manual steps, a process that breaks the same way every week, a system that requires someone's constant attention to function — that's the conversation the FDE model is designed for. Discovery first. Defined scope. Clean handoff.