The term Reality Distortion Field, or RDF, became famous inside Apple’s original Macintosh team. It described Steve Jobs’ ability to make seemingly impossible things feel possible.
At its worst, that sounds like denial. But there is a useful question underneath it: are we sure this is actually a constraint?
I think that question belongs in product management, especially as the role starts to look more like being a founder.
Getting closer to the problem
A forward-deployed PM works alongside the customer. They watch how the work gets done and figure out, with the customer and engineers, what needs to change.
That proximity matters because a requirement rarely arrives with its full history attached. Something that looks necessary may be a workaround for a problem nobody has revisited.
Imagine a customer says, “We cannot automate this process. Five people need to approve it.”
You could design five approval steps. Or you could ask why five people need to approve it.
Maybe regulation requires it. Maybe one person makes the decision and the other four compensate for unreliable data. Maybe the process has existed for ten years and nobody remembers why.
Those are very different problems, even though the initial request sounds the same.
Distortion needs detection
What interests me about RDF is the questioning. You have to understand a process before you can tell whether the constraints around it still make sense.
But persuasion without that understanding is dangerous. You can become very good at getting people behind a bad idea.
So the skill is partly reality distortion and partly reality detection. You need enough belief to imagine a better way, and enough judgment to recognize a constraint that really cannot change.
The loop looks something like this:
Understand the workflow Question the assumptions Propose something better Build and deploy Observe what happens Repeat
The last two steps matter. A persuasive explanation is still only an explanation until it meets the customer’s actual work.
What becomes more valuable
AI can help write requirements, organize research, and build prototypes. But when nobody is quite sure what the problem is, someone still has to work through it with the people involved.
That also involves sales. A customer has to see enough value in a different way of working to try it. Founders face this with customers, employees, and investors. A forward-deployed PM faces it inside the workflow they're trying to improve.
So I'd be careful about treating RDF as permission to ignore constraints. Ask why they're there, then test whether a different approach actually works.