When people repeatedly copy an AI answer into WhatsApp, the product’s real job may be helping them make a decision with someone else. The overlooked copy action can reveal that the useful output is not the answer on screen, but the conversation it makes possible.
Consider Ama, an invented composite of a founder building a procurement assistant in Accra. At 6:18 p.m., she was sitting in the back of a parked car outside Osu, holding her phone above a laptop with a weak battery, while a pilot customer waited for a recommendation he could forward to his business partner.
The assistant had compared three supplier quotes and produced a clear explanation. Ama watched the session replay later that evening. The customer read the answer, selected most of it, copied it, opened WhatsApp and sent it.
Then he waited.
His partner had challenged the recommendation twice already. If they could not agree that night, the order would go elsewhere and Ama’s pilot might end without a second transaction. Her product had completed its stated task, yet the decision was still unresolved somewhere she could not see.
The journey continued after the answer
Ama had designed the product around a familiar sequence: enter the quotes, review the comparison, choose a supplier. The interface treated the generated answer as the end.
The customer treated it as a draft message.
When Ama checked more session recordings, she noticed the same exit. People copied a paragraph, switched to WhatsApp and disappeared. A few returned later to edit an input or generate another version. Others never came back.
Her first explanation was that the interface needed a better result screen. Maybe the comparison should be shorter. Maybe the recommendation needed a clearer confidence score. Those changes might have helped, but they did not explain why the customer kept taking the answer elsewhere.
The product was serving a decision involving two or three people, while the interface assumed one person could finish the work alone.
That distinction matters. A founder can spend weeks improving an answer that already works, while the actual friction sits between the person reading it and the person whose agreement they need.
The missing feature was hiding in plain sight
A copy event looks trivial in analytics. It can mean the answer was useful. It can also mean the user had to rebuild the final step by hand.
Ama wrote down what happened after each copied answer. The customer shortened the text, removed technical wording, added the supplier names and sent it to someone with authority to approve the purchase. Sometimes that person asked for the reasoning. Sometimes they wanted only the recommendation and the risk.
The AI had done the comparison. The customer still had to package the decision.
That led to a harder product question than “Should we add an export button?” An export button would make copying easier, but it could preserve the wrong assumption. Ama needed to decide whether she was building a private analysis tool or a product that helped a small group reach agreement.
The second version would require different choices. The output would need enough context to survive outside the product. It might need a concise recommendation, the trade-off behind it and a format that reads naturally in a chat. The team would also need to resist building a full collaboration system before proving that a shareable decision was valuable.
This is the same tension behind what happens when a demo impresses the user but misses the person paying. The person operating the product may be only one participant in the decision that creates value.
One small test changed the product question
With the pilot still at risk, Ama did not begin with accounts, permissions or a new messaging integration. She added a plain action beside the result: prepare a message.
It produced a shorter version with the recommendation, the main reason and the unresolved risk. The customer could edit the text before copying it into WhatsApp.
That evening, the pilot customer generated the message and sent it. His partner replied with one question about delivery risk. He returned to the product, checked the comparison and sent a revised note.
The order went forward.
That single outcome did not prove a market. It did reveal a job Ama had previously excluded from the product boundary. The customer was using AI to prepare a decision that another person could trust enough to discuss.
There was still uncertainty. Would people pay for this step? Would they use a direct share option, or keep copying because WhatsApp already contained the relationships and context? Would a polished message improve decisions, or merely make weak recommendations sound more certain?
Those questions deserved testing before a larger build. As the spreadsheet that revealed who really owns your roadmap shows, repeated customer behaviour can redirect a product long before a formal request reaches the backlog.
Watch what users carry out
If people leave your product with the same piece of output, inspect the handoff before adding more intelligence.
Look at what they copy, what they remove and what they add before sending it. Identify the recipient. Ask what that person needs to approve, challenge or act on the result. Then test the smallest version of that handoff.
For Ama, the important event was no longer “AI answer generated.” It became “decision prepared for another person.”
The next morning, she removed “better supplier answers” from the top of the planning document. In its place she wrote: “Help one person explain a purchasing decision to the person who can approve it.”
The export button could wait. The product had finally found the journey it needed to finish.
Comments
No comments yet.