Stated vs Revealed Preference

This is the number one trick I use when deciding what and how to build on our GTM Eng team at Vercel.

What is stated vs revealed preference?

It's an economic principle aimed at understanding what people say they want versus what they actually do.

The concept comes from economist Paul Samuelson, who developed revealed preference theory in the late 1930s. The core idea is simple: actions reveal preferences more reliably than words.

A quick example:

You say that you wish you didn't need a car, could commute by train, and lived in a walkable part of town. You hate your long car commute. That's your stated preference.

But your revealed preference tells a different story: you live in the burbs with a big SUV and lots of space. You enjoy the quiet evenings and listen to podcasts on your drive while slamming Starbucks.

You learn more about what is true in the world via revealed preference.

Why this matters for GTM Engineering

AI is amazing — everyone has a million ideas for how it can be applied. Lots of the ideas are good, even! But problem selection is critical so that you can keep your team focused on the highest ROI work.

The challenge is that when you ask people what they want, you get stated preference. They'll tell you about the shiny future they imagine. That's useful for understanding direction, but not necessarily for understanding urgency or willingness to actually change behavior.

So I use this question to uncover what we should actually build:

"How are people solving that today?"

The answer you're looking for is a wild, manual, painful process.

Someone copying and pasting between three different systems. An ops person maintaining a massive spreadsheet that takes hours to update. A developer running the same script manually every morning before their coffee.

These are signals of revealed preference. They've already decided this problem is worth solving — they're just solving it poorly.

The red flags

If the answer to "how are you solving this today?" is one of these, proceed with caution:

• "We haven't tried it yet"
• "We don't do it because XYZ"
• "We've been meaning to but never got around to it"

These responses don't necessarily mean it's a bad idea. There could still be something valuable buried in their request. Add it to your backlog, but keep it in the bottom third of the list.

The difference is urgency. When people are already hacking together solutions — even terrible ones — they've proven they care enough to act. That's the strongest signal you can get.

Good discovery works internally too

This isn't just for customer conversations. I use the same framework when prioritizing internal tools and automations.

When someone on the team says "it would be nice if we had X," I ask how they're handling it now. If they shrug and say they just skip it, that's one priority level. If they pull up a Google Doc with a 47-step manual process they run every week, that's a completely different conversation.

The hack they've built — no matter how ugly — is proof that the problem is real and worth solving.

Finding pay dirt

The best opportunities sit at the intersection of:

1. A painful manual process that already exists
2. High frequency (they're doing this often)
3. Clear ownership (someone actually cares about the outcome)

When you find all three, you've found pay dirt. Build that first.

Everything else can wait.