B2B sales enablement workshop / 5 MIN READ
Make the roadmap conversation clear about what exists today
Keep present capability, development intent and approved commitments distinguishable.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A roadmap can explain direction, but a buyer may hear a date or feature mention as a delivery promise. Sellers need current approved language and a clear route for requirements that the existing product cannot meet.
What you will leave with: A roadmap discussion card with current state, uncertainty and commitment boundaries.
Use this when
- Buyers ask when an unavailable feature will arrive.
- Sales materials combine current functionality with planned ideas.
This is not legal advice or authority to make contractual feature commitments.
Establish the current capability first
Salesforce’s public services agreement distinguishes purchases from reliance on future functionality. Treat that as one supplier’s explicit boundary, and check your own organization’s approved terms and messaging.
Describe what the buyer can use today in the relevant product, plan and configuration. Confirm whether a capability is generally available, restricted, in preview or merely under consideration. These states should not be merged into a single affirmative answer. If the current product fails a mandatory requirement, say so before discussing possible future work.
Explain future direction at its approved level
Use only roadmap information authorized for the recipient and situation. A public planning statement, a private preview and an internal engineering idea have different disclosure boundaries. Check the date and owner of the material before reusing it.
State uncertainty in language the buyer can understand. Avoid a confident spoken promise followed by a tiny disclaimer that contradicts it. If timing is not committed, explain that clearly. Do not translate an internal target into a customer deadline, or describe a prototype demonstration as evidence that production delivery is inevitable. Product development can change scope, sequence or direction.
Explore the requirement behind the request
Ask what task the missing capability would support and what constraints make it important. This can reveal whether an existing approved approach meets the need or whether the gap is genuinely disqualifying. Any workaround should be accurate about effort, limits and support.
Capture the requirement for the product team through the agreed route without promising prioritization. Distinguish interest from a binding customer condition. If a special commitment is being considered, involve the authorized product, delivery, legal and commercial owners. A seller’s desire to close the evaluation does not establish that the organization can safely make the commitment.
Confirm the buyer’s decision basis
In the recap, separate current capability from discussed future direction and unresolved requests. Ask the buyer to correct any misunderstanding. If they can proceed only with a guaranteed future feature, keep that condition explicit rather than marking the account as fully suitable.
Update the conversation when approved roadmap information materially changes and the organization has an appropriate obligation or permission to communicate it. Keep earlier assurances from lingering in active proposals. A responsible roadmap discussion lets the buyer choose based on a clear picture of what is available and what remains uncertain.
Make the reasoning concrete.
A fictional software buyer needs an audit export before a regulated reporting deadline. A salesperson has seen an internal prototype and wants to say it will be ready in time.
Convert the prototype into a promise
Opening: Assure the buyer that delivery will precede their deadline.
Hypothesis: The evaluation may continue smoothly.
Risk: The seller lacks an authorized delivery commitment and may mislead the buyer.
State the current gap and approved direction
Opening: Explain existing capability, disclose only permitted plans and escalate the deadline requirement.
Hypothesis: The buyer can evaluate the actual risk.
Risk: The current offer may not be suitable for this purchase.
The seller records the deadline as a mandatory requirement and does not claim it is met. Any possible commitment goes through the authorized review, and the buyer receives an accurate current-state summary.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Current state
What can this buyer use today?
Status
Is the future item a public plan, private preview or internal idea?
Permission
What roadmap information is approved for this audience?
Requirement
What task and deadline make the feature necessary?
Commitment
Who can authorize a binding promise, if one is possible?
Watch for the wrong conclusion.
- Turning an internal target into a customer deadline.
- Using a disclaimer to contradict a confident verbal promise.
- Marking a mandatory feature gap as resolved because a prototype exists.
Your next action
Audit one roadmap answer and separate its current capability, approved future statement and unresolved buyer condition.
Sources & scope
The workflow, worksheets and hypothetical examples are original editorial analysis. Sources support only the identified principles. No measured business results or named human reviewer are claimed.
- Salesforce Main Services Agreement, updated 15 October 2026 →Primary supplier agreement · Supports: The agreement distinguishes purchases from reliance on future functionality; this is an example of a supplier boundary, not universal legal advice.