When the document was not the right tool

The situation

A US construction-tech customer was building a central platform for a business with many moving parts. We began with a conventional discovery process, but the documents were not helping the founder review what the team intended to build. Designs kept changing, and the cost and testing conversations became harder. The issue was not that the customer lacked a vision; our way of confirming it was not working for them.

The decision I made

I got on calls to understand the obstacle instead of insisting on another round of written sign-off. The customer found visual and spoken discussion easier than long specifications. I proposed a leaner design loop: put a rough concept on the screen early, invite direct corrections, record decisions in a format the customer could actually review, and have the team confirm what each change would mean before building it. Quick-and-imperfect visuals became a tool for discovering the right answer, not a promise that design changes had no cost.

What changed

The team had a more usable way to capture and verify requirements, while the customer could point to what did and did not reflect the business. The engagement still had serious discovery and testing challenges; this approach did not erase them. The customer nevertheless stayed with the product, signed a second phase and support, and later publicly recommended my advocacy and the team’s partnership.

What stayed with me

Accessibility is not a decorative feature added at the end of a product. It begins with how we invite someone into the decision. If the customer cannot challenge the plan in the format we give them, it is not yet a shared plan.

The best requirement is one a customer can challenge