The First Two Weeks Decide
TL;DR: The embed phase is the opening stretch of a deployment, when a forward deployed engineer (FDE) works inside the customer's operation before anything is built. Its job is to replace assumptions with facts: what the problem actually is, what the data actually holds, who can actually say yes. Five heuristics below. Skip them and the build still happens. It just builds the wrong thing, on schedule.
The brief is almost never the problem.
A brief describes the problem as it looks from a meeting room: the queue is too long, the review step is too slow, the team wants a copilot. Sit with the people doing the work and a different picture shows up within days. The queue is long because a third of the items arrive incomplete. The slow step is slow because two teams disagree about what a finished item looks like. Nobody wrote that down, because to the people living it, it isn't a problem statement. It's Tuesday.
That gap, between the brief and Tuesday, is what the first two weeks are for. Everything after is execution. These are the heuristics we hold the embed phase to, stated as principles, because they're the part of a deployment that decides whether the rest deserves to happen.
Five heuristics for the embed phase
Work on the problem in the room, not the proxy in the brief. The forward deployed engineer role was built on exactly this distinction: embed with the customer and solve their problem, not a stand-in for it. A proxy problem is recognisable. It names a tool (“we need a chatbot”) instead of an outcome, and it survives contact with nobody. So the first heuristic is rude but necessary: keep asking who hurts, at what step, measured how, until the answer names a workflow and a person rather than a technology.
Ask for access on day one. Data, systems, the users who’ll live with the result, and the security reviewer who’ll eventually judge it. Access requested in week six arrives as a delay; access requested on day one arrives as a plan. If an account, a data extract or a review meeting can’t be scheduled early, that isn’t admin noise. It’s the first honest signal about how the deployment will actually run, and it belongs in the open while there’s still time to act on it.
Read the data before designing around it. Sample records lie by omission in a specific way: they’re the clean ones. The real corpus has the duplicate accounts, the scanned attachment nobody can search, the field that changed meaning two years ago and kept its name. An architecture sketched before anyone has looked at a few hundred unfiltered records is fiction with diagrams. Look first. Some designs die in that reading, and they deserve to.
What the embed phase has to surface — the real problem, the real data, real access and a real owner, before the first workflow is chosen. Pick a first workflow that’s small enough to ship and real enough to matter. Both halves count. A first workflow with no real users proves nothing except that a demo works. One that tries to absorb an entire department proves nothing either, slower. The test we use: named users, a volume you can count, and a before-and-after someone can check. If it succeeds, it earns the right to grow. If it fails, it fails small, in weeks, with the lesson still cheap.
Name who can say no. Every deployment has more vetoes than the kickoff admits: a security review, a data owner, a team lead whose workflow changes, the users themselves, who veto by ignoring. The embed phase should surface all of them and agree, in plain language, what “in production” means for this workflow: who’s accountable for it, what good output looks like, and what happens when the system is unsure. A deployment, in our vocabulary, means a system running in production (real users, real data, an owner for failures), not a pilot that impressed a room. That definition gets agreed here, or argued about later at a much higher price.
Where this breaks
Honesty about the limits, because there are two real ones.
Discovery can become theatre. Two weeks of interviews and sticky notes that end in a report nobody acts on is worse than no discovery at all, because it spends the customer’s patience and calls it diligence. The embed phase only earns its time if it ends in decisions: a chosen workflow, an access plan, an owner, a definition of done. If it can’t produce those, say so and stop, rather than drifting into a build to justify the calendar.
And heuristics can’t fix an organisation that won’t open the door. If users won’t give an hour, if data access is refused, if no one will own the outcome, the right move is to pause the engagement, not to build a polished demo against sample data and hope. A demo built in the dark doesn’t de-risk anything. It just defers the argument to go-live, where the same people say no with more at stake.
There’s a quieter failure too. Embed with one loud user and you’ll build for them. The person who talks most in discovery is rarely the median case, so the workflow you choose has to be checked against the people who’ll use it quietly, at volume, when nobody from the pod is watching.
What it decides
By the end of the embed phase you should be able to say four things without hedging: the problem, in the words of the people who have it; the state of the data, from having read it; the first workflow, with its users and its measure; and the owner, by name. If you can, the build that follows has a chance, because it’s aimed at something real. If you can’t, building anyway isn’t momentum. It’s a guess with a budget.
Work with us
If a deployment you’re planning still describes its first workflow in slide language, the honest next step is two weeks of finding out what’s actually true, before anyone writes code. Bring us that starting point through Trida AI’s intake and we’ll help you turn the brief into a problem worth building against.