Timing, Trust, or Product?
How to tell which kind of friction you’re actually facing, because the response to each is completely different.
Every builder in a transitional market learns to read friction. You have to. There’s so much of it.
The mistake most teams make is treating friction as undifferentiated signal.
Something is slowing us down, so they hold a retrospective, rewrite the roadmap, add a feature, or hire someone with a different background. The problem is that friction has different causes, and the response to each is completely different.
Get the diagnosis wrong and you’ll spend six months solving the wrong problem.
The timing problem
A timing problem feels like broad agreement with no forward motion.
The practitioners understand the problem. They can articulate exactly what’s broken. They’ve seen your solution, they like it, and they have no principled objection to it. But something prevents commitment. Integrations stall. Pilots get approved but never started. The person in the room is enthusiastic; the person who signs off is somewhere else.
The tell: you’re not hearing no. You’re hearing not yet.
Timing problems are rarely about the product being ahead of its time. They’re usually about incentives: internal ones that make change feel risky, external ones that make the status quo feel adequate. In markets with no normalization and no standardization, everyone has quietly adapted their workflow to the chaos.
The workarounds are load-bearing.
Nobody wants to be the one who pulled the wrong piece out.
You can’t build your way out of a timing problem. More features don’t move the needle. What you can do is stay close, stay credible, and understand whose incentives need to shift, and what would have to happen to shift them.
The trust problem
A trust problem looks like a timing problem, but has a different anatomy.
Warm reception everywhere. Genuine interest. Nobody can find an objection to the product, but nobody will be first. You start to notice a pattern: people want to know who else is using it before they commit.
The first question isn’t what does it do. It’s who else is doing this with you.
The tell: the real objection is never stated directly.
Trust problems are relational, not technical. They’re about who is building this, under whose roof, with whose backing. Not what they’re building.
In institutional markets, provenance travels faster than product specs.
The question underneath the question is always: can I afford to be wrong about this person?
The credibility you carry into a room isn’t just yours. It’s borrowed, earned, and sometimes inherited. That shapes what you can ask for and how quickly. If you’re facing a trust problem, more product won’t solve it. You need reference customers, the right warm intros, and visible evidence that someone the market respects has already made the bet.
The product problem
A product problem is the one builders are most reluctant to name, because it implicates the work.
The signs are subtle at first. Engagement without traction. People come to demos but don’t come back. The feedback is inconsistent: not this needs more features but I’m not sure this is what I need. Different users are describing fundamentally different versions of what the product should do.
The tell: you’re hearing interesting, but... and the but changes every conversation.
A product problem usually means you’ve identified real friction but mislocated its root. The market has pain, and you’ve built a solution for a related but different one. Or you’ve solved the visible symptom without touching the underlying mechanism. The users aren’t wrong to be ambivalent. They’re telling you something.
The response is uncomfortable: go back to the problem. Not to the solution, not to the roadmap. Back to the original question. What are people actually trying to do? What workaround are they using, and why does it work well enough?
The answer is almost always in the workaround.
How to tell them apart in practice
When I’m trying to diagnose which problem I’m in, I ask three questions:
Is the objection about capability or readiness?
If people agree the capability exists and just can’t act on it yet: timing.
If the capability itself is questioned: product.
Does the enthusiasm travel?
If the person in the room is excited but the decision goes nowhere: trust.
If the person in the room loses interest between meetings: product.
What’s consistent across independent conversations?
Timing problems have consistent signals: everyone’s waiting for the same catalyst. Trust problems have consistent hesitations: the same questions about provenance and who else is in. Product problems have inconsistent ones. Different people want different things, and none of them are wrong.
The messy middle generates all three simultaneously. Most complex markets have timing problems on one layer, trust problems on another, and product problems embedded in specific workflows. The work is isolating which is which. The moment you conflate them, you’re solving the wrong one. And the market will tell you, slowly.
Up next: what it means to build the neutral layer, and why it’s almost always politically harder than technically hard.