Sign up for our live DEG Talk Monday April 29th at 2:00pm EST.
This blog post is a follow up from the talk I gave at the AFT Spring Summit. In the talk I gave my thoughts on what we as digital banking vendors can learn from the original core banking entrepreneurs. I’ve had the pleasure of working for several great companies in my career, starting in core banking on the sales and marketing side and eventually transitioning to building digital banking products for both core and non-core providers. During this time, I experienced the evolution of the digital banking channel and believe that we as vendors made a fundamental mistake.
We focused too much on the technology, and not the customer.
At a high level, let’s start with the introduction of the internet to mainstream banking. As the internet gained prominence, consumers began to expect businesses to have an internet presence. For most financial institutions this was a marketing website, which was really nothing more than a digital representation of in-branch material that listed out account types and rates. The next step was to make the “risky” decision to launch internet banking, also known as making information currently available in my core banking system available to the consumer on the web so that they did not have to come to the branch, visit an ATM, or call the IVR to see their latest balance or transactions. The marketing website and the Internet banking application were, and still are for the most part, built for entirely different use cases.
One is for marketing and the other is for self-service and convenience.
At this point, digital banking created a fracture of the customer experience that is not present in the branch. In the branch you have a cohesive experience of sales, marketing, and service. From most community banks, this is in fact what they would refer to as their primary value proposition: “We differentiate on service.”
In branch/person service differentiation was created because of the geographic nature of banking. A financial institution was a physical fixture of a community. Customers came in and out of the location, and with it came a constant flow of customer interactions. When a customer came to the teller line or loan desk, the banking employee could see if there was concern or delight related to a transaction. Responding to concerns and continuing to build upon customer delight created the mentality of service differentiation.
In addition to the differentiation of in-person service, financial institutions were also subject matter experts on the financial products needed in their local communities. Business owners were coming to the branch with their problems, and bankers would work with them on how to structure a loan to meet their needs.
As digital banking began to gain steam, a new problem was created. The increased convenience of information and self-service features meant that the customer was no longer connected to the primary value proposition of the financial institution: the local branch. And as the pace of technology increased, the digital banking channel only continues to play catch up. Apple releases the iPhone, and years of effort are poured into replicating the desktop feature set in the mobile channel. Alexa becomes popular and now all of a sudden we expect consumers to walk around their homes asking for the balances, what bills are due, and scheduling transfers.
As an industry, we continue to prioritize convenience and technology advancements over remaining connected to the day to day needs of our end customers and their communities.
If that weren’t true, digital banking solutions would not be struggling with new account opening, integrated PFM features, or interactive sales and service capabilities.
So what do legacy core banking founders have to do with this conversation? We’ll get to that later.
Let’s now shift the conversation from the problem to a solution. For that I bring in the influence of my colleague, Chris Spiek.
During the early part of his career Chris ran a small software company. As the company grew, he realized that modern frameworks and software tools were making it easier to build software faster, but he didn’t feel like he was getting any better at understanding what should be built. He asked himself: “How do we set ourselves up to make sure that we’re building products that people will want to adopt?”
In an attempt to develop a framework that would answer that question, he started the Re-Wired Group with Bob Moesta and support from Clayton Christensen. Over the next decade he and Bob worked to formalize and popularize the product development framework known as Jobs-to-be-Done (JTBD).
The challenge we all face is that a product can never be perfect. We only have some much time, money, and resources to apply to any given problem. Great products are created when companies better understand their customers and apply themselves to the most important problems to solve. Said in another way, great products enable the most meaningful customer progress.
How do we understand our customer needs then? We build personas and customer journeys. The problem with building around common attributes is things get messy when the real world doesn’t fit into your well-constructed user personas hung on your product team’s office wall.
Let’s take two persona types: Sally the Soccer Mom and Betty the Business Owner.
Sally the Soccer Mom is:
Betty the Business Owner is:
The problem arises when your customer happens to be both a Soccer Mom and a Business Owner. How do you know what is most important for her if you are building a product roadmap to account for them as two distinctly different entities? For the customer, they are fluidly moving between roles and responsibilities each day. Building a product roadmap around rigid attributes may lead you to build solutions that aren’t fluid and have little crossover.
Another common tactic to avoid the problems with personas is to create surveys, and ask the customer what they want. This sounds good on the surface, but has a fundamental flaw. People lie. Not intentionally or maliciously, but they do lie when asked about purchasing decisions.
To illustrate, let’s examine a recent example. A friend of mine recently had their third child. After visiting them and meeting the new bundle of joy, the topic of cars came up. Adding a third child meant it was time to move beyond their current midsize SUV to something with a third row. The husband was enamored with a new luxury SUV that recently added a small third row as a feature. The wife was adamant that she wanted a large SUV with plenty of room in the trunk for the larger baby stroller. The minivan was not an option for either.
Fast forward several months and they come to our house to visit… and parked in front of our house is a shiny new minivan.
If you sent a survey to each of them prior to the purchasing decision, their responses would have not matched with the ultimate decision they made. They would not be telling the truth. The same is true if you survey them after the purchase. At that point in time they “know too much.” The responses you are gathering only reflect their satisfaction with the product and do not reflect the trade-offs they were willing during the decision process.
To unpack that more, something happened between the first thought of the husband (luxury SUV) and wife (large SUV) and the decision to purchase the minivan. What happened was that tradeoffs were introduced. The reality of pricing, third row seat size, and the large SUV not easily fitting into the garage were all introduced. Value was then created when the couple salesperson simultaneously slid both minivan doors open, and the two older kids easily jumped into the car and claimed a seat. Not to mention the built-in vacuum to easily suck up all the scattered Cheerios!
So if we can’t rely upon personas, customer surveys (pre-purchase or post-purchase), what do we do?
We study switching. The big difference in studying switching versus a survey is that in studying switching you don’t talk about features. You listen to the customer’s story and build a timeline of activity that documents a customer journey from first thought to purchase.
Listening to the customer story helps your team to better understand the tradeoffs customers are willing to make in order to adopt your product. This is important because it helps you to ultimately prioritize what is most important regardless of persona and removes idealized conditions.
The JTBD methodology will be covered in more detail in our upcoming webinar (link)
So what does all of this have to do with legacy core founders?
The founding stories of core processors that I have heard are all very similar. The original implementations involved the implementation of the core system onsite at the bank. So while business was being done throughout the day, the core product team was connected to the financial institution and their customers. As problems presented themselves the financial institution and the core team were having daily conversations about priorities and trade-offs.
Working closely with the customer helps to better understand the highest priorities and the trade-offs customers are willing to make. If we better understand what to really focus on, we will build products that customers love and earn the trust of our financial institution clients.
Join us on Monday April 29th to learn more about the JTBD process we use at Autobooks and answer your questions.