YouTube was a dating site, and Slack was supposed to be a game. Can banks change their business models the way startups do?
We have been developing mobile banking applications since 2008, and our experience shows that even a new loan offer or basic travel insurance functionality usually requires 4 – 6 months to implement.
In addition, the annual cost of developing a mobile banking solution, depending on the functional range, is approx. USD 250 000 – 1 250 000.
Table of contents
- Testing ideas is difficult. Why?
- The game that became an unicorn
- The way of the startup
- Is pivot possible in banking?
- New business models in banking?
- Pivot blockers – what is the reason of such a long development time? Why are the costs so high?
- 3 ways to speed up ideas verification in digital banking
- Final thoughts
Testing ideas is difficult. Why?
Given the huge costs and long production time, it is not surprising that banks would like every functionality in digital channels to become successful.
This creates an atmosphere of pressure, with a very little space for mistakes and learning from them.
Why does application development take so long? Why are the costs so high? How does it all affect digital banking?
Before answering these questions, let’s take a look at how this situation was tackled by considerably smaller organizations.
The game that became an unicorn
When developing a software (and mobile banking is no exception here), releasing a prototype to the market as soon as possible and testing it on users is the key. It allows the application’s creators to quickly check whether the product has potential.
This model has been used for many years by Stewart Butterfield, the mind behind Slack.
“His company, Tiny Speck, began developing a game called Glitch. After a brief launch in 2011, Glitch was returned to beta and by 2012, Butterfield declared the concept wasn’t viable. However, the internal communications platform Tiny Speck had created to communicate between US and Canadian offices turned out to be the real opportunity”.
The platform was launched in 2014 under the name Slack and soon joined the elite group of unicorns ($1b+ valuation). Since then, its value increased sevenfold.
In addition, Butterfield is also the creator of Flickr. This photo-sharing site also evolved from a computer game.
Other examples worth mentioning include Twitter and YouTube:
“Twitter launched in 2005 as Odeo, a platform for discovering and subscribing to podcasts. But thanks to iTunes, Apple loomed large in the podcast space, so Odeo decided to pivot.”
“YouTube started as a dating site that allowed singles to upload videos of themselves talking about what they wanted in a partner.”
The way of the startup
What is the lesson here? These tech companies succeeded because they were not afraid of changing the direction of the ship when they saw the iceberg in front of them. And it was through experiment that they were able to see what DOESN’T work and what DOES in their front-end or back-end. When they found out, they pivoted.
Can a bank function similarly when developing its digital banking?
Is pivot possible in banking?
Banks are not startups and can’t pivot within their core business model. They are also too large organizations to rebuild themselves from foundation to roof.
However, contrary to popular belief, banks pivot. How?
- For example, they change their target group, like DNB Bank Polska.
In 2019, this bank paid individual clients up to $250 for closing their accounts, because instead of individual clients, it wanted to focus solely on servicing SME and corporate.
- It is also worth to mention Solaris Bank, which was created in order to build other banks. This is not a pivot, but undoubtedly a new approach to bank management.
“As a licensed banking partner, Solaris Bank enables you to build a digital payment services on our payment infrastructure. You can focus on your core business while our Payment APIs handle the payment processing – always ensuring regulatory compliance”, says their website.
- Do you enjoy westerns? If so, you definitely know this cliché scene, where a stagecoach is transporting cash between banks. Why are there no such stagecoaches today? The decision to stop storing cash in banks was a pivot here.
Yesterday we operated in cash, today we operate in digital money.
But the fact is that pivots in the banking sector happen quite rarely. We can even say that pivots in banks happen once per century.
New business models in banking?
But banks can and do test new business models.
Examples of this approach are projects such as:
- Polish ING Bank, which wants to be like Klarna. The bank has bought shares in Czech fintech Twisto, which supports deferred internet payments system and enters the non-cash payments market with a bang.
- PKO BP—the bank’s leasing company is building a platform for selling, leasing, and renting cars. You can do everything remotely, with one click.
- Shopping services based on our idea of superwallets – a platform for mobile purchases that integrates with mobile banking. It is already offered by a number of the largest banks in Poland https://finanteq.com/superwallet/
It is no revelation to say that banks need innovations and have money to get them. Despite this, we can often hear that it is fintechs that set trends, and banks just follow. Why aren’t banks implementing new functionalities faster?
Pivot blockers – what is the reason of such a long development time? Why are the costs so high?
Product owners in banks have many great ideas on how to improve digital channels. Here are main reasons why creating single functionality in a bank takes so much time and money:
Lack of programmers on the market.
Creating and maintaining software is a very demanding process. Additionally, a large team means large costs, while a small team results in a large workload and lack of flexibility.
Inflexible infrastructure.
Coding is not the biggest problem – the lion’s share of the worktime is spent on adapting applications to the bank’s infrastructure.
80% bank representatives are convinced that digital will radically change banking (according to a study by Boston Consulting Group). At the same time, the same number of bankers admit that the bank’s infrastructure is an obstacle for those who want to quickly create new opportunities for interacting with customers.
Complex decision-making process
A complex structure doesn’t help if you want to move fast.
Complex development process.
As we’ve already mentioned, developing an app can cost up to $1,250 million a year. This is caused by the currently used software creation process. Included in this investment you’ll find the development, testing, design, images, animations, content, UX, management time etc.
On top of the investment over the course of the year companies budget some 10–20% to support and maintain the apps. This is before investing in promotion and marketing of your App, let alone making it available on other devices or in other countries.
The result is a growing backlog.
When the bank finally introduces this new, long-awaited, shiny feature implemented in its app, it may turn out that very few clients actually use it. It is also worth mentioning, that when a functionality is implemented with a delay, it may reflect poorly in the bank’s image, as in the case of Google Pay and Apple Pay, which are strongly demanded by users.
3 ways to speed up ideas verification in digital banking
Is it possible for banks to quickly test hypotheses in their applications and implement the new functions faster? Here are some ideas (In parentheses, we performed a subjective estimation of by how many percent each method speeds up hypothesis testing).
1. Test and Behaviour Driven Development (acceleration: medium)
Having various tests strategies, like TDD (Test Driven Development) or BDD (Behaviour Driven Development) is a great agile practice that helps achieve ‘failing fast’. So are the frequent releases to the end user, as they allow defects to be discovered quicker than if the product is shipped at the end of a long waterfall lifecycle.
Discovering UX issues instantly is also part of the fail-fast concept, as it steers the project to success during development, rather than creating a lot of software before giving it to the end user. Fail fast is a useful and important agile concept.
2. MODULAR BANKING (acceleration: high)
The Ubers and Facebooks of this world frequently introduce clever new features. How? Their systems’ architecture has interchangeable components that can react to market and institutional changes quickly.
If components are provided in the form of SDK’s, they can be easily embedded into any existing app. If they are highly customizable they are ready to blend into any mobile banking design. Examples of such components are FINANTEQ’s OCR for paying invoices, mobile token or Smartwatch Starter Kit.
3. NO-CODE (acceleration: high)
If the bank needs to create front-ends much faster and modify them as quickly as necessary, it should look for a no-code platform. The main advantage of these platforms is that most of the business functionalities can be configured by a person without programming skills.
And this can shorten the process that lasts for months even by several times.
How does no-code work? It is a visual approach to application development. No-code enables anyone to create applications for web and mobile (along with the logic), through a graphical user interface (GUI). In other words, creating a new functionality and including it in the app occurs during configuration, not during development.
The effect is that a functionality adjusted to the user’s needs can be created almost overnight. Researching and verification of market hypotheses on selected groups of customers becomes easy.
By 2024, low-code application development will be responsible for more than 65% of application development activity (according ro Gartner). This is why FINANTEQ is using its own no-code tool to organize internal processes, but also offers dedicated solution for banks.
Final thoughts
What are two lessons that banks can learn from pivoting startups?
- If we see that given functionality does not make sense (e.g. it is used by a small number of users or people complain about it) we need to be able to close it quickly and focus on the new project.
- Before closing the entire project, we should analyse what works well and utilize that part.
Focus checks and tests are necessary, but the end client is the final verification threshold. The only true path is: fail fast, learn faster.