“We can add that” is a cheap promise

I have been in enough product meetings to know that “we can add that” gets treated as if somebody solved something.

Usually we have solved one part. A customer asked, the team can picture the build, and someone has already started estimating it in their head. That is how a request goes from conversation to roadmap before anyone has to say what the customer can count on.

That first part is real. Knowing the thing can be built matters. It is also the easiest part to confuse with a customer promise.

Say a system can draft a customer update and send it in seconds. Useful.

But the customer isn't relying on the verb “draft.” They're relying on the update being right, arriving when it matters, and being enough for whatever they need to do next. And eventually every shiny verb has a bad day.

An update is wrong or late, or the situation needs judgment the system doesn't have. Now somebody has to know who notices, who steps in, and what the customer was actually promised.

This is where I try to make myself keep talking after “yes, we can build it.” What will the customer be able to rely on when it works? When the normal path fails, what will we do? And what are we explicitly not promising? That last question is usually the useful one. It may show that a person has to stay in the loop, the scope needs to shrink, or the capability is interesting but not ready to become an offer.

There is an obvious limit here. A small, self-contained convenience does not need an emergency response plan because it occasionally mis-sorts a low-stakes list. The ceremony should match the consequence.

But if someone will use the thing to spend money, meet a deadline, or make a decision, the feature is only the visible part of the work. “We can add that” is permission to start the harder conversation, not a promise the customer should rely on yet.