Problem Framing in the Customer's Environment
Translating what the customer asked for into what they actually need, without becoming the person who says 'actually you don't need that.'
Why this is the first skill, not the third
Customers describe problems in the vocabulary of solutions they've already considered. 'We need a dashboard' usually means 'I am tired of being surprised by bad news in meetings.' 'We need an AI agent' often means 'this manual process embarrasses us and we want to look modern.' Neither of those underlying things is what you'd build if you took the request literally. Akshay Krishnaswamy, Palantir's Chief Architect, framed the work in his TBPN interview as the entire product development process running 'front-to-back from the field, not from a privileged engineering core.' Field-first means the engineer has to convert customer language into something buildable before any code gets written. The wrong code shipped quickly is worse than no code shipped at all.
Five questions that surface the real problem
There is a small set of framing questions that, asked patiently, almost always expose the underlying situation. (1) 'Walk me through the last time this came up. What specifically happened?' Converts abstract complaints into a single concrete incident you can dissect. (2) 'If this were solved tomorrow, what would change for you personally?' Surfaces the political and emotional stake, which determines whether the person will champion the project. (3) 'What have you already tried?' Reveals constraints you can't see and saves you from re-proposing rejected solutions. (4) 'Who else is affected, and do they agree this is the problem?' Catches the case where you're talking to one stakeholder about a problem the rest of the org doesn't share. (5) 'What would the simplest acceptable version look like?' Forces a definition of done that isn't infinite. None of these questions are clever; they only require the FDE to actually wait for the answer instead of preparing the next slide.
Sitting with users, literally
The 'Day in the Life of a Palantir Forward Deployed Software Engineer' essay on Palantir's blog (the closest primary artifact we have for the day-to-day) describes time spent next to analysts and ops users, watching them do the actual task. Not interviewing them in a conference room, sitting at their desk, watching the spreadsheet they keep open on a second monitor that no one mentioned, the Slack workaround, the field they always leave blank because the dropdown doesn't fit their case. This is the highest-bandwidth research available to an FDE and is consistently undervalued by engineers who prefer specs to observation. One hour of watching is worth four hours of interviewing. At OpenAI specifically, the company's own Deployment Company page describes the first phase of every engagement as 'a couple of days onsite with the customer' before any building starts. That cadence is structural, not optional.
The stakeholder map
Every real customer problem has at least three stakeholders, and they do not agree. There's an executive who signed the contract, who cares about the headline outcome and the timeline. There's a middle manager whose team is affected, who cares about adoption and risk and not looking bad. And there's the individual end user, who cares about whether their day got worse. A solution that delights any one of these can be rejected by the others; a solution that survives requires all three. Inside the first two weeks of an engagement, an FDE should be able to name who fills each of these roles, what each one would call success, and where their definitions conflict. The conflict is not optional; it is information about the shape of the deliverable.
When to push back, and how
Pushing back on a customer's stated solution is a skill, not a moral position. The wrong way is to argue: 'actually you don't need that.' The right way is to make the alternative cheaper and more concrete. Build a tiny version of what you think the real problem is and put it alongside the literal interpretation of the request. Let them compare. Customers are not stupid; if you show them two artifacts and one is clearly better suited to their situation, they will choose it, and they will credit themselves with the insight, which is the right outcome. Save direct pushback for cases where the literal request is technically impossible or actively harmful, and budget those interventions. You probably get two per engagement before you start being seen as difficult.
Key takeaways
- •Stated problems are in the vocabulary of solutions already considered. Translate them back to the underlying situation before writing code.
- •Five questions: concrete incident, personal stake, prior attempts, who else, simplest acceptable version.
- •Sitting next to a user for a half-day reveals what no interview can. OpenAI's own engagement structure requires onsite days before building.
- •Three stakeholders per problem (exec, manager, user). They disagree. Map them before week three.
- •Push back by building, not arguing. Put two small artifacts side by side and let the customer choose.
Exercise
Pick a request you've received at work that started with 'we need [solution].' For each of the five framing questions, write down either the answer or the specific follow-up question you'd ask to find it. Notice which questions you can't answer; those are your real gaps with that stakeholder.
Self-check
- 1.Why is 'walk me through the last time this came up' more useful than 'what's the problem'?
- 2.What's the failure mode of solving for only the executive stakeholder?
- 3.Quote one of Krishnaswamy or Qureshi's framings of FDE work and explain why it shapes how you'd open week one.
- 4.When is direct pushback the right move, and what's the rough budget for it across an engagement?
Sources