A product vision worth returning to

The situation

A Canadian logistics company engaged our team to build a product initially valued at about $250k. During onboarding, I asked where the product fitted in the company’s wider plans and what the founder hoped it could become. As development progressed, new requests kept coming. The projected cost moved about 30% above the original proposal. The customer was frustrated—not only by the amount, but by the feeling that we should have helped them see where the work was heading.

The decision I made

I did not begin the escalation by pointing to the contract. I returned to that onboarding conversation and compared the original vision with the product we were now being asked to build. Using the account tracker, I reconstructed the sequence of scope decisions and their financial impact. I also acknowledged something uncomfortable: while many of the changes came from the customer’s evolving requirements, our team could have questioned some of them earlier. Accepting a request is not always the same as helping a customer protect their priorities.

What changed

We walked through the changes together: which ones served the product’s current purpose, which ones represented a different ambition, and why the original estimate could no longer describe the expanded product. The customer accepted the explanation and approved the outstanding change requests. The engagement ultimately generated more than $500k rather than the original approximately $250k. The delivery team became more willing to challenge requests that did not support the customer’s stated vision instead of automatically accepting them.

What stayed with me

An escalation is rarely solved by a better defence of the invoice. It is solved when the customer can see how the product, the decisions and the investment changed—and can recognise their own goal in what comes next.

The Human Side of Customer Escalations