Why FDEs should write key results with clients before any code

A deployment can run reliably and meet the spec, yet the client still calls it a failure. The cause is rarely the code: the two sides never agreed on what success looks like.

John Doerr’s Measure What Matters was not written for Forward Deployed Engineers. Portfolio Penguin presents the book as a guide to using OKRs to make tough choices about business priorities. But the first week at a client is exactly when those choices have to be made.

If you are an FDE, or want to become one, the book teaches a skill many strong engineers still lack: turning a client’s vague requirements into a few numbers that anyone can score at the end of the period.

Where the method comes from

Doerr did not invent OKRs. According to the What Matters website, the method was created by Andy Grove at Intel, and Grove himself taught it to Doerr. In 1999 Doerr took it to Google’s founders, which is why the Penguin Random House Canada edition carries a foreword by Larry Page.

According to the publisher, Doerr has introduced OKRs at more than 50 companies. The UK edition came out on 26 April 2018. The publisher also stresses that goals must be communicated across the whole organisation, from new hires to the CEO. For FDEs that detail is worth keeping: a deployment’s OKRs must be clear enough for both end users and the client’s sponsor to understand.

First idea: the Objective is only what must be achieved

What Matters defines an Objective simply as what is to be achieved, no more and no less. It contains no numbers and no solution. That is why it helps when a client opens with “we want an agent”.

Imagine deploying an agent that processes claims files for an insurance company. “Build an agent that reads PDFs” is a solution. A proper Objective would be: claims staff process files faster without losing accuracy. Once that sentence is written, you and the client are genuinely talking about the same problem.

Second idea: a KR must answer “met or not?”

According to What Matters, effective Key Results are specific, time-bound, aggressive yet realistic, and measurable, so that at the end of the period it is clear whether they were achieved. “Improve the staff experience” fails this test. On the last day of the pilot, nobody can prove it true or false.

Applied to the insurance example, the figures below are purely illustrative. KR1: during the 30-day pilot, the agent correctly extracts the data fields in 80% of type A files without staff having to correct them. KR2: average handling time per file falls from 20 minutes to 12. KR3: 15 staff use the tool daily by week four.

Each KR forces discovery questions from the start: how many minutes does it take now, who measures it, where does the data come from. No baseline, no KR.

Two common mistakes when writing OKRs with clients

The first mistake is putting the solution in the Objective. “Deploy a PDF-reading agent this quarter” sounds like a goal but is really a task: if the agent ships and staff are still slow, the Objective still counts as done. When you hear a sentence like that, ask the client: once that is done, what changes in their work?

The second mistake is writing KRs without a baseline. “Cut handling time by 40%” cannot be scored if nobody knows how long it takes now. The practical fix is to make the first week a KR of its own: measure handling time on a sample of real files, then agree the target figure with the client.

Third idea: be clear about what is a promise and what is an ambition

This is the idea FDEs most often miss. What Matters distinguishes committed OKRs, goals the team must achieve within the cycle and which are scored only as met or not met, from aspirational OKRs. For the aspirational kind, below 40% counts as a miss, while 40–70% is good progress. An OKR’s score is the average of its KR scores.

Suppose the three KRs above score 0.9, 0.6 and 0.3. The average is 0.6, within the good-progress range if this is an aspirational OKR. But if the client assumed all three were promises, that 0.6 becomes a report of failure.

The fix is to label them at the kickoff. KR1 on accuracy is a commitment, because it is the condition for staff to trust the agent. KR2 and KR3 are aspirational. A one-line note like that saves you from an awkward meeting at the end of the pilot.

Who should read it, and in what order

The book is most worth reading when you start running pilots or engagements yourself, because then you have a real project to apply it to. Read the sections on defining and scoring OKRs first, then apply them straight away to your current project. Only then read the section on CFR, which stands for Conversations, Feedback, Recognition: according to What Matters, OKRs combined with CFR make up continuous performance management.

For FDEs, CFR is the weekly check-in with the client: seeing where the KRs stand, listening to feedback, recognising the first users willing to try the tool. Read this section before you have a real OKR in hand and it easily stays abstract.

For your career, this skill shows up directly in a job application. In job postings, look for phrases such as “success criteria” or “measurable outcomes”. On your CV, replace “built a document extraction pipeline” with a line that has an Objective, a number and a deadline. Interviewers will see at once that you know how to measure value, not just ship features.

Your first meeting with a client, then, should not end with a feature list. End it with three KRs that have deadlines and both sides’ signatures.