How product managers work with sales, and what a lost deal is really telling you

Product managers work with sales by turning deal feedback into evidence about buyers, triaging requests against rules both teams agreed in advance, and equipping sales to sell what already exists. The hard part is reading the feedback correctly. Matt Dixon and Ted McKenna, writing on The JOLT Effect, report that "a staggering 40% to 60% of deals are lost to customer indecision", which means many of the losses that reach a PM as "we were missing feature X" were never really about feature X.

Why is "we lost because of a missing feature" so often the wrong read?

A rep who loses a deal needs an explanation, and a missing feature is the explanation nobody can argue with. The buyer often offers it too, because "you don't have Outlook sync" is easier to say than "we weren't convinced changing was worth the risk".

The JOLT research gives the second reason more weight than most teams do. Of the deals lost to no decision, Dixon and McKenna report that 44% were lost to a preference for the status quo and 56% to indecision stemming from risk or fear of failure. Their follow-up piece, What is Customer Indecision?, says the figures come from a study of 2.5 million sales calls.

Those numbers describe sales conversations in general, not your market, and they come from researchers who sell a method for fixing indecision. What they still show is that a PM who treats every loss report as a feature gap is reading from the wrong model most of the time.

What does buyer psychology tell a PM about deal feedback?

Four ideas from how B2B buying works change how you read a loss report. Take a scheduling tool for dental clinics, where a rep reports a lost deal "because we don't have two-way Outlook sync".

Pain comes first. A buyer who cannot name a painful problem in their current setup does not buy, however good the demo. Ask whether the clinic ever described what double bookings or missed reminders cost them.

Buyers pay for a distance, not a product. They buy the distance between where they are and where they could be. If nobody quantified that distance, say two hours of front-desk rework a day, the price was compared against nothing.

Switching feels risky, even when it is right. Changing scheduling tools means migrating patient data, retraining staff and possibly a messy first month. Buyers hesitate over exactly those worries, even when the business case is sound.

Confidence decides, numbers justify. The practice manager needs to feel safe backing the change and needs a return figure to defend it to the owner. Missing either half stalls the deal.

Read through that lens, the Outlook sync request might be real. It might also be the one concrete objection the buyer could name for a change they were never convinced to make.

How do you find the problem behind a sales request?

Ask why until you reach a business consequence. For the dental clinic: why do you need Outlook sync? Dentists keep personal calendars in Outlook. Why does that matter? They get double-booked for school runs. What does that cost? Two cancelled appointments a week and an angry patient each time.

Now you have a problem (dentist availability is invisible to the booking system) with a cost attached, and several possible answers: full sync, a one-way availability import, blocked-time templates, or better onboarding. The feature request was one solution. The problem is what belongs in your discovery notes.

Dixon and McKenna make a related point about sellers: "what most sellers do when they encounter indecision often makes the situation worse", because they keep arguing against the status quo. The product version of that mistake is shipping the requested feature and watching the next deal stall for the same unspoken reason.

What rules should a PM and sales agree for request triage?

Rules agreed in advance beat judgment calls made under deal pressure. A workable set for most B2B teams:

Rule	What it means in practice
Every request comes with a problem	Log the customer's problem and its cost, not just the feature name
Tag the deal context	Deal stage, size and whether the request blocked the decision or was a wish
Count patterns, not volume	Review requests across many deals on a fixed cadence; one loud deal is one data point
Sort objections into three buckets	A real product gap, an enablement gap (the product does it, sales did not show it), or an expectation to reset
Name the exception path	Who can approve a one-off commitment for a strategic deal, and what it costs the roadmap
Close the loop	Tell the rep what happened to each request, including no

The third bucket in the objection rule is where most of the value sits. Some "missing features" turn out to exist, or to have a workaround sales never learned. For how to decline the ones that do not make it without burning the relationship, see how to say no to stakeholders; for weighing the ones that do, how to prioritize features.

What should product give sales in return?

A sales team that can sell what exists asks for fewer custom features. Your side of the relationship is enablement: clear positioning, the use cases where you win, answers to the objections that come up every week, and proof points buyers trust, such as a customer's before-and-after numbers.

Build that material around the buyer's gap, not your feature list. "Front desks at clinics like yours stop spending mornings fixing double bookings" sells the future state; "two-way calendar integration with conflict detection" describes a feature. If you want to produce and refresh that material faster, AI for sales enablement covers how to draft battlecards and objection guides with a model.

Is this just product managers doing sales' job?

The strongest objection is that a PM coaching reps on buyer psychology is overstepping, and that sometimes the feature really is missing. Both are fair. Some losses are product gaps, and the triage table exists precisely so real gaps get counted and prioritised instead of dismissed.

The point is not to second-guess every rep. It is to stop the roadmap from being written one lost deal at a time, and to give sales better evidence and better material in return. PMs who came from sales often do this well, because they have felt both sides; moving from sales to product management covers that transition.

How does Builders Camp teach product and sales collaboration?

Sales for Product Managers is a 1 week Builders Camp bootcamp directed by Andre Albuquerque, in the Growth Specialist Track. Its published topics include how sales actually works (pipeline, qualification and the realities that shape sales behaviour), translating deal feedback into product insights, request triage and roadmap protection, positioning and proof, objection handling that maps objections to product gaps, enablement needs or expectation-setting, and feedback loops with a steady operating cadence. Its practical challenge asks you to diagnose a deal that went cold after a demo and write a re-engagement that addresses the real blocker; the cold deal diagnosis exercise describes that brief. See the Sales for Product Managers bootcamp for dates and format.