How do you qualify a prospect on implementation readiness without showing the product?
How do you qualify a prospect on implementation readiness without showing the product?
Implementation readiness is the hidden third gate in discovery. You can have pain, budget, and timeline—but if prospect's team can't absorb change (no IT bandwidth, no project manager, no sponsor), the deal stalls post-signature. Qualify this before demo.
The Implementation Readiness Checklist (Discovery Frame)
You don't ask these as a form. You weave them into natural probe questions:
| Readiness Area | What You're Checking | Diagnostic Question | Red Flag Answer |
|---|---|---|---|
| Sponsor clarity | Does someone own success post-close? | "Who'd be your day-one project lead if we moved forward?" | "TBD" or "Probably IT" (no name) |
| Timeline realism | Can they actually start, or is it fantasy? | "If we signed in May, when could your team go live with a pilot?" | "Depends on IT schedule" (vague gate) |
| Org change readiness | Will team adopt the new process, or fight it? | "How did your team respond when you last implemented a new tool?" | "We had to force it" (low buy-in) |
| Technical debt | Is their infrastructure ready, or will integration stall? | "What does your current stack look like? Any compliance constraints?" | "We're not sure; haven't audited in 2 years" (risky) |
| Competing priority | Will this stay a priority, or get deprioritized post-launch? | "Over the next 6 months, what's your team's #1 initiative?" | "This is #3, maybe #2" (low juice) |
| Budget for ops | Do they fund ongoing training/support, or expect free setup? | "After we go live, how do you typically budget for ongoing training?" | "It's built into salary" (no budget for adoption) |
The MEDDPICC "Impl Plan" Deep Dive
MEDDPICC has an Impl Plan leg specifically for this. But most reps treat it as "How long will setup take?" The real questions are:
- Sponsor: *"Who owns the business outcome post-launch? When can they commit 4 hours/week?"*
- Resource plan: *"Do you have a dedicated project manager, or will this be hat-on-hat?"* (Hat-on-hat = person doing it as side duty = high risk of stall.)
- Change sequence: *"When you've rolled out tools before, what was your go-wide strategy? Phased or big bang?"*
- Rollback trigger: *"If adoption is slow, what's your failure threshold—when would you pause and regroup?"* (Tells you if they have a realistic kill-switch, not just optimism.)
Operator Moves (MEDDPICC Impl Probe)
- Separate "they can afford setup" from "they can execute setup." Prospect has $50K budget, but IT team is 2 people and booked 6 months. That's a qualified deal that will fail. Disqualify or extend timeline.
- Ask for the Sponsor's name early. If you're talking to a manager and they say "I'll need to get approval from my director," ask: *"Great. Does your director typically stay hands-on during rollouts, or does she delegate to you?"* You're testing if Sponsor will actually show up.
- Listen for "tight timeline" in disguise. Prospect: *"We need this by Q3."* You: *"What makes Q3 the gate? Is there a business driver, or could it flex to Q4 if we need?"* If they say "It's arbitrary," you have a real timeline. If they say "Board commitment," they have a hard gate—plan accordingly.
The SaaStr Implementation Readiness Quadrant
SaaStr's playbook frames implementation readiness as 2D:
Only advance deals in Quadrant 1 (top-right). Quadrant 4 (top-left) needs timeline reset. Quadrants 2–3 are disqualification or significant extension.
TAGS: implementation-readiness,MEDDPICC,sponsor,project-readiness,qualification-gate,saas,discovery-call
FAQ
What does "implementation readiness" mean and why qualify it before a demo? It's the hidden third gate in discovery: a prospect can have pain, budget, and timeline, but if their team can't absorb change with no IT bandwidth, no project manager, or no sponsor, the deal stalls post-signature.
Qualifying it before demo prevents you from advancing a deal that will fail after the contract is signed. The article frames it alongside pain, budget, and timeline as a co-equal gate.
What does a "hat-on-hat" answer tell me about resourcing risk? Hat-on-hat means the implementation will be handled by someone doing it as a side duty rather than a dedicated project manager. That signals a high risk of stall because no one owns the rollout full-time. Ask "Do you have a dedicated project manager, or will this be hat-on-hat?" to surface it.
How do I separate "they can afford setup" from "they can execute setup"? A prospect can have a $50K budget yet have an IT team of two people booked solid for six months, which makes it a qualified deal that will fail. Budget proves affordability, not execution capacity. When the two diverge, disqualify or extend the timeline rather than push forward.
How do I test whether a "tight timeline" is real or arbitrary? When a prospect says "We need this by Q3," ask "What makes Q3 the gate? Is there a business driver, or could it flex to Q4?" If they say it's arbitrary, you have a real, flexible timeline. If they cite a board commitment, you have a hard gate and should plan accordingly.
How does SaaStr's implementation readiness quadrant guide which deals to advance? SaaStr frames readiness on two axes, sponsor commitment and tech readiness. Only advance deals in Quadrant 1 where the sponsor is in and infrastructure is ready. Quadrant 4 (sponsor in, infra shaky) needs a timeline reset and roughly a three-month ramp, while Quadrants 2 and 3 call for disqualification or significant extension.