Turn Gong Sales Call Insights into Product Decisions

Atisbo was previously called GetSenso. This archive post predates some product changes — notably, Atisbo now runs an MCP server, so coding agents work the same prioritized backlog your team does. See the docs for current details.

Every day, your sales team is having the exact conversations your product team wishes they could have. Prospects are telling them exactly why they are evaluating your product, what the competitors are offering that you lack, and the specific feature gaps that are preventing them from signing a contract today.

"We love the platform, but we can't sign until you have SSO."

"This looks great, but without a native Salesforce integration, our RevOps team will block the deal."

These are not casual feature requests. They are deal-breakers with immediate, quantifiable revenue attached to them. They are the highest-signal product research your company conducts.

And yet, in most B2B SaaS companies, these signals die the moment the Gong call ends.

The sales rep might drop a quick note in a Slack channel ("Lost another one to lack of SSO 😞"), which gets three emojis and is quickly buried. Or they might log it in Salesforce under a generic "Closed Lost Reason: Missing Feature" dropdown. The actual context—the nuance of the prospect's workflow, the specific workaround they rejected, the urgency of the request—remains locked inside a 45-minute call recording that the product team will never have time to watch.

This is not a failure of your sales team, and it is not a failure of your product team. It is a structural failure of how product discovery is conducted.

Why Sales Feedback Rarely Reaches the Roadmap

The default approach to extracting product signal from sales calls is manual reporting. A product manager asks the sales team, "What are you hearing out there?" and the sales team gives them a list of the five things they lost deals over that week.

This breaks down for three reasons.

First, recency bias. Sales reps are human. They remember the deal they lost yesterday, not the deal they lost three weeks ago. When a PM asks for feedback, they get the loudest, most recent pain points, not a statistically significant sample of the market.

Second, the "Feature Factory" translation problem. Prospects rarely diagnose their own problems correctly. They ask for a specific solution ("We need a button that exports this to a CSV") when their actual problem is different ("We need to share this data with a vendor who doesn't have a login"). When sales reps pass feedback to product teams, they often pass the requested solution, not the underlying problem. Without the original call transcript, the product team has no way to investigate the root cause.

Third, the lack of aggregate revenue context. A PM might hear that three different prospects asked for a specific integration. What they don't hear is that those three prospects represent $450k in pipeline ARR, while the feature the engineering team is currently building was requested by ten free-tier users. Without a system to tie feature requests directly to pipeline revenue, prioritization becomes a guessing game.

The Four Signals Hidden in Your Sales Calls

Before building a system to extract product signal from Gong, it helps to be precise about what kinds of signal are actually there.

Deal-breaker signals are the most urgent category. A prospect explicitly states that they will not buy your product unless a specific condition is met. This is not feedback; it is a negotiation constraint. If a $100k deal is blocked by a missing feature, the product team needs to know immediately so they can weigh the cost of building the feature against the value of the deal.

Competitive intelligence signals occur when a prospect compares your product to a competitor they are evaluating simultaneously. "Competitor X does this in two clicks, why does it take five clicks here?" These signals are invaluable for understanding how your product is positioned in the market and where your UX is falling behind the standard.

Friction signals happen during the demo. The sales rep shows a feature, and the prospect asks a clarifying question because the workflow is unintuitive. "Wait, so I have to go back to the main menu to do that?" If ten prospects ask the same question during demos, you do not need more training material; you need to fix the UX.

Expansion signals come from existing customers during renewal or upsell conversations. "We'd love to upgrade to the Enterprise tier, but we need custom reporting first." These signals are critical for prioritizing the features that drive Net Revenue Retention (NRR).

A System That Actually Works

The teams that successfully turn Gong calls into product decisions share a common architecture. It has five components.

Unified signal collection. The first step is to stop analyzing sales calls in isolation. A prospect asking for a Salesforce integration on a Gong call means something different when it is corroborated by 50 Zendesk tickets from existing customers asking for the same thing. The product insight lives in the convergence, not in any single channel. Your sales calls need to sit in the same system as your support tickets, your Slack conversations, and your NPS responses.

Taxonomy that emerges from the conversation. You cannot rely on sales reps to manually tag calls with the correct feature requests. The system needs to read the call transcripts, build themes from the actual language prospects use, and group identical problems together automatically.

Deal-breaker detection. The system must be able to distinguish between "it would be nice if you had X" and "we cannot buy without X." Deal-breakers need to be flagged and routed to the product team immediately, bypassing the normal quarterly review cycle.

Pipeline revenue context. Every extracted theme must be tied back to the CRM data. The system needs to calculate the total pipeline ARR attached to a specific feature request, allowing the product team to prioritize based on business impact, not just the number of mentions.

Living decision rationale. When a PM decides to build a feature based on sales feedback, the evidence—the specific Gong calls, the pipeline revenue at risk, the exact quotes from the prospects—must be preserved in a living document. When the feature ships six months later, the team needs to know exactly which prospects to follow up with.

Where Atisbo Fits

Atisbo connects to Gong and treats your sales calls as one signal among many—alongside Zendesk tickets, Slack conversations, Notion documents, Amplitude events, GitHub issues, and Granola meeting notes. It reads the call transcripts, builds themes from the actual language prospects use, attaches pipeline revenue context to each theme, and continuously surfaces what is most urgent and most ready for a decision.

The output is not a call summary. It is a decision: what to build next, which deals it unblocks, what evidence from across all your sources supports the decision, and which requests are deal-breakers that cannot be deprioritized without losing specific revenue.

Atisbo works with Gong through a connection that reads your existing call data. There is no new tagging workflow for your sales team, no requirement for PMs to watch hours of call recordings, and no more valuable feedback dying in a Slack channel.

"Atisbo works with Gong and connects to your existing sources. No native one-click integration is promised—contact the team at atisbo.dev to confirm the current connection options for your stack."

The Five Questions Your Sales Data Should Answer

If your current setup cannot answer these five questions in under five minutes, you are leaving product intelligence on the table.

If your product team is not reviewing these questions regularly, your sales calls are just an archive, not a product intelligence system.

The Compounding Return

The teams that build this system do not just close more deals. They build a compounding advantage. Every sales call that is analyzed and connected to a product decision makes the next decision faster and more confident. The context behind why a feature was built is preserved in a living document, creating a permanent, searchable record of market demand.

The teams that do not build this system continue to operate in the dark. Product managers continue to guess what the market wants, sales reps continue to feel ignored when they pass along feedback, and prospects continue to buy from competitors who listened.

Your sales team is already conducting the highest-volume product research in your company. The question is whether you have a system to use it.

See how Atisbo connects your Gong calls to product decisions →