The meeting where product, sales, and engineering all had different definitions of "real-time"

It was a Tuesday afternoon in December and we were in a quarterly planning meeting. Product had put “real-time reconciliation dashboard” at the top of the Q1 roadmap. Sales was excited because they had been promising it to prospects. I was estimating engineering effort. Fifteen minutes into the conversation, I realized we were all talking about completely different things and nobody had noticed.

Generate a realistic dark editorial illustration for a fintech engineering article: layered ledger rows, payment states, query bottleneck cues, subtle SQL-console influence, deep navy and amber palette, 16:9, no text, no clip art, no fake corporate stock feel.

By this phase the work was no longer “just build it.” It also builds on what I learned earlier in “Why our compliance team rewrites my API specs and I have learned to be grateful.” 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 "Three Definitions, One Word" in the article "The meeting where product, sales, and engineering all had different definitions of "real-time"". 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 "The meeting where product, sales, and engineering all had different definitions of "real-time"". 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.

Three Definitions, One Word

Product wanted the dashboard to update without the user refreshing the page. When a new transaction arrived, it should appear in the table within a second or two. They were thinking about WebSocket connections and push-based updates to the browser. Their mental model was a stock ticker.

Sales had been telling prospects that our reconciliation engine processed matches in real-time, meaning the moment a bank statement arrived, it would be reconciled against pending transactions instantly. Their mental model was an ATM that confirms or rejects a transaction at the point of sale.

Engineering, meaning me and Raj, had designed the reconciliation engine with eventual consistency in mind. Bank statements arrive in batches, sometimes hourly, sometimes daily. We poll for new statements, process them through a matching pipeline, and surface results. The pipeline takes 30 seconds to 5 minutes depending on batch size. Our mental model was a mail sorting facility.

Three teams. Three mental models. One word that meant something different to each of us. We had been talking past each other for twenty minutes before anyone surfaced the disconnect.

How One Word Derails a Quarter

The damage was not just the wasted meeting time. Sales had already included “real-time reconciliation” in proposals to two enterprise prospects. Product had written user stories assuming sub-second processing. Engineering had estimated based on the existing batch architecture with a WebSocket push layer on top. Each team had made commitments based on their own definition.

• Sales had set client expectations for instant reconciliation that our architecture fundamentally cannot deliver
• Product had designed a user experience around immediate feedback that requires a complete re-architecture of the processing pipeline
• Engineering had estimated three weeks for a WebSocket layer when the actual scope was three months for a near-real-time pipeline
• Finance had approved a Q1 budget based on the three-week estimate

The real-time reconciliation that sales promised would require replacing our batch processing pipeline with a streaming architecture, which is a fundamentally different system. It was not a feature on top of our existing product. It was a rebuild of the core engine. The gap between what was promised and what was feasible was not a misunderstanding. It was a structural communication failure.

The Glossary That Saved Us

After the meeting I went home frustrated and did the thing engineers do when they are frustrated: I wrote a document. I titled it “FinanceOps Latency Glossary” and defined every time-related term we use in product discussions.

• Real-time UI: Dashboard updates push to the browser within 2 seconds of data availability (WebSocket)
• Near-real-time processing: Data processed within 30 seconds of arrival (streaming pipeline)
• Batch processing: Data processed in scheduled intervals, typically every 1 to 60 minutes
• Instant: Never use this word. Replace with a specific latency target.
• Live: Means different things to different people. Replace with real-time UI or near-real-time processing.

The glossary was two pages. I sent it to product, sales, engineering, and the CEO. The single most impactful part was the rule at the bottom: no one is allowed to use the word “real-time” in a client-facing document or meeting without specifying which definition they mean. If you cannot pick one from the glossary, you do not understand the requirement well enough to promise it.

What Actually Shipped

We shipped real-time UI in Q1, meaning WebSocket push updates to the dashboard when new reconciliation results are available. The reconciliation engine itself stayed batch-based with a 5-minute processing cycle. Sales updated their messaging to say “results appear on your dashboard within minutes, updated automatically.” It was honest, accurate, and clients were fine with it.

The near-real-time processing pipeline went on the roadmap for Q3, after we had done the architectural groundwork of moving from batch polling to event-driven ingestion with Kafka. That was always the right sequence. We just needed a shared vocabulary to see it clearly.

Create a realistic systems-style editorial image: simplified financial workflow, tidy relational structure, subtle success signal, graphite and ledger-green palette, 4:3, no text labels, no infographic clip art.

Operator mode means you inherit every downstream consequence. The code path is only half the story; the other half is how the decision warps planning, trust, and execution speed. I kept relearning that lesson while building ftryos and pipeline-sdk.

The most expensive misunderstandings in cross-functional teams are not arguments. They are agreements where everyone nods while picturing something different. A shared glossary does not prevent disagreement. It prevents the kind of false agreement that wastes months.

I keep the glossary updated and reference it in every planning meeting. It has saved us from at least three more “real-time” misunderstandings since December. The document took an hour to write. The meeting that inspired it wasted a quarter of planning time. Cheap insurance.

The vocabulary matters because it shapes expectations. When a product manager says real-time and an engineer hears real-time, they are often describing different latency tolerances, consistency guarantees, and infrastructure costs. Getting precise about which definition of real-time a feature actually requires prevents overengineering and underdelivering. The simplest version that meets the actual user expectation is always the right starting point.