Evolve the relationship

A system that works attracts asks. Within weeks of the handover every team that watched the shadow wants one, and the next engagement gets chosen by whoever asks loudest, or most senior. Choose it from evidence instead: what the first month in production taught, read with the person who now runs it, and every new ask put through the questions that qualified the first engagement. The answer is one recommended frame, and a no in writing for the rest. Anthropic asks its FDEs to build long term relationships with customers and proactively identify new opportunities1. Find them in the evidence, and take only the ones it qualifies.

1. Read the first month with their operator, on their screenYour access ended at the handover, as it should: it is their system now, and you are on call to its operator, not to it. A month on, go through the incidents, the near misses, the drift readout, the two numbers and the override log together, then keep that hour every month. Every case the desk corrects by hand is an incident nobody filed.
2. Turn each incident and near miss into a brief that ends in a controlPain, evidence, the enforced control that was missing, the fix and where it now lives, in the shape the product manager's step 8 uses. Never a person. Each control becomes a rule the next frame starts with, written down before it starts.
3. Write down every ask, in the asker's wordsAsks arrive in corridors and in emails to your sponsor. Record who asked, the pain as they put it, and the last time it hurt. An ask you did not write down gets answered by someone else, and the answer carries your name.
4. Qualify each ask with step 1's questionsAs step 1 does: a week of their tickets, enough to qualify and not to size. A genuine judgement call, the volume to carry evaluation, and, action by action, whether a wrong answer can be undone. Then the three disqualifiers: no path for their data to a model inside their policy and region, no one who can sign the risk, no one to run it after you. Most asks fail one, and the brief says which.
5. Rank by value and by reuse, then ask who would run itValue is the volume times what a case costs today, read against what their sponsor is measured on this year. Reuse is how much of the first system carries over: connectors, the golden set's shape, the authority budget, the harness, the runbooks. A frame that lands on the operator still learning the first system breaks both, so name who would run the new one.
6. Put every no in writing, as their sponsor's decisionA no said in a corridor comes back next month as a yes somebody else gave. Write each one in the brief with its reason and the condition that would turn it into a yes, and let the asker hear it as their sponsor's ranking, not as your gate. At a vendor a yes is a new contract too, so your account lead sees the brief before their sponsor does.

Inside your company the asks arrive from every business unit at once, often through your own management chain. Keep one ranked list, owned by the platform's sponsor and open to every asker, so the ranking is theirs and you are not the referee. A no to a peer's team then comes from the list and its reasons, never from you in passing.

• A senior leader whose ask did not make the listYour ask is on the list, and here is why it is not first: there is no way to read the rostering data yet. When there is, it moves up, and you will hear it from me first.
• Their operator, on the first month's evidenceShow me what your team corrects by hand. Every correction is an incident nobody filed, and it is the best evidence we have about what to build next.
• Their operator, asking you for one small changeIt is your system now, so it goes on your team's backlog. I will pair with your engineer for an hour, and the change is theirs to make and to keep.

Produces

Next-frame brief

Good looks like

Two pages. The month's evidence, each incident as a brief that ends in a control, every ask qualified with its numbers, one ranked list, one recommended frame with the rules it starts with, and a written no, with its condition, for each of the rest.

Owner

Forward-deployed engineer, with their operator; their sponsor decides

• Ranking by who asked. The most senior ask wins the first meeting and fails the third, when nobody can be found to run it.
• Starting the next frame on the team still learning the first system. Both systems get half an operator, and the first one's drift goes unwatched.
• Leaving the incidents' rules in the last engagement's folder. The next frame starts without them, and its first cap goes back into a prompt.

Your second customer is your own product team. Solved twice is a pattern; solved three times is a product gap. Sort each repeat into configuration, a reusable service or a product capability, write it up with every customer's evidence, and let the product's owner decide. Skip this, and a product company slowly becomes one that maintains a large bespoke system for every customer, indefinitely2. OpenAI asks its FDEs to codify working patterns into tools, playbooks, or building blocks that others can use3.

1. Keep a pattern log from day oneOne line each time you build something you have built before: what, where, how many days. Without it the third copy looks like the first. What could hurt another customer this week, such as a cap that lived only in a prompt, goes home the day you find it, not at handover.
2. Sort each repeat, and write down the reasonConfiguration: the product already does it, and a customer needed a setting. Reusable service: the same code would serve several customers, owned by your practice. Product capability: every customer will need it, so the product should own it. The reason is what the product owner will argue with. Scale AI hires forward-deployed product managers for this judgement: people who can tell the difference between a customer's stated request, their actual problem, and what the platform should do4.
3. Write the request with every customer's evidence, redactedThe days each copy took, the defects each had, what keeping them cost, and what a shared version would have prevented. One customer's evidence reads as a feature request; three customers' reads as a gap. No customer's name, data or terms leaves its own row.
4. Check who owns each copy before you propose a shared oneRead the clause in each statement of work on who owns what you built (step 2). Where the customer owns their copy, the shared version is written fresh from the pattern, never assembled from their code, and the entry says so.
5. Send model gaps to research with the failing casesA gap in the model, not in your code, goes to the people who train it: the slice, the score and its lower bound, ten failing cases labelled by the customer's experts, and what you tried that did not fix it3.
6. Hand the decision to its owner, and record itThe product owner decides, or the forward-deployed product manager where there is one. In a consultancy the entry goes to the practice's asset library; inside a company, to the platform's backlog. Record the answer with its condition, not yet included.

Inside your company the product team may be the platform team down the corridor, and the pull is to fix the repeat yourself in their code. Write the entry anyway, with every business unit's evidence, and let the platform's owner decide. A shared component nobody agreed to own becomes your team's for good.

• The product owner, asking for a capabilityWe have built this three times, for three customers. Here is what each copy cost and what broke. I am not asking for a feature for one of them; I am asking whether the product should own it, and I will take not yet with a condition.
• A customer asking where their lessons goWhat goes home is the pattern, never your data, your code or your terms. The next customer gets a better product, and so do you, at your next upgrade.

Produces

Pattern entry

Good looks like

One page: the problem in one sentence, where it occurred, what each copy cost to build and to keep, the sort with its reason, the evidence, the ask, who decides, and the answer with its condition. No customer's name or data outside its own row.

Owner

Forward-deployed engineer; the product owner or FDPM decides

• Writing the pattern up with one customer's evidence. It reads as that customer's feature request, and it is triaged as one.
• Fixing the repeat yourself, in a shared repository nobody agreed to own. It works until you move on, and then it is a fourth copy with no owner.
• Sending research a complaint instead of cases. A gap in adjectives is feedback; ten labelled failures with a lower bound is a defect someone can act on.

A reusable asset is a claim until someone who is not you has used it on a real deployment, and you have timed it. Build the configurable version with tests and a written interface, use it at the next deployment, and measure the days to first value against the bespoke copy. Then retire the copies, or you will keep four things alive where there were three. OpenAI asks its forward-deployed software engineers to design abstractions to solve customer problems, and then use them to scale our speed and quality of delivery across all Forward Deployed engagements5. This step adds the measurement.

1. Write the shared version, interface and tests firstAn MCP server, a skill or an evaluation template, configured per customer and never forked. Write its interface and tests from the pattern entry before any code. Start from the cleanest copy only if your contracts let you; where a customer owns theirs, write it fresh from the copies' behaviour.
2. Write the README with its limits at the topFor an engineer who has never met you: the limits, the interface, the configuration, and a sandbox to try it in. The limits lead because they are what the next deployment trips on.
3. Let someone else wire it at the next deployment, and time itIf you wire it yourself you measure your memory, not the asset. Stay on call and off the keyboard, and count the days from the first commit to the first case it serves. If no deployment comes within a quarter, run it on the copies' recorded inputs, and write down that this proves less.
4. Fix gaps in the asset, never in a copyThe next deployment will need something the asset lacks. Add it behind the same interface with a test, and release a version. A fix made only in their copy is the fork this step exists to stop, and Ramp's FDE team says why: ad-hoc customizations pollute the codebase6.
5. Retire the bespoke copies on dates their owners agreeEach copy moves onto the asset through its own customer's change control, after a side-by-side run on the same inputs. Until the last one moves you maintain both, so the dates go on the sheet.
6. Agree the handoff with its long-term owner, earlyWho owns it after your practice: the product team or the platform team. Agree what ready for handoff7 means before you build: deployments running it unchanged, a README a stranger has followed, an on-call on their side.

Inside your company the asset usually ends up the platform team's, and the risk is that it never leaves yours. Agree the handoff criteria with the platform's owner before you build it, and put the date in both teams' plans. A business unit that must ask you for every change will build its own copy instead.

• The next team, before they startUse the connector as it is for a week before you change anything. If it cannot do what you need, tell me: the fix goes into the connector, not into your copy.
• A customer whose own copy is to be retiredYour lookup moves onto the shared connector in your next change window. We run both side by side on the same cases for a week first, and from then on you get every fix the other deployments find.

Produces

Asset proof sheet

Good looks like

One page per asset and version: its owner and long-term owner, where it runs and who wired it, the days to first value against the bespoke copy, defects found and fixed in the asset, what it does not cover, what the measurement does not prove, and a retirement date for each copy.

Owner

Forward-deployed engineer, until its long-term owner accepts it

• Wiring it yourself at the next deployment and calling the speed a saving. You measured that you remember how; the next team still cannot.
• Patching the new customer's copy because the asset's release is a day away. That copy is now the fifth, and the asset is behind its own users.
• Building the asset and never retiring the copies. You now keep four things alive where there were three, and the saving is spent on the old ones.

Relationships end badly in two ways: the sponsor stops believing your numbers, or nobody notices the system has stopped earning its cost. A quarterly review prevents both, if you hold it before anyone asks, put the saving and the spend on one line, and ask what a vendor rarely asks: what would you stop? Bad news you bring early costs little; the same news found by them costs the relationship. OpenAI asks its Deployment Leads to run pre-/post-deployment measurement and report to exec sponsors8; Databricks asks its strategists to use their trusted advisor status to identify the next high-value FDE engagement9.

1. Put the saving and the spend on one lineThe two numbers as the product manager's step 8 builds them, against the baseline taken before the pilot, with review hours and re-runs beside them. The sponsor should never hear a number about this system first from anyone but you.
2. Show drift, incidents and the controls they producedThe output mix against both its thresholds, every model or prompt change with the harness run that cleared it, and each incident with the control it produced and where that control lives now. A quarter with no incident says so, and lists its near misses.
3. Ask their sponsor what they would stopA report nobody reads, a meeting that outlived its reason, a slice that costs more than it saves. Stopping something is the cheapest value a review can find, and asking is how a sponsor learns you are not only selling.
4. Check who champions it, and who runs it, nowWrite down who backed it at the start and who does today. Champions move on, and a system loses its defender before it loses its users, so keep three people on their side who have seen the evidence, never one. Do the same for the operator: a successor who has not thrown every switch is a handover not yet done.
5. Propose the next frame only from the next-frame briefStep 9's brief, ranked, or nothing. A proposal without a measured pain is a sales call.
6. Hold your own retrospective, apart from the reviewWith your team, not theirs, while it is fresh: what went wrong, written as a change to your practice's playbook, such as a template line, a check or a default. A retrospective that changes nothing was a meeting.
7. Close cleanly when the work is doneEvery access of yours removed and confirmed, the evidence archived where their operator will look, open risks handed to a named owner, and a reference asked for. A clean close is a good ending, not a lost account.

Inside your company the review is where a project quietly becomes permanent, or quietly loses its sponsor. Hold it anyway, with the business unit's head and with finance in the room. Your next budget will be set from these numbers, so they should come from you first.

• A quarter where it cost more than it savedThis quarter it cost more than it saved. Here is why, and what changes before the next one. If that does not turn it round, my recommendation will be to switch it off.
• The question a vendor rarely asksWhat would you stop? If something we built or report is not worth its cost to you, I would rather hear it here than at renewal.
• A sponsor who wants the next one soonerWe can frame it next. I will bring the measured pain, who would run it and what it reuses, and you decide on that, not on how well this one went.

Produces

Quarterly value review

Good looks like

Two pages, sent before anyone asks: the two numbers on one line with their baseline, drift, incidents and their controls, adoption, what the sponsor would stop, the champion and the operator then and now, the next frame or a clean close, and actions with owners.

Owner

Forward-deployed engineer, with their sponsor and their operator

• Holding the review only when renewal is near. The sponsor reads it as a sales call, and believes the numbers less for it.
• Missing that the champion has gone. The system runs, the review is on time, and nobody on their side will argue for it when the budget is cut.
• Dragging the engagement on because closing feels like losing the account. They are paying for an FDE the system no longer needs, and they know it.