"The biggest risk on this project is what happens after discovery."
That line came from the sponsor of a CRM build we're running for a manufacturer. Discovery was almost done. The data model was close to sign-off. And the part worrying them most was not requirements, scope, or the integration plan. It was the six weeks after discovery, when the project leaves the workshop and disappears into build.
I think that's right.
I've watched that stretch do more damage to CRM projects than bad requirements ever did.
Sign-off is where the client stops seeing the work
Discovery is a comfortable phase. People talk. Whiteboards fill up. A Miro board starts to look like progress. The client explains how the business works, the delivery team translates that into objects and processes, and eventually both sides sign a document.
Then the project becomes invisible.
That is the moment the real risk starts. The client did not approve a HubSpot portal. They approved an abstraction of their process. What they pictured in their head was usually their current way of working, cleaned up and drawn more clearly. So when the first real pipeline, record, form, or workflow appears late in the project, they're not reviewing a build. They're seeing their own process rendered in software for the first time.
And when that first look happens in week seven or week eight, every surprise lands as a mistake.
That is the problem. Not that the team built the wrong thing on purpose. Not that discovery was useless. Just that the first concrete version showed up too late for the business to react without feeling like something had gone off track.
We've done this ourselves. A build can follow the signed design faithfully and still create a bad client experience if the first real screen appears near the end.
The design document still earns its place
The obvious reaction is to say discovery is the problem and the fix is to skip it. I don't think that's true.
A signed scope is what stops a ten-week CRM project from turning into a thirty-week one. Requirements work matters. A data model reviewed up front still saves pain later. A proposal or scope document is often the only thing stopping a project from picking up three extra departments and a second round of approvals halfway through build.
To be fair, there are projects where people hide behind documentation instead of making decisions. That's real. But the answer is not to throw away design. The answer is to stop treating sign-off like a handoff.
The document is a starting position. It is not the last meaningful moment the client needs to see the work.
Show the client a real record every two weeks
The fix we keep coming back to is not sophisticated.
Build a piece. Show it. Adjust it. Build the next piece.
On the manufacturer project, we agreed on a fixed review cadence every two weeks. No big reveal at the end. No six-week silent build window. Whatever exists gets shown. If the pipeline is half-built, we review half a pipeline. If only one object is ready, we review one object. The point is not completeness. The point is keeping the business attached to the shape of the build while it is still changing.
That only works if the reviewable parts come early.
Infrastructure can go in first without much discussion. Tracking code, sending domain, connector setup, and other technical groundwork usually do not create debate. Fields, pipelines, lifecycle rules, and handoff logic are different. That is where the client's process meets the screen. That is where you find the "that's not what I meant" moments.
A field list on a whiteboard rarely causes tension. The same field shown on a real company record does.
The same thing happens with stage design. In a workshop, a sales leader will often agree that a stage like "Quoted" or "Commercial Review" makes sense. When they see it inside an actual deal record, with entry criteria, required properties, and automation attached to it, the real objections finally show up. That is useful. It is much cheaper to get that objection in week three than during UAT.
The other rule is simple: walk into review sessions with something real already built.
One of my team is doing exactly that on a sales process workshop this month. Before the session starts, they are drafting the pipeline in HubSpot from the client's own documentation so the meeting begins with a real object to react to. People are much better at saying "that stage is wrong" than they are at inventing the right stage from nothing.
That is not a flaw in the client. It is just how review works.
The other risk is a new face in week eight
The same sponsor named a second risk, and it is tied to the first: someone senior arrives late.
A new VP of Sales joining in the last third of a CRM build is a predictable problem. They have not been in discovery. They did not sit through the trade-offs. They have no memory of which options were rejected and why. What they do have is authority, fresh opinions, and very little reason to trust decisions they didn't help make.
Under a big-reveal model, that person sees the finished build cold. One sentence can reopen three months of work.
Under a review cadence, there is at least a trail. Versions exist. Review notes exist. Rejected options exist. The new stakeholder can still disagree, but now they are disagreeing with a visible sequence of business decisions rather than reacting to what feels like a surprise delivered by the implementation team.
That does not remove the politics. It does make them easier to manage.
The goal is not perfect discovery
The goal is not to write a discovery document so thorough that nothing surprises anyone later.
That is fantasy.
The goal is to reduce the distance between the abstract design and the real system. If the business only sees diagrams until the build is nearly complete, you are storing up avoidable conflict. If the business sees real records, real stages, and real handoff logic while the work is still moving, the project stays grounded in something people can judge accurately.
That is a better way to run a CRM build.
If you've been on the client side of one, I'd like to know when you first saw a real pipeline or record. Was it early enough to change anything that mattered?
by Perry Nalevka on September 25, 2026
CEO of Penguin Strategies
