There’s a metaphor the Palantir crowd uses for forward deployed work, and I keep coming back to it because it’s right. The forward deployed engineer lays down a gravel road — a rough, specific path that gets one customer from where they are to where they need to be. Later, once that path is proven, the core product team paves it into a superhighway that carries the next ten customers smoothly.
Most people hear that and assume the gravel road is the embarrassing part. The temporary hack you apologize for. I think it’s the opposite. The gravel road is the most valuable thing you build, because it’s the only way to find out where the road actually goes.
You can’t pave a road that doesn’t exist yet
Here’s the failure I’ve watched teams walk into. They want to build the superhighway first. The general platform. The configurable, future-proof, handles-every-case system. So they spend two quarters designing for customers they haven’t met and problems they’re guessing at. Then the first real customer shows up and needs something the beautiful architecture made hard.
The gravel road inverts the order. You build the ugly specific thing for one real customer, in their environment, with their actual constraints. It teaches you things no amount of planning would have: which features they never touch, which edge case is actually the whole job, where the data is dirty in ways nobody mentioned. That knowledge is the asset. The code is almost incidental.
Working code today beats a perfect plan next quarter — not because speed is a virtue, but because the plan was wrong and the code is how you find out.
The discipline most people skip
This is where “scrappy” gets dangerous, so let me be precise. A gravel road is rough, not broken. It carries real traffic. The difference between a useful gravel road and a pile of technical debt is one habit: you stay honest about which parts are load-bearing.
- The thing the customer depends on every day gets real tests and real error handling, even on the gravel road. That part is production.
- The thing you hardcoded to ship this week gets a comment that says so, and a note about what generalizing it would take. That part is deliberate, not accidental.
- Everything you learned that contradicts the original plan gets written down and carried back to whoever owns the roadmap. That’s the entire point of having gone.
Skip that last step and the gravel road really is throwaway work — not because of how it was built, but because nobody harvested what it taught you.
When to pave, and when not to
Not every gravel road should become a highway. Some are one-offs, and trying to generalize them is how you build a configurable monster that serves no one well. The signal to pave is when the third customer asks for a path you’ve already cut twice by hand. Now you know the shape of the demand, you’ve de-risked the design with real usage, and the investment is justified by evidence instead of optimism.
That sequence — cut it rough, prove it carries weight, pave it only once the traffic is real — is most of what good forward deployed work is. The gravel road isn’t the compromise on the way to the real thing. It’s how anyone ever finds out what the real thing is.