Thinking tool: Find problems, not applications for solutions

Headshot of Adam Jones

Adam Jones

It's easy to get excited about an idea for something to do. Being energised about new ideas is generally good!

But it's usually more effective to start from the problem: understand an important problem, then test many solutions against it - rather than taking a product and testing it against many problems, markets and customers.

People care about their problems, not your solution. If they see you're committed to solving their problem rather than selling your solution, they're far more likely to give you their time, attention and feedback - which gives you a feedback loop to improve whatever it is that you're doing.

Two mirrored panels. Solution first: 'your solution' on the left branches rightwards into three boxes each labelled 'a problem'. Problem first: 'their problem' on the right branches leftwards into three boxes each labelled 'a solution'

This is the same move as backwards chaining, pointed at a problem instead of a goal: hold fixed the thing you actually care about, and search over the thing you get to choose.

Palantir's FDE model

Bad imitators treat forward deployed engineers (FDEs) like sales engineers: go into a customer, make the solution work there, and hunt for use cases it could serve.

Instead, the best Palantir FDEs would do something very simple:

  1. Figure out what the most important problem was for the organisation
  2. Solve it by any means.

Especially early on, this led to some crazy custom solutions that barely used the core Palantir product. But when something became a pattern, that learning got distilled into the product - and it often did.

Solving the problem often means not doing what your job title suggests. In one urgent government crisis, I remember FDEs doing data entry gruntwork for ~72 hours straight, sleeping in shifts in a nearby meeting room. It was simply the most important thing to be done, and they were among the only people with the IT access to do it. It likely saved several lives.

For more on this, see Ted Mabrey's (Palantir's Head of Commercial) blog "Sorry, that isn't an FDE". A quote:

Much like the sometimes abrasive French waiter cares more about you having the best meal than you do, FDE’s are trained to view themselves as owners of their customers’ businesses.

You must hold yourself accountable to the end results of the customers business and try to act as if you are the CEO, but with zero authority. This alignment constantly demands more of our product. We have a visceral connection to how much more a customer could win if the product could just do a little bit more for them.

Instead of a customer facing engineer whose actual job is to reduce scope to shrink the customers ambition down into what a product does today, we own that every single reason the customer might lose is a shortcoming in what our product can do for them. Those shortcomings define our roadmap.

Applying in practice

This applies across areas that dramatically vary in scale and shape. For example:

  • In product development, the number one mistake is not speaking with users. The number two is talking about your solution instead of their problems - there's a whole book about avoiding it. (Okay, it makes other points too. But that's the key one.)
  • I'm sceptical of "AI centres of excellence", which usually feel like pushing a solution rather than solving a problem. To adopt AI well, it might weirdly be more effective to start a "general" centre of excellence that:
    1. trains people to have broad multidisciplinary problem solving skills, which should include deep knowledge of AI including having truly understood many AI integration case studies
    2. rotates these people across teams in the organisation, tasked with helping solve that team's problems most effectively
  • At work, someone suggests a standing meeting between two teams working closely. But if the teams don't actually need to interact, or are already aligned, the meeting is a waste - and your calendar fills with these. Better to start from the specific problem: confusion on a particular topic, regular communication failures, or teams that aren't bonding. Each works backwards to a much more targeted solution, or at least a clear agenda.
  • When job hunting, people often start from "here are my skills, who wants them?" rather than "here is an organisation's problem, can I solve it?". The second framing writes a much better application, and often reveals roles that were never advertised.
  • Open source projects that get traction usually start because the author personally hit a problem and solved it for themselves. Projects that start from "I want to build a library using this cool new technique" basically never get big.
  • The best gifts feel personal and valuable because they demonstrate the giver has carefully understood what's going on in the other person's life and how to help them. It feels much worse to be given a gift that feels like a solution to a problem you don't have.

This is part of my thinking tools series. Also consider:

  • Backchaining is in some sense the dual of this: start from the goal and work backwards, rather than starting from your solution and working forwards
  • Framestorming keeps you exploring the problem space instead of the solution space
  • Climb the user-contact ladder: real problems come from real users