Clarity Compounds
Most projects are decided in pre-sales, not delivery
A use case lands on my desk. The deal is closed. The headline outcome on the contract reads something like “automate invoice processing” or “build a finance assistant” or “improve capacity planning.” All real, all signed, all wide enough to drive a truck through.
I sit down with the customer to scope it. Within a week we’ve narrowed the wide outcome into something we can actually deliver in a meaningful timeframe. Then the pushback comes. “But you said you’d solve our whole invoice problem.” Not in those words always, but that’s the shape of it. The customer bought one thing. We’re now describing a smaller thing. Someone has to absorb the gap, and that someone is usually us.
This has happened often enough across our portfolio that it’s not a one-off. It’s the shape of a problem.
And the problem isn’t really at the scoping stage. The damage was done weeks earlier, before any FDE was in the room.
Every decision made in pre-sales compounds. A use case framed too widely in the sales call becomes a contract framed too widely. A contract framed too widely becomes a kick-off with mismatched expectations. A kick-off with mismatched expectations becomes a project that spends its first month renegotiating what it’s supposed to be. By the time you reach delivery, you’re not building. You’re recovering.
So we changed how we start.
Get an FDE in the room early
The first move was to stop letting sales scope alone.
This idea came from a recent conversation I had with Rahul Agarwal at Medplum, who runs his FDE team as what he calls sensors in the field. He described a rotating delegate system where one FDE each week is on the hook for early-stage sales calls, answering the “can it do X” questions across all prospects. The point isn’t to assign that FDE to any of those projects. It’s to make sure FDE thinking is in the room before the deal hardens.
We adapted this for our team of four. Every week, one of us is the rotating FDE. They join all pre-sales calls in the 30 to 70 per cent probability band. Below 30, it’s too speculative to spend FDE capacity on. Above 70, the project is real enough that we want a dedicated FDE rather than a rotating one. The 30 to 70 band is the window where the customer is serious but the scope is still soft, and that’s the window where an FDE can change the trajectory.
What does the rotating FDE actually do on these calls? They ask better questions than a salesperson would think to ask. Not because salespeople aren’t smart. We’re all chasing the same outcome, which is the biggest value we can credibly deliver. The difference is that an FDE can sharpen where that value actually sits, given what’s possible and what’s optimal to build first.
There are four things we want answered before a deal moves forward:
What does the process look like end to end today? Walk me through a single transaction, from trigger to completion. What systems are touched, what decisions are made, and by whom. This is the question that surfaces the gap between the label the deal was sold under and what’s actually going on.
Where does the data live, and who controls access? Which systems are involved. Cloud or on-premise. Are APIs available. Is there an external IT partner managing any of this. Integration risk and IT-partner dependency block more projects than anything else, and you want to know about both before you sign.
Who actually does this work every day? Can we speak to the operators, not just the champion or sponsor. How many people touch this process. Champions know what they want. Operators know how it works. You need both, and you need to confirm access to the second early.
What does success look like in three months? What specific outcome would justify the investment. How will the customer measure it internally. This forces them to articulate something concrete, and gives us a yardstick to scope against rather than an open-ended engagement.
The rotating FDE isn’t promising delivery. They’re often not even going to be the one delivering. The value of the rotation isn’t continuity. It’s that the customer hears these questions early, and the team gets to flag concerns before they get baked into a contract.
Dedicate an FDE before the deal closes
Once a deal crosses 80 per cent likelihood of closing, the rotation ends and one FDE takes ownership. Sometimes that’s the rotating FDE who’s been in the calls. Often it isn’t. What matters is that ownership transfers cleanly, and that it happens before the deal officially closes rather than after.
The reason for that timing is simple. The week between contract signature and project kick-off is wasted week. If a dedicated FDE is named once a deal looks close to certain, they can start absorbing context while the commercial paperwork moves in parallel. By the time the contract is signed, the FDE has been in the late-stage calls, has read whatever documentation exists, and is ready to run the kick-off.
Run the kick-off before doing anything else
The kick-off isn’t where work begins. It’s where we explain what work begins, and what we need from the customer before it does.
The kick-off has two jobs. First, set expectations for the engagement: what we’re building, what we’re not building, how we’re going to work together. Second, hand the customer their list. Credentials for the services we need to integrate with. Test environments we can break without consequence. Ground truth sample data, real cases the system should handle and real cases it currently gets wrong. A high-level overview of the process from the people who actually run it. Named partners in IT who can unblock us when we hit access issues, because we will hit access issues.
The customer then has one to two weeks to deliver that list. Nothing else happens in the meantime.
This sounds rigid and it is. The reason it’s rigid is that the cost of starting without the list is enormous and invisible. You begin building against assumed integrations, you discover the assumptions are wrong in week three, and now you’re rebuilding while explaining why the timeline is slipping. Or you start without ground truth data and ship something that works on the synthetic examples and falls over on the real ones.
If the customer can’t get us tool access in two weeks, that’s also information. It tells us something about how their organisation moves, and it predicts how the rest of the project will go.
Spend one to three days on site
Once the materials are in, we go on site.
The duration depends on the complexity of the process, which usually correlates with the contract size. One day for something narrow, three for something with multiple stakeholders and handoffs.
What we do on site is shadow. We sit with the operators who currently do the work. We watch them do it. We interview the champion, but we don’t only talk to the champion, because champions know what they want and operators know how it actually works. We ask questions that probably feel obvious to them and reveal things that aren’t obvious at all. Why do you check this twice. What happens when this field is blank. Who do you call when the system is down. Is there a spreadsheet on someone’s desktop that this depends on.
There’s no shortcut for this. Calls don’t surface it. Documentation doesn’t capture it. The tacit operational knowledge that determines whether a project succeeds is in people’s hands and habits, and you have to be next to them to see it.
A common worry is that this is paternalistic, or that customers won’t want us in their offices. In practice the opposite is true. Customers are usually relieved to have someone take their process seriously enough to sit with it. The ones who don’t want us on site are usually the ones whose projects we should be more cautious about anyway.
Define the scope
Only now do we write the statement of work.
By this point we’ve been in pre-sales calls, we’ve owned the project for two or three weeks, we’ve received everything we asked for, and we’ve watched the work happen. The scope we now write is grounded in that, not in the wide framing from the sales call. It defines what we will deliver to call the engagement complete, broken into specific capabilities with timelines and an estimated FDE budget. That’s the document the customer signs off on. Reaching the end of it is what ends the project.
Internally, alongside the full scope, we pick a first slice. Something inside the scope that we can deliver end-to-end in roughly a week, so the customer starts getting real value almost immediately. It might be ten per cent of the total scope, sometimes thirty, occasionally more. The exact size matters less than the shape: it has to be end-to-end, it has to run on real data, and it has to be something an operator can actually use rather than a demo we click through ourselves.
That first slice is deliberate. The point is to get something in front of operators that they can poke at, react to, complain about, and start building habits around. A live solution processing real data teaches us more in a week than months of planning. It surfaces the integration edges, the undocumented system behaviour, the IT-partner responsiveness, all of it, while there’s still time to do something about it. From there we keep building against the agreed scope, with each iteration landing in something the customer is already using.
Wide scoping at the start kills upsell. If phase one was framed too broadly and underdelivered, there is no phase two. A scope that’s well-defined and well-delivered is the only reliable path to the second engagement. Customers don’t buy more from teams that disappointed them on the first thing. They buy more from teams that shipped something useful in the first month and earned the right to do harder things.
What we’ve seen so far
We’ve run two projects through this full sequence. That’s not enough to call it proven, but it’s enough to notice that both have started cleaner than projects we ran the old way. Less mid-project reframing. Less of the conversation that begins with “but I thought you were going to do.” Faster path to a deliverable that an operator can actually use.
We’re going to keep running it and refining as we go. The four questions the rotating FDE walks into a call with will keep evolving. The criteria for what makes a good first slice are still being learned. The tradeoff between rigour and speed at the front of the project will keep adjusting.
But the underlying bet feels right. Everything that’s unclear early compounds. Every assumption left unexamined in pre-sales becomes an argument in week six. The leverage isn’t at delivery, where most teams focus their energy. It’s at the start, where most teams aren’t even paying attention.
Scope is a contract, not a conversation. The work we do before the build is the work that decides what the build will be. Clarity early is the cheapest part of the project. It’s also the part most likely to be skipped, because nothing seems to be happening when you’re waiting on credentials or sitting in a sales call you’re not going to deliver. But that’s exactly when the project is being decided. The build is just where the decision becomes visible.