Enabling Customer-Centric Finance
Companies that move from product-first to problem-first solutioning are going to be the next big winners.
People don’t wake up excited about a payment product. They wake up excited to get paid. It’s why solving real problems trumps flashy tech demos. It’s also why the people and businesses who build customer-centric solutions win in the long-run.
Most people aren’t payments people. Most people are not like my average reader — a fintech geek who reads Payments Culture, Fintech Wrap Up, and Batch Processing. Most people don’t care about infrastructure — they care about outcomes.
Jobs to Be Done and Where to Find Them
Clayton Christensen introduced the world to the jobs to be done framework (JTBD) as a way to understand why a customer makes a buying decision. In JTBD, when a customer buys a product or service, they are “hiring” that product/person/software to get a “job” done. When we buy a cheeseburger, we “hire” the burger to do the “job” of satisfying our hunger.
This way of thinking is what drives innovation at companies like dailypay and Greenlight. dailypay’s customers — hourly workers — needed access to their earned wages. They went out and built a platform using real-time payments that could fill that job opening. Greenlight saw a need from parents: how to teach good finance habits to their kids. The solution Greenlight built fulfilled the job of the parents — a wonderful education platform — and the kids — interactions that feel like games instead of school.
How do you find the job your customer needs done? You talk to them. Ideally, you are them. Then you build a solution compelling that customers can't rationally justify staying with their current process.
Sometimes, a screwdriver is as good as a drill
The “killer use case” for novel payments technology is always everything that’s wrong about existing tech. “ACH will end checks because it’s faster and cheaper.” “RTP will kill ACH because it’s 24/7 instant.” “TradFi is ______, Bitcoin fixes this”. The problem is that most jobs don’t need the latest and greatest, they just need to work. Customers care about the destination, not the journey.
When you change the battery in a remote or tighten a loose door knob, you grab a screwdriver. You could grab a drill — it’ll tighten the screw just as well — but that’s overkill for the job at hand. Similarly, we could send every paycheck in the U.S. by wire instead of ACH. We don’t because the job to be done isn’t about speed, it’s about ease of use and simplicity.
The Trap of Tech-Led Thinking
The Field of Dreams Fallacy is the belief that simply building superior products will result in customers flocking to you. However, most people are satisficers. Per Simon Herbert, we all aim to make “good enough decisions with reasonable costs of computation.”
Many millions of VC and R&D dollars have been burned building genuinely great technology only for it to never achieve product market fit. Much of this comes down to what Dan Hock calls the “Generalist Disease”. Rather than getting deep into a field or industry, many of us try to optimize for optionality. Without sufficient depth of understanding of customer needs, people and businesses shoot for technological superiority.
Technological superiority is something that can be measured while the degree of customer pains address cannot. Financial projections and forecasts rarely take the latter into account — you don’t need depth to model theoretical cost savings or revenue enablement. Successful founders, leaders, sales teams, and product managers spend the incredible amount of time needed to understand, define, and address customer needs.
In the Payments world, you’ve got a unique challenge: you have two customers with JTBD. A payments company must solve for pain points for both payers and payees. When done well, you see the phenomenal growth of UPI in India. However, if managed with less care, you end up like The Clearing House’s RTP network.
Better Tech Doesn’t Guarantee a Better Selller
Launched in 2017, RTP was supposed to revolutionize payments in the U.S. The system had 24/7 availability, was cheaper than wires, and ran on the latest payment standard — ISO 20022. What it didn’t have was a set of accessible use cases where it was irrational to choose any other option.
Their website lists 9 different use cases for RTP — almost all of which are satisficed by existing methods. Take auto sales and lending: funding can be managed via check, wire or even ACH. While dealerships live and die by cash conversion cycles, car buyers generally don’t care whether the payment takes 3 days or 3 seconds to clear. Unless they cannot rationally justify it, buyers are going to default to what they know vs. the new fancy tech.
In recent years, however, RTP has found traction in specific niches — most notably in bill pay and insurance payouts. But its slow adoption highlights a key insight: People don’t change solutions just because it’s better — they switched when the pain of staying is worse than the pain of change.
How to Build for Customers Rather Than Features
When building, the common questions and most of the documentation are around features: how it works, what systems it runs, and uptime. This is great for building an implementation guide or writing a legal contract, but doesn’t sell the product by itself. The stats and specs must be framed in terms of the customer’s job to be done.
The job to be done must be defined by — more often extracted from — the customer. This process takes time and requires overcoming our inclination for generalizing. Once defined, developing and positioning a solution requires that we recognize most people are looking for good enough. They don’t want to optimize — they want to statifice, to get the job done.
Adding all of the latest and greatest tech, like bolting on an AI chatbot or a blockchain, is a great way to raise money. It’s typically a great way to burn that same money. Sometimes a better version of excel is really all a customer needs to get the job done. That additional tech, if it fits your customers needs, will make great additional features and add-ons — so always remember to lather with Herbert’s Satisficing and shave with Occam’s Razor.
With the JTBD framework and satisficing concepts, builders must address critical questions before continuing:
Is the solution an incremental improvement or does it make switching inevitable?
Is the solution over-engineered when a “good-enough” solution would do?
(If already in market) If the product disappeared tomorrow, how soon could customers replace it?
At the end of the day, payments and finance aren’t about the rails, the tech, or even the product. They’re about solving real problems for real people. The best builders understand this, while the rest burn cash building for customers that will never come.