DEVELOPING PRODUCTS FOR CUSTOMERS

From an operational and financial point of view, banks must:

1. Build around customer knowledge – focusing on the problem, issue or dream that needs addressing;
2. Have the discipline to map out every step of the development;
3. Create a documented workflow of each step of the delivery, processing, interaction, and controls;
4. Seek to design and code using parametrised tables and documenting the programming effort.
5. Seek to build open systems or off-shelf basic solutions;
6. Always involve areas such as Legal, Compliance and other relevant areas in the design process;
7. Seek existing solutions and compare the cost and flexibility of adapting them.

Build around Customer Knowledge

This will avoid unnecessary costs. Sometimes banks build solutions based on what their competitors have or the latest market fad. When it tries to sell or implement this, it can be a waste of time as the bank does not understand what drove such solution, product, or service creation, nor what is the bank differentiation. By building the solution around the customer base, or a specific segment, a bank will ensure that the required investment will go towards what is actually needed.

As an example, why build a massive inbound telephone capability or sales and service stores or branches, if the bank’s customer base interacts with them mainly through WhatsApp, or only 15 per cent of the bank’s base uses face-to-face interaction? By knowing how its customers interact with it, the bank can save valuable resources that will be needed elsewhere.

Discipline to Map every Step of Development

Building a product or a service starts by finding an insight, a market opportunity, or a regulatory requirement. Based on one or more of these, an idea is designed. Then the process starts with someone or a team of developers translating the idea into a product or service description and specification. The more detailed the description and specification are, the easier it is for product or service development.

This description and specification must be shared with the areas potentially involved in the project, for example Operations, IT, Legal, Compliance, Finance, Marketing, Channels and Customer Management. Within the description and specification, it is fundamental to describe what is known about the potential users or buyers of the solution. Such knowledge will be the main driver of future decisions. Whenever there are questions, challenges, or doubts about the next steps on the design or specification process, it is a very good habit is to talk to samples of future users or buyers.

Every step of the development must be documented and shared with every participant. And at the end of each step, the next one must be clearly defined with the responsible person appointed and with due dates agreed. This documentation must be completed at the end of the process, as in the future a product manager may need to understand why a line of action was taken, and/or explain to regulators aspects of the product. Robust documentation will also save time on needed process fixes and improvements.

Create a documented workflow of each step of the delivery, processing, interaction, and controls

Once it develops the product or service, the bank must document a clear workflow that describes every step of the delivery, management, and controls – highlighting decision points, potential process bottlenecks and the areas responsible for the delivery and the timing of each step and the systems involved.

A detailed workflow is fundamental for detecting issues affecting product delivery and enables prompt fixing of issues and analysis of planned performance against actual performance. It will also help the Product Manager to apply quick fixes without having to go repeatedly through all the development steps during the life of the product.

Important

Over the years, because of regulatory requirements, new insights, and issues with the day-to-day delivery of solutions, managers make quick fixes that create redundant decision points, adding useless steps that can cause new bottlenecks and service failures. If the bank is disciplined to use and update such workflows periodically, it will avoid all the above inefficiencies and save a lot of time and money.

Seek to design and programme always with parameter tables and documenting programming

We live in a volatile world. Prices, rates, taxes, and rules can change quickly. As a result, hard coding all aspects of a product or service that may change is not ideal. To avoid unnecessary program fixes and be more flexible, quicker, and cheaper a product developer working with a software programmer must always create parameter tables (a list of values that a user can selected, without hard coding) for variables like price, rates, terms and the number of instalments.

Another major issue is caused by systems not being properly documented. When the system is programmed the first time, it is normally properly documented, which will help future Product Managers to understand the logic behind it and how it works. However, as time goes by, and new fixes are made that are not properly documented, the systems become what is called a ‘black box’. Everybody knows what the system delivers, but how to change it is a mystery!

Even when a bank spends a significant amount of time and money to try to retro-engineer such systems, often the effort isn’t enough and they continue as ‘black boxes’ where only part of the system logic and design is understood. This can eventually force the bank to build a new system and turn the old system off, incurring an unnecessary cost. Even worse, sometimes – due to market changes or regulator requests to adjust the parameters of the system – banks can suffer losses and are forced to apply inefficient ‘patches’ that normally require massive post-delivery reconciliation.

Seek to build open systems or off-shelf basic solutions

Open systems can link to other systems or solutions that may improve performance or deliver some components without the need to build everything – and can be off-the-shelf software or built in-house using similar thinking and systems architecture.

Preferably, banks should buy off-the-shelf systems as the developer releases regular improvements, especially to comply with changing regulations. Because the supplier provides the same solution to many clients, the cost will be lower, and maintenance fees are normally cheaper than constantly updating an internal solution.

Always involve Legal, Compliance and any other relevant area in the design process

Banking is becoming more and more a regulated activity. Sometimes what banking players accept as common sense isn’t seen the same way by the regulator, forcing the bank to scrap and re-start previous work after a great deal of time and cost invested in a development. To avoid surprises in a solution development project, it is fundamental to involve (from the beginning) areas such as Legal, Compliance, Operations, and any other department that may help on any external requirement.

Seek existing solutions and compare the cost and flexibility of adapting or building

Until recently many technology professionals believed all banks should build their own proprietary systems to provide a competitive advantage. More recently, specialised technology solution providers, with deeper knowledge and more agile delivery, have supported the boom of fintechs or digital banks – and reduced IT as a competitive differentiator. It is advisable nowadays to first look for any existing solution in the market. To do that, a bank must have an open systems architecture and work with APIs.

What is an API? An Application Programming Interface (API) enables access to data in defined databases, services, or devices. So, the user makes a request, and the API does searches in the server of whoever is providing the access and returns the requested answer.

It avoids the need for a customised interface between two systems by following a pre-defined protocol.

We use many APIs without noticing them. For example, when using a search tool, it uses hyperlinks that drive our requests to specialised sites that then seamlessly provide us the information.

Why a bank should use APIs:

• It improves security, because all interactions are mapped and controlled, so that it is known who is interacting with the bank. The bank also decides which data will, or will not be available;
• It is faster and does not require a team of developers to link systems that are not compatible;
• It provides access to complementary or new solutions to an existing system without the need to self-develop software at a reasonable cost. This is becoming more important because of the proliferation of fintechs – and,
• There is no need for manual work to extract data from other sources, as it uses an automated process.