A flawless integration test proves that the software can complete a workflow. It does not prove that customers want to complete the workflow that way.
On Friday afternoon, the eSignature flow worked from beginning to end. A document entered the system, the signer received the request, every required field behaved correctly, and the completed agreement returned with its audit record intact. The founder closed his laptop believing the riskiest part of the product was behind him.
By Monday morning, that belief had lasted less than an hour.
The print button changed the interview
Consider Kojo, an illustrative composite of founders I have watched build workflow products. He runs a small SaaS company from Accra, drinks his coffee cold because product calls keep interrupting it, and has enough runway to make one serious product bet.
At 9:20 on Monday, he joined a customer interview expecting to confirm that the new signing flow was ready. The customer, Esi, managed agreements for a small services company. Kojo shared the prototype and asked her to show him how she would send a contract.
Esi downloaded the document.
Then she printed it.
Kojo stopped her. The product already supported electronic signatures, he explained. She could add the recipient, place the fields and send the document without leaving the browser.
“I know,” she said. “I need my director to mark it first.”
She pointed to the margin of the printed page. Her director wrote questions there, crossed out clauses and passed the document back. After those changes, Esi created a clean version and sent it for signature. The signature was the final step in a process built around review, authority and visible corrections.
Kojo’s product had made that final step faster. It had left the contested part untouched.
Two more interviews produced variations of the same behaviour. One person printed documents for an internal review. Another sent an attachment through an existing messaging thread because that was where the decision-maker replied. Neither person doubted that an electronic signature could work. Their hesitation came earlier: who could approve the wording, how changes were recorded, and whether sending the document meant the negotiation was already over.
By lunchtime, Kojo faced a real choice. He could keep building toward launch and hope customers adapted, or pause a release his small team had already promised. Continuing risked spending the rest of the quarter polishing a workflow people would route around. Pausing meant admitting that Friday’s success had answered the wrong question.
Technical readiness can hide product uncertainty
Integration work creates reassuring evidence. The API responds. The callback arrives. Errors appear in logs. A team can point to each completed test and say, truthfully, that the feature works.
Customer behaviour produces messier evidence.
A person prints a document because the paper copy carries social meaning inside the company. Someone forwards a file because the person with authority never enters the product. A manager asks for a handwritten note before approving a digital action. These behaviours can look inefficient from inside a product roadmap. From the customer’s side, they protect accountability.
That distinction matters when runway is limited. Technical uncertainty asks, “Can we make this work?” Product uncertainty asks, “What must become easier before someone changes how they work?”
The second question should shape the first.
I have made versions of Kojo’s mistake. Shipping gives a founder something concrete to measure, while an unresolved customer decision feels slippery. Code turns green. Interviews produce contradictions. The temptation is to trust the cleaner signal.
Clean evidence can still describe the wrong layer of the problem.
This is the same risk behind Kojo’s customer knowledge gap: a team can move quickly while remaining uncertain about the decision that matters most.
Test the moment before the feature
Kojo returned to Esi’s workflow with a different interview prompt. He stopped asking whether she would use eSignature. He asked her to begin with the last agreement that had become difficult and walk forward from the first disagreement.
That changed what he could see.
The delay began when two people reviewed different versions. The risk appeared when nobody knew whether a comment had been resolved. The signature request came only after those problems had been settled elsewhere.
His next test required less code. He showed a rough review state that made comments, ownership and approval visible before a document was sent. Esi no longer reached for the printer immediately. She stayed on the screen long enough to ask who else could comment.
That question was the turn. It did not validate the whole product, but it revealed a workflow worth testing.
A useful product interview starts one decision earlier than the feature. Before testing an AI summary, inspect what the customer does with the source material. Before automating an approval, learn how authority is established. Before adding eSignature, watch how the document becomes ready to sign.
Ask for the last real example. Let the customer handle it as they normally would. When they leave your prototype, do not redirect them. The exit may contain the product decision.
Monday’s evidence belongs in the roadmap
Kojo delayed the release and narrowed the next build. The working integration stayed. It became infrastructure waiting for a better product sequence, rather than proof that the product was ready.
On Friday, his team had celebrated a completed signature. By the following week, the more valuable signal was a sheet of paper beside Esi’s keyboard, covered in the marks their product had never accounted for.
That paper did not mean digital signing had failed. It showed where the real work began.
Comments
No comments yet.