The operator at the Ghanaian bank pressed "send" on the AI workflow and watched an hour of manual reconciliation collapse into ninety seconds. She turned to me, smiled, and said "this is magic." Her director, two floors up, had already told me the team couldn't authorize the next payment milestone. The demo excited the person who used it daily. The budget belonged to someone who had never opened the tool.
This gap, between the user who loves your product and the person who pays for it, is where early-stage AI startups quietly die. The fix is not better demos. It is deciding, before your next build, whose problem you are actually solving.
The user is not the buyer
The operator's enthusiasm was real. She saved time, avoided errors, and told her colleagues. That enthusiasm produced nothing. Her director cared about a different question: what this automation would mean for headcount, for the department's cost center, for his own reporting line to Accra.
Every founder building AI tools for operators inside larger organizations faces this split. The person who feels the pain is rarely the person who controls the spend. When you optimize purely for the user's delight, you build something people love and no one funds. When you optimize purely for the buyer, you build something that gets purchased and then ignored.
The distribution of these two groups tells you what to build next. If operators keep asking for more features but the budget owner is silent, you have a sales problem disguised as a product problem.
Who solved whose problem
The same dynamic played out in a different arena in the 1970s: Singer's sewing machine division bet on the electronic home sewing machine, a machine that made embroidery and complex stitches easy for anyone, and marketed it to the hobbyist who loved the craft. The machines were genuinely better. What Singer missed was that the people with the money to buy a premium home machine were buying it either as a gift or as a signal, and the people who actually sewed daily, the professionals and the serious hobbyists, had already moved to industrial machines. The product delighted the enthusiast but the budget owner had a different job in mind for that money. Singer's consumer electronics push collapsed, and by the 1980s the company that had defined home sewing had sold off that part of the business. The lesson, documented across the business press of that era: loving your user is not the same as understanding your buyer.
Find the person whose budget moves
Before you write another line of code, ask who feels the pain in their P&L, not who feels it in their daily workflow. The operator felt the pain of a tedious task. Her director felt the pain of a line item he could not justify.
Walk up the chain until you find the person who can say yes on their own authority. That person's problem is your roadmap. If the operator's director cannot approve the spend, find the person above him who can, and learn what they measure. Build the demo to answer their question: what does this save me, not what does this save my team.
The reverse is also true. If you are selling to a budget owner and the end users hate your tool, the renewal dies quietly. You need both: a buyer who sees the economic case and a user who does not quietly sabotage it.
Shipped the wrong thing, and what it cost
The bank's operator loved the reconciliation tool. I had built it to solve her problem, because she was the one who talked to me, because she was the one who said the old process was killing her week. I nearly shipped the next version focused on her other daily frustrations: more automation, more time saved on tasks she hated.
The director stopped me. Not because he was unkind. Because he had a spreadsheet with the actual cost of the team, and my tool was saving one person ninety minutes a day, which he did not need, while the real cost, the risk of manual error across thousands of transactions, remained unaddressed. That was his problem. I had built for the person in front of me instead of the person whose budget would pay me.
If the founder had built for the person with the budget, the first version would have looked different. The demo would have shown risk reduction, not speed. The next build now faces the same choice again, for the second contract, the one that decides which of two directions the product takes. It always comes back to this: the demo delights the user, the check comes from someone else. Build the thing that makes the check writer say yes, and keep the user happy enough that they never tell the check writer to stop.
Comments
No comments yet.