Give the Customer a Date Instead of a Yes.

Watch the video version:

The customer asks for something in the meeting, and everyone in the room wants a yes. Giving it takes five seconds, and it feels like the relationship just grew stronger. Your team pays for it for months: a date nobody evaluated, a feature that turns into shelfware, and eventually estimates padded so far you stop trusting them. Most leaders give that yes anyway, because "let me take that back" feels like admitting you cannot decide.

Sometimes nobody even says yes. A capability gets described without its limits, and the limits never make it into every conversation. I am living that version right now. A customer wants to group and price by NPI, the National Provider Identifier, instead of by CCN, the CMS Certification Number that facility pricing runs on. Not every NPI can map to a CCN; an individual doctor's has nothing to map to. A support ticket came in, my team hand-checked the data, and much of it belonged to individual providers. I cannot be certain that caveat entered every conversation with this customer. As an aside, I find it funny that CMS pushes NPI and releases pricing factors only on CCN.

It frustrated me, because it is a gap I have been pushing to fill: a role that sits at the intersection of engineering, support, business, and sales, so customers get accurate information and their needs are tracked and evaluated properly.

A yes in the room is made without the people who own the capacity, the data, or the edge cases. It is a commitment nobody evaluated. The team inherits a date it did not set, or a capability described without its limits, and the first time anyone sees the gap is often a support ticket.

The customer learns that what they heard in the room is not quite what they get, so they start verifying everything. The bigger cost lands on the team, where what I call the Trust Flywheel turns the wrong way: trust compounds when a leader's commitments hold, and when they do not, the team learns caution. They learn that commitments get made over their heads, so they pad their estimates. That is the main thing I see, though all of the cautious behaviors show up: waiting for written confirmation before starting, routing questions upward, flagging fewer caveats. The yes that was supposed to build trust spends it.

Better to take it back and give the customer a date instead of a yes. Phrase it as care: we will involve our UX team to make sure it will meet your needs and perform well, and you will hear from us by a specific day. Then evaluate it with the people who own the work, against the question from Wednesday's piece: will it be useful to our user base? Then follow up on the date you named, limits included. Someone has to own that loop between sales, support, engineering, and the business. A loop nobody owns drops the caveat at the first handoff.

Take the last three things your company committed to a customer in a meeting. For each one, ask four questions. Was someone in the room who owned the capacity to deliver it? Did the customer leave with a follow-up date? Did the limits travel with the commitment? Who owned the follow-up? Count the commitments with even one no. Then look at your team's last few estimates. If they have started padding, that count is why.

Quiet Confidence goes deeper into the restraint this takes: staying clear when everyone in the room wants an answer now: https://TheQuietConfidenceBook.com

You are being graded on a second scorecard no dashboard shows, and it measures what you held back.