Monday morning. 9:12 AM. You open your email before making coffee — a mistake you'll regret for the rest of the day.
Three emails from the VP of Sales. Sent at 11 PM on Friday. Subject lines:
"Northgate deal closed!! — need custom SSO by March"
"Bellweather signed — want white-label dashboard, 'discussed this with Sarah'"
"Re: Oakhurst — committed to webhooks integration, super straightforward"
You don't know Northgate. You've never heard of a white-label dashboard conversation. And super straightforward from a Sales leader is a phrase that has, in your experience, a 100% historical rate of being the exact opposite.
By 9:45 AM your Slack has twelve new messages, three of them from the Sales reps whose deals just closed, all of them containing some variation of the phrase "my customer is excited and just needs confirmation from the product team."
This is not a sales problem. This is not an engineering problem. This is the product manager's inheritance: a mountain of commitments made in the energy of a deal, none of them scoped, all of them carrying the emotional weight of customer expectations that are already set.
And the question isn't whether to honor them. At a growth-stage company, the answer is almost always yes. The question is: how do you build the bridge between what was promised and what's actually deliverable — without destroying the deal, the relationship, or your engineering team?
The Anatomy of a Sales Promise
Before you can build the Reality Bridge, you need to understand how sales promises actually work — because "Sales promised something unrealistic" isn't the problem statement. It's a symptom.
The real dynamics:
Sales is optimizing for signal, not certainty. In enterprise sales, vague feature promises serve a function: they keep the conversation moving. "We can explore that" and "That's on our roadmap" are technically true but directionally misleading. By the time the contract is signed and the specific commitment gets handed to Product, the Sales rep has already moved on to the next deal.
Discovery happens after the sale in startup land. In mature sales organizations, solutions engineers scope proposals before commitments are made. In growth-stage startups, there often are no solutions engineers. The PM is the solutions engineer — they just don't find out until the deal is closed.
Customers heard something different. When a Sales leader says "we can do that," the customer hears "this is coming in the next quarter." The Sales leader meant "this is technically possible for us to build." These are not remotely the same commitment.
The Sales team is doing their job. This is critical. The VP of Sales who closed three deals by promising features that don't exist is not a bad actor. At a startup, they're doing exactly what they're supposed to do: acquiring revenue by meeting customer needs. The organizational design hasn't yet built the structures that translate "what customers want" into "what we commit to deliver."
Understanding this isn't about excusing the pattern — it's about avoiding the trap of treating this as a Sales problem to be solved through confrontation. It's an organizational coordination problem to be solved through systems.
Why the Standard Fixes Don't Work
Fix 1: "Sales needs to involve Product before promising things"
In theory: yes. In practice, no. Sales cycles are unpredictable. Customer conversations happen in airport lounges, over dinner, in 15-minute windows between other calls. The moment a customer asks "can you do X?" the Sales rep is making a real-time probability assessment — they can't pause and say "let me get our PM on a call before I answer."
More importantly: if you make promise approval a friction point in the sales process, deals slow down. At a growth-stage company with limited runway, slowing deals is an existential risk.
Fix 2: "We need a feature request process"
This is the right direction but the wrong timing. A feature request process is a system for building the right things. The problem is not a build-planning problem — it's a commitment-tracking problem. You can have a perfect sprint planning system and still be destroyed by sales commitments that were never captured.
Fix 3: "We should just say no to custom features"
Fine for a mature product company. Fatal for a startup where the first 10 enterprise customers define the product through their requirements. The custom features that feel like distractions at the time often become the standard features that acquire the next 100 customers.
The Reality Bridge System
The Reality Bridge isn't a single meeting or doc. It's a three-layer system that runs continuously between Sales closing and Engineering shipping.
Layer 1: The Promise Registry
Every sales commitment gets captured in a shared register. Not in Salesforce. Not in a deal-level Notion doc. In a structured, PM-owned register that connects sales language to product language.
The register fields:
| Field | Why It Matters |
|---|---|
| What was promised (exact words) | Sales language ≠ product language. Capture both. |
| Which customer/deal | For prioritization against deal value |
| Expected delivery date (what Sales said) | The anchor expectation to work backward from |
| PM-scoped reality | What it actually takes to build — assessed after discovery |
| Engineering estimate | Hours/sprint-weeks from the engineering team |
| Roadmap impact | What gets displaced if this is prioritized |
| Status | Scoped / In-flight / Delivered / Negotiated down / Blocked |
This register does something important: it creates a shared vocabulary between Sales and Product. When a Sales leader can see that their last five deals generate a combined 14 sprint-weeks of engineering work that displaced two infrastructure items, the abstraction of "I'll loop in product later" becomes concrete.
Layer 2: The Discovery-First Rule
Before any sales promise gets entered into engineering planning, it goes through a 30-minute discovery call with the customer. Not a requirements call — a discovery call.
The goal of this call is to understand the actual need behind the promised feature. In the overwhelming majority of cases, the customer's actual need is significantly narrower than what was promised.
Common promise-to-need translations:
| Sales Promise | Actual Customer Need (Usually) |
|---|---|
| "Custom reporting dashboard" | Scheduled CSV export to their analytics team |
| "White-label the product" | Remove your logo from the app header |
| "SSO integration" | SAML with their existing Okta setup (existing library) |
| "Webhook support" | A single webhook on account creation events |
| "Custom permissions" | Two roles: admin and viewer |
| "API access" | Read-only access to one or two specific data types |
The discovery call script:
"I'm the PM working on your account. I want to make sure we deliver exactly what you need — not more, not less. Can you walk me through the specific workflow where you'd use [promised feature]? What does success look like for your team at the end of the quarter?"
Eight out of ten times, the answer to this question reveals that delivery can happen in 30% of the originally estimated engineering time.
Layer 3: The Honest Timeline Conversation
Once you have the scoped reality, you need a structured meeting with Sales to close the loop. This is not a negotiation — it's a translation.
The meeting framing:
"I talked to [customer] yesterday. Here's what I learned about what they actually need. The good news is it's significantly more tractable than what we were initially thinking. Here's my honest timeline for what I can deliver, what the trade-offs are, and what I'd recommend we communicate to them."
The Honest Timeline Document:
Customer: [Name]
What was promised: [Exact promise]
What they actually need: [Post-discovery scope]
Delivery timeline: [Conservative estimate]
What this displaces: [Roadmap items affected]
Recommended customer communication: [Specific language]
Risk if we miss this timeline: [Business impact]
This document transfers shared ownership of the commitment to both Sales and Product. The Sales rep is no longer waiting passively for delivery — they're co-owners of the timeline and the customer communication.
The Three Conversations That Build the System
Building the Reality Bridge isn't a one-time project. It's an ongoing relationship with your Sales organization that improves iteratively. Three conversations accelerate this:
Conversation 1: The Pattern Review
Every month, review the last 30 days of sales promises with your CRO or VP of Sales. Show the data:
- Number of promises made vs. scoped
- Average scope compression (promise size vs. delivery size)
- Engineering time consumed by sales commitments
- Deal value generating each commitment
This conversation isn't punitive — it's a shared learning loop. After two or three of these reviews, Sales leaders start self-moderating their promises because they can see the systemic effect.
Conversation 2: The Pre-Close Feasibility Check
Negotiate a lightweight pre-close check for your top deal tier. Not a veto — just a 20-minute PM review of any commitment above a threshold (e.g., promises for features requiring more than 3 sprint-weeks).
Frame it to Sales as: "This protects you. If the feature is simple, I'll confirm immediately. If it's complex, we can adjust the contract language before signing — not after the customer is frustrated."
Most sales leaders will agree to this after experiencing one or two post-close delivery disasters. It accelerates their credibility with customers, which ultimately helps them close.
Conversation 3: The Promise Vocabulary Workshop
Run a 45-minute session with your Sales team to align on language. Specific phrases that create specific (and manageable) customer expectations vs. phrases that create ambiguity.
| Don't say | Say instead |
|---|---|
| "We can build that" | "That's a use case we support — let me have our PM confirm the specifics" |
| "That's on our roadmap for Q2" | "Our PM can give you a timeline once I connect you." |
| "We do custom integrations" | "We have an API — let's understand your specific integration needs" |
| "We're very flexible" | "Let me get specifics — we want to promise what we can deliver" |
This workshop has a secondary benefit: it gives Sales the language to stay in the deal without making a commitment they can't keep. This is a skills upgrade for them, not a constraint.
Scaling the System as the Company Grows
The Promise Registry / Discovery-First / Honest Timeline system is designed for a company without a solutions engineering team. As the company grows, the system evolves:
Stage 1 (seed/Series A): PM owns all promise tracking and discovery. The register is a simple spreadsheet. This is sustainable up to ~20 sales deals per quarter.
Stage 2 (Series B): Hire the first solutions engineer or sales engineer. They own the discovery calls and the register. PM reviews and approves scoping. This extends the system to ~50+ deals per quarter.
Stage 3 (Series C+): Full solutions engineering team, formal CPQ tooling, contract language templates for common feature asks. PM shifts from tactical promise tracking to strategic pattern identification — using commitment data to build the product features that recur most often in sales conversations.
The skills you build in Stage 1 — accurate scoping, customer discovery, Sales relationship management — are the foundation everything else builds on. PMs who master this early become the architects of the products that win enterprise markets.
The Prodinja Angle
The Promise Registry is only as useful as the discipline to maintain it consistently. Prodinja's PM Shadow automatically tracks when sales commitments in your CRM diverge from items on your roadmap — and flags the gap before it creates a delivery surprise. It also generates timeline estimates with confidence intervals based on your team's historical velocity, giving you an honest basis for the customer conversation that sales leadership can trust.
Explore how Prodinja connects to the broader stakeholder management system that makes enterprise PM sustainable.
Key Takeaways
- Sales promises are a symptom of organizational coordination problems, not Sales dysfunction. Solve the system, not the person.
- The Reality Bridge is three layers: a Promise Registry, a Discovery-First rule, and an Honest Timeline conversation with Sales.
- Discovery compresses scope by 60-70% in most cases. What was promised as "custom SSO" is usually "SAML integration with Okta using an existing library." Talk to the customer before you estimate.
- The Promise Registry creates shared vocabulary — converting abstract sales commitments into engineering-week data that Sales leaders can see and self-calibrate against.
- Build toward the Pre-Close Feasibility Check. Getting invited into deals before they close is the ultimate leverage point — it prevents the problem instead of healing it.