The meeting ended well. The deal went nowhere.
Picture a platform engineer trying a new data tool. The demo runs cleanly. The engineer asks detailed questions, stars the repository, and says it could help with an internal project. Two weeks later, the next meeting is still not on the calendar.
It is tempting to read this as a follow-up problem. Perhaps it is. But the engineer may have learned everything they needed without ever having a budget, a migration window, or permission to introduce a new supplier. Technical interest was real. A purchase was never the next agreed step.
In this hypothetical account, the useful next step is to understand who could make that purchase happen. The buying map below is a working framework, not survey evidence. It should change when a real account proves it wrong.
Start with the workload, not the regional slide
‘We are expanding in APAC’ is useful company context. It does very little to qualify a first conversation. I want to know which workload is causing pain, what it costs to leave it alone, and why someone would change it now. A slow internal dashboard, an unreliable fraud signal and an expensive reporting pipeline do not have the same buyer or urgency.
Country is one dimension, but not a substitute for understanding the account. A regional headquarters, a local subsidiary and a founder-led company may make decisions differently even when they share a postcode. I would not infer their approval process from a country stereotype.
For a Southeast Asia plan, I would build a small account sheet before building a large territory model. Record where engineering sits, who operates the workload, which entity would sign, who owns the budget, and where the data would run. Treat residency and procurement requirements as questions to validate with the buyer’s specialists, not assumptions to put in a sales deck.
Text version
Working account map · roles may overlap
- Technical champion: Can test the tool and explain why it helps.
- Workload owner: Owns the operational problem and accepts the migration risk.
- Budget + approval: Can fund the change and bring in procurement or security.
One enthusiastic engineer is not evidence that the other roles are covered. Ask who else needs to participate.
A pilot should settle a question
An open-ended proof of concept is easy to start and difficult to finish. The vendor sees activity. The customer sees another experiment. Nobody has written down what a successful result would allow them to do.
A short pilot agreement can fix some of this. Use one representative workload, name the customer owner, describe the current baseline, and agree on a decision date. Ask the customer to define the performance, reliability or operating-cost target that would justify a change. Do not choose the easiest benchmark and call it the business case.
Also agree on what happens after a positive result. Is the next step a paid deployment, a security review, or a budget request? If there is no next step, say so. A useful technical evaluation is still worthwhile, but it belongs in a different forecast category from an active purchase.
Text version
Proposed pilot contract
- Before the test: Named owner, baseline workload, success criteria
- During the test: Record results and migration effort, including failures
- Decision review: Proceed, stop, or extend for one stated reason
A positive technical result still needs a funded deployment path. Schedule that conversation before running the test.
Give a partner an actual job
A partner logo on a regional slide does not explain who will do the work. I would bring in a partner when there is a concrete gap: implementation capacity, an existing customer relationship, a contracting route, or support coverage the vendor cannot provide. Those are different jobs and deserve different agreements.
Ask a blunt question: what becomes easier for this customer because the partner is involved? If the answer is unclear, the extra handoff may slow things down. If the answer is implementation ownership, put that person in the pilot planning session. Do not wait until the deal is signed to discover who will migrate the workload.
The same test applies to localization. Translating a landing page can help readers understand a product. It cannot resolve an unclear deployment model or a missing operator. Let specific account friction determine what to localize first, then check whether it actually removed the friction.
The next meeting is the useful artifact
At the end of discovery, I would aim for something more concrete than ‘great discussion’: a named workload owner, an agreed question to test, and a meeting where the right people can decide what follows. If those are missing, the next task is discovery, not a more elaborate demo.
This does not make regional selling mechanical. Relationships, timing and credibility still matter. It does make the uncertainty visible. A team can decide to invest in an early technical relationship without pretending it is a late-stage opportunity.
For a small team, that distinction is valuable. You only have so many engineering hours to lend to pilots. Spend them on work that teaches both sides something, and be honest about whether the lesson can lead to a purchase.
04 / Reader discussion
Continue the conversation.
Add a thoughtful question or perspective. Every comment is reviewed before it appears publicly.
Loading discussion…