Patterns in Discovery from 100+ Salesforce Consultants
With the goal of discerning why implementation projects fail, I've spent the better part of the last two months on calls with Salesforce consultants, solutions architects, delivery managers and basically every other position you can think of that touches an implementation.
I started these calls with the assumption that projects are failing because teams are failing to execute — not enough code being written etc., which was wrong. After a few of these conversations all arrows were pointing towards pre-sales discovery and... untrue assumptions.
There's a lot of interesting patterns that emerge and I wanted to highlight three of the biggest ones I've seen below.
1. The answers are in-between the lines
Your clients don't really know what they want. Or, if they do know, they are not able to articulate it clearly. But you already know that.
What you might not know, is why?
Years of work with the same systems desensitize people to inefficiencies that are super obvious in hindsight. Many of the workarounds and shortcuts are "just how it is". A good consultant's job is to poke and prod until they find these.
This is a tough task for various reasons across different types of customers, but here two of the overarching reasons that I've found.
Firstly: Discovery answers are role scoped
You can ask five stakeholders, "How does approvals work?", and get five confident, but completely different answers — and all of them are true! Individual stakeholders know their workflows best, and don't know (or in many cases don't have access to) the downstream failure modes. Piecing together coherent but local workflows at the org level is key.
Secondly: The ideal workflow is not the current one
In discovery, clients often describe work "as imagined". What I mean by that is they are describing the cleanest possible version of their workflows that should happen — the version that exists in decks, process docs, and kickoff slides.
More often than not orgs are running on invisible shortcuts, exceptions, and handoffs — the most important of which consistently go unmentioned because they feel so normal.
For example, a team might answer our earlier question about approvals with "approvals happen in Salesforce," but in practice the final sign-off is a 👍 on Slack, and the finance check is in a half abandoned spreadsheet.
Across junior → senior folks, the biggest skill difference I notice is the ability to read between the lines and identify all of the little tells and hesitations that clients have while talking about their needs.
2. Fuzzy communication is a silent killer
It's easy to discern when something is too vague. You can stop the meeting and drill into it.
It's way harder to discern whether something has enough detail. When everyone nods after a client says something it makes sense to second guess if the gap you just thought about is real.
Falling into the trap of thinking
"It felt clear in the meeting → it's buildable"
is often inevitable.
Small ambiguities compound during discovery:
- vague discussion → wrong requirements harvested
- wrong requirements → SOW locks the wrong things
- locked wrong things → design + build on unstable base
- unstable base → scope change + budget blowups + rework + trust loss
Over the course of the pre-sales process small bits of fuzzy communication stack up and cause fundamental misalignment that is invisible until delivery. Even when consultants are super diligent about taking notes, reviewing summaries, producing proposals and decks, etc. there's always layers of context that don't fit cleanly into existing artifacts.
It's really hard to articulate the "they kind of agreed" or "they seemed okay with it" moments that obviously have implied constraints that were felt but not agreed upon.
3. Structural Tension
Pre-sales discovery has incentives such that it isn't a pure search for truth. It's attached to a deal, and deals run on momentum.
Pre-sales structurally asks you to do two opposite things at the same time:
- Keep energy/morale high during the deal
- Reduce uncertainty of the project
The first one is more immediately relevant — as it wins the deal. So it makes sense that early conversations are nudged in the direction of being "crisp" and forward-moving.
There's a lot of pressure created here to converge on a shared reality before one actually exists. The fragmented perspectives and fuzzy communication that we discussed earlier can't get resolved under the weight of deal momentum.
Nobody wants to derail a promising deal over edge cases that might not matter. And sometimes it's not even your call, clients have procurement timelines, budget cycles, and internal politics that force compression whether you like it or not. It takes judgment to know which details are worth slowing momentum for, and which ones can wait. But when too many "we'll figure that out later" moments accumulate, they create a hidden layer of assumptions that never get explicitly surfaced. When convergence is reached and everyone feels aligned, more often than not everyone has mapped the conversation onto their own version of the customer's reality and walked away satisfied for different reasons.
Many traditional systems of record have been implemented to address this, but just logging decisions in a meeting was never enough. Most systems focus on capturing decisions and requirements. They are less suited to capturing hesitation, partial agreement, or evolving assumptions, which tend to live in conversations rather than artifacts.
You need to be tracking what was assumed, inferred, or deferred, not just what was agreed upon.
When delivery begins, it forces this false convergence to conform with execution constraints. Momentum is secondary to execution, and the compressed uncertainty expands back into the room.
So what?
Across all of the above the common thread is that: discovery fails when uncertainty is mistaken for alignment.
The best consultants I spoke to weren't just better communicators or Salesforce experts. They were disciplined about separating what was known from what was assumed. They surfaced deferred questions, innately understood their downstream effects, and acted on any uncertainty.
Building technology is the easy part. Understanding how people really experience the problem is the hard part.