When the sales team demos a feature that does not exist yet and engineering finds out from a prospect

On a Monday morning in February 2025, I got an email from a prospect asking for documentation on our “automated multi-currency reconciliation” feature. They had seen it in a sales demo the previous week and wanted to understand the API before signing their contract. I read the email three times. We did not have automated multi-currency reconciliation. We had single-currency matching with a manual currency conversion step. The feature the prospect was asking about did not exist.

Generate a moody startup meeting aftermath scene: roadmap cards, pitch deck on screen, notebook with engineering estimates, dark neutrals with amber accents, 16:9, no people, no cheesy corporate vibe.

By this phase the work was no longer “just build it.” It also builds on what I learned earlier in “The tech debt spreadsheet that made my cofounder finally understand why we need a refactoring sprint.” Every architecture choice had a people cost, an audit cost, and a recovery cost when production disagreed with the plan. That is roughly when the line between FinanceOps systems and projects like flowscape or ftryos got interesting to me: the design only counts if the operators can live with it.

Editorial supporting image for the section "How This Happens" in the article "When the sales team demos a feature that does not exist yet and engineering finds out from a prospect". Show open laptop with SQL query plan or ledger-like table visible, printed reconciliation notes, payment terminal receipt, notebook full of arrows and constraints for "When the sales team demos a feature that does not exist yet and engineering finds out from a prospect". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: deep blues, oxidized steel, warm amber monitor spill. Mood: tense but controlled, operational, carrying team and system weight at the same time. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No floating database icons, no cartoon locks, no holograms, no generic fintech stock imagery, no text overlays.

How This Happens

My first reaction was anger. How could sales demo a feature we had not built? But after talking to the sales rep, the situation was more nuanced than “sales lied.” What happened was a cascade of small misrepresentations that individually seemed harmless.

The sales deck included a roadmap slide showing multi-currency reconciliation as a Q2 planned feature. During the demo, the prospect asked about multi-currency, and the sales rep said “that is coming in our next release.” The prospect heard “it exists.” The sales rep thought they were communicating timeline. The slide was designed to show vision but was interpreted as capability. Nobody was being dishonest. The communication was just imprecise enough to create a false impression.

This is the kind of cross-functional failure that never happens because one person does something wrong. It happens because the communication chain between engineering, product, and sales has just enough ambiguity at each handoff that the final message does not match the original reality.

The Trust Erosion

The immediate problem was manageable. We contacted the prospect, clarified the timeline, and they agreed to sign with a contractual commitment for multi-currency delivery in Q2. But the deeper damage was to the trust between engineering and sales.

Engineers started second-guessing everything sales said to prospects. The next time a sales rep mentioned a feature in a call, an engineer interrupted to clarify that the feature was “in development, not in production.” The correction was accurate but it undermined the sales process and embarrassed the rep in front of the prospect. Sales started excluding engineering from prospect calls. Engineering started adding disclaimers to every internal feature update. The whole dynamic became adversarial.

• Engineering lost trust in sales accuracy and started micromanaging prospect-facing communication
• Sales lost trust in engineering timelines and started hedging by over-promising to close deals
• Product was caught in the middle, getting pressure from sales to accelerate roadmap items that engineering could not deliver
• The CEO was getting conflicting information from both sides about what was promised and what was feasible

The Feature-Readiness Framework

After three weeks of friction, I proposed a framework that would prevent this from happening again. The goal was not to restrict sales but to create a shared vocabulary for what is real, what is planned, and what is speculative.

1. Shipped: Feature is in production, tested, documented, and supportable. Sales can demo it live and promise it to any prospect.
2. Beta: Feature is functional but not fully tested or documented. Sales can mention it exists and offer early access with caveats.
3. Committed: Feature is on the roadmap with engineering capacity allocated and a delivery estimate. Sales can include it in contracts with a timeline.
4. Planned: Feature is on the roadmap but no engineering capacity is allocated yet. Sales can mention it as a future direction but cannot include it in contracts.
5. Exploratory: Feature is an idea being evaluated. Sales cannot mention it to prospects.

The critical rule was that engineering signs off on the readiness level of every feature before it goes into any sales-facing material. If a feature is labeled “Committed” with a Q2 date, that means an engineer has confirmed the scope, the capacity, and the timeline. If engineering has not signed off, the feature stays at “Planned” regardless of what product or sales wants to promise.

Making It Stick

Frameworks only work if they are enforced. We embedded the readiness levels into three places where they would be impossible to ignore.

• Every feature in our product management tool has a readiness level field that engineering updates weekly
• The sales deck pulls readiness levels automatically so slides cannot show a “Shipped” badge on a “Planned” feature
• Monthly sales-engineering sync meetings walk through every feature in the active sales pipeline and verify readiness levels match reality

The monthly sync meeting was the hardest to establish. Sales thought it was a policing exercise. Engineering thought it was a waste of time. It took three months before both sides saw it as a coordination tool rather than an oversight mechanism. The meeting consistently catches two to three readiness mismatches per month. Each one is a potential repeat of the multi-currency incident avoided.

Create a realistic editorial image of a technical planning desk after a difficult decision: cleaned-up notes, timeline revisions, calmer composition, 4:3, grounded startup atmosphere, no text.

By this stage the job had changed. I was no longer just picking a tool or fixing a bug. I was carrying the blast radius across product, compliance, sales, and hiring. That is exactly why I kept pressure-testing the same lesson inside ftryos and pipeline-sdk.

The problem was never that sales was dishonest. It was that the distance between engineering reality and sales messaging was too large and nobody was responsible for keeping them aligned. A readiness framework closes that gap by giving both sides a shared source of truth.

The multi-currency reconciliation feature shipped in Q2 as committed. The prospect signed and remains a client. The framework has prevented at least four similar misalignments since February. It cost nothing to implement except the willingness to have an uncomfortable conversation about why the problem happened in the first place.