Separate contact engagement from organizational buying decisions with questions to surface approvers and size presales
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
I recently worked a deal that showed every indicator of a late-stage opportunity: fast replies, detailed technical questions, contract discussion, revised quotes, refined scope. My contact was engaged from the first call through weeks of architecture, pricing, and security conversations.
Partway through, a second stakeholder joined the process. The central question moved from which developer to hire toward whether to build custom software at all, and the company chose a third-party platform. No competing developer won the work; the organization settled that underlying question on its own.
That outcome is a useful prompt for separating two signals that service businesses often collapse into one: how engaged a contact is, and whether their organization has decided to buy.
A champion inside a prospect's organization can explain the problem to colleagues, gather requirements, schedule calls, and push a proposal forward. That role is genuinely useful and often shapes the final scope of a project.
Four things sit outside a champion's control in most organizations: budget ownership, architecture approval, procurement rules, and executive sign-off. Any one of those can end a project on a timeline the champion doesn't set, on its own schedule, separate from how the working relationship is going.
One useful question for a technical consulting process, asked early: "Who else needs to be comfortable with this approach before the project can move forward?"
That question surfaces the people capable of changing the decision: a product lead weighing build-versus-buy, an IT lead evaluating architecture, a finance stakeholder setting budget, a procurement process requiring competitive bids, an executive scoping whether the problem is a current priority. Naming these people early gives a more complete picture of how many approvals sit between a strong conversation and a signed contract.
Detailed technical presales — architecture proposals, prototypes, several rounds of scope revision — fits naturally once three points are confirmed:
Each of those points can still be open while a champion is deep in technical detail with you. Unpaid architecture work done before they're confirmed is effort spent inside a decision the champion doesn't fully control.
This is the same tension covered from the positioning side in Update Your Developer Portfolio: Close the Sync Gap Now — a strong technical presence attracts engaged contacts, and engaged contacts still sit inside organizations with their own approval structure.
Two questions are worth tracking as separate entries for every opportunity in a pipeline:
A responsive, detail-oriented contact gives real signal on the first question. The second depends on people the champion may not control, and stays open until they've weighed in. Recording both numbers, rather than one blended estimate, gives a more accurate read on where a deal actually sits.
In the opportunity described above, the champion's engagement stayed close to full buy-in through weeks of technical work, and the organization's decision on build-versus-buy remained open until a new stakeholder joined months later. Separating those two numbers from the first call would have flagged the second one as unresolved long before the final decision arrived.
How can I tell a champion from an actual decision-maker? Ask directly who owns budget, who approves architecture, and who else needs to sign off before the project can start. A contact who can name specific people and a specific process is working with visibility into the decision. A contact who says "I'll handle it internally" is often still building that visibility themselves.
Does this mean I should stop building relationships with champions? Champions remain valuable through a sales process. They explain the problem internally, gather requirements, and introduce stakeholders. Confirming who else sits in the decision adds a second layer of information alongside that relationship, rather than replacing it.
When is unpaid technical presales worth the investment? Once the three points above are confirmed: the problem is agreed to be worth solving, the general solution type is settled, and the people who could override that agreement are in the conversation.
What if my champion doesn't know who else is involved in the decision? That answer is itself useful information. A champion without visibility into the rest of the decision places the opportunity earlier in the pipeline than the technical conversation alone suggests.
How do I ask about decision-making structure without sounding distrustful? Framing the question around project success — "who else needs to be comfortable with this approach" — reads as diligence. Pairing it with genuine technical engagement keeps the conversation collaborative.
If you're mid-proposal on a technical build and want a second read on where the buying decision actually stands, I work with a small number of founders and product teams on exactly this kind of scoping.
Let me know in the comments if you've run into a version of this in your own pipeline.
Thanks, Matija