Product Management for B2B Financial Software

Financial software is a product and much of traditional product management applies but there are some key differences. In this article I am going to describe the overall product management process for B2B financial software and along the way I will identify areas where there is divergence from non-financial software product management.

Internal projects within financial institutions involve a very similar product management approach but I am going to focus on B2B for this article.

Broadly speaking there are 11 steps in managing financial software products:

1. Work with stakeholders to identify new ideas and features.
2. Know and monitor the competition.
3. Develop epics/user stories and wireframes to validate product features with stakeholders.
4. Take validated wireframes and make high fidelity mockups.
5. Create the product road map.
6. Create, refine and prioritize user stories for the product backlog.
7. Start development.
8. Review and lessons learned.
9. Release as frequently as possible to validate product features and quality.
10. Engage with the customers including surveys and face-to-face interviews.
11. Develop a range of KPIs to monitor and improve the product.

This 11 step process is applicable for new builds as well as for new versions. This basic approach holds for all product management, however there are some significant differences when talking about financial software for business customers.

Case Study

For the purposes of this article, I will using the example of a Loan Management System which will be used by a loan servicer to manage portfolios of mortgages on behalf of investors.

I will assume that there are 1000 loans of an average size of EUR250,000. I will further assume that there is only 1 investor and that their requirement is for quarterly reporting on the performance of their portfolio.

Work with stakeholders to identify new ideas and features

The biggest challenge for most financial software is that often there is a regulatory component that needs to be taken into account. For example, compliance and KYC, reporting requirements, privacy laws, etc. What this means is that the process of ideation and designing of workflows needs to be done in the context of what can be done as well as what must be done.

One example of this is that GDPR limits the use and storage of personal data. There are many requirements and the penalties are high. This is a non-functional requirement but it can have a massive impact on how to design the system. Personal data has to be captured for KYC and it will need to be stored somewhere, however, when displaying reports to investors, personal data must be anonymised or simply not displayed at all. Even if the investor wants to see personal data, the software may not facilitate this.

In terms of our case study, that would mean that the loan servicer must be able to see individual names and addresses but the investor must not be able to. This adds a level of complexity to the product which would not be present in most non-financial systems. Clearly there are other areas where GDPR is relevant, for example Healthcare, but the point here is that an investor in this case will buy a portfolio of assets without being allowed to know certain details of what is in it. While most investors would not be interested in the name of the person who took out a mortgage, they would like to know details about the property itself and the address. This is a relatively trivial problem, but thought does need to be given to what level of detail is acceptable — street, city district, region, etc. — and agreed with the investor while staying within the bounds of the law.

Know and monitor the competition

It is vital to know who the competition is when managing any product. The challenge is that when talking about big ticket and often customized items, it is hard to define who the competition actually is. Also, many times there are service providers who will do the work for you on their own system. This can be a viable alternative.

Specifically in the case of Loan Servicing for portfolios of mortgages, depending on the jurisdictions there are hundreds or even thousands of third-party providers of such services. As a bank/financial institution or service provider, a valid option can be not to build or buy software but rather use one of those services. As a Product Manager of B2B software, such Indirect Competitors may be fierce. One tool which can be effective is to look at the Total Cost of Ownership (TCO). If the TCO of your product is greater than the overall cost to use a third-party provider, it will be a hard sell. Not impossible, but it makes your job much harder. In this case, as a product manager, your focus here will need to be looking at non-functional considerations such as compliance, speed, availability and security.

However, money is not everything and many companies are willing to pay more for a better solution but you need to be able to explain to them why it is a better product and where they are getting (better) value for money. Even as a product manager, you will often be pulled into sales discussions with clients especially if there is any customization required or a future feature wish list.

Develop epics/user stories and wireframes to validate product features with stakeholders

This part of the process is the same as for other kinds of software, however often the User Story will involve making some kind of calculation. For example, an investor report might need to display the Loan-To-Value of a particular mortgage. This needs to be calculated in a particular way. That calculation needs to be defined. In this simple example it is the outstanding amount of the loan divided by the valuation of the house that the mortgage financed. It does not stop there, however, as there can be different definitions of which valuation to use (e.g. market value, sales price, desk valuation, etc.). The outstanding amount of the loan itself can be defined in at least two different ways:

1. Any amounts due are assumed to be paid.
2. If a payment was say 10 days late and the LTV was calculated 5 days after the payment was due, then the outstanding loan balance would be the same as during the previous period.

The point here is that precision is very important and incorrect calculations may lead to serious financial loss due to making decisions on incorrect information.

Take validated wireframes and make high fidelity mockups

While of course there needs to be a clean front-end, for most financial software the focus is on function over form. Sparse and simple is often preferred over fancy graphics and slick presentation. Some design is required for sure, but most financial professionals will focus on the calculations and the output. The best approach is to have a grid displaying data with a summary table showing aggregated data. In addition, filters are extremely important to allow on-the-fly analysis. Usually there will be some kind of dashboard with some graphs and tables here and there. However, probably the most critical feature that you will usually see is the ability to export any calculations, raw data and reports. Many finance professionals will use the software to run the month or quarter end process, but then they want to export the output and run their own calculations and pivot tables to feed into a different reporting system or to add to a PowerPoint briefing. Almost always users will want to be able to customize fields and dropdowns.

When implementing financial software, clients will usually want to run an excel model next to the system to make sure that everything is correct and accurate. In addition, very often consulting is part of any new install so it is not just about software.

Create product road map

The roadmap for financial software is essential as most financial institutions and service providers will have a quarterly perspective. They will want to know costs and revenues on a quarterly basis. As a product manager, you will never get a budget for adding a feature without a business plan to justify the expenditure. This is particularly so for internal development but also when rolling out software for B2B clients. In my experience, even with a Scrum approach, clients will want to define upfront what features will be included in the phases. For example:

Phase 1 (Q1 2020): Basic loan management functionality, simple dashboard.

Phase 2 (Q2 2020): Import/Export functionality, KYC module, investor report, portfolio views with transferring of assets between portfolios.

Phase 3: (H2 2020): Integration with PSD2, Automated reconciliation of bank statements, creation of direct debit instructions over bank API.

The point is that these phases are precise and define specific functionality that needs to be built by a certain time. The sales team will also take the road map and sell to it, so the features need to be completed on time (or close to it). This means that when using an Agile approach, the product backlog will need to be prioritized on the basis of the road map. Practically this also means that as the backlog is refined over time, the road map also needs to be updated and groomed as well as vice versa.

Create, refine and prioritize user stories for the product backlog

When preparing the backlog, the focus will be on the data and calculations. So a possible User Story might be:

As an Investor, I want to see an Overview of the Portfolio including Expected Loss and Fair Market Value.

Expected Loss will be calculated using Probability of Default (PD) imported from a third-party provider. Loss Given Default (LGD) will be 10% based on recovery of 65% of Valuation.

Expected Loss is calculated as follows Outstanding Amount of Mortgage * Max(0, 10% + LTV-65%) * PD * LGD whereby there will be 10% loss assumed for any LTV 65% or less and 10% plus the difference between the LTV and 65% for LTVs of greater than 65%.

Fair Market Value is defined as the last external valuation commissioned no less than 6 months prior to the current reporting date. If there is no more recent valuation then it will be used anyway but then an additional 10% will be added to the LGD to offset the uncertainty.

The point to note here is that it is all about precision of definition and calculations. It is not usually about how users access a particular screen or use a particular button. I am not saying that UX is not important at all, it is, but it takes a back seat to the numbers.

Start development

This part will be very similar to any normal project. One point I would add here is that Scrum can work very well so long as the road map constraints mentioned above are included. This means that there will most likely be some hard deadlines that have to be respected in the road map. Kanban does not work well for building financial software. The reason for that is that it is very difficult to build to phases with the flow process of Kanban. Once the software is operational, Kanban can be used effectively for managing service delivery but not during initial development.

Traditional waterfall project management is often used (especially for internal products) but this is less than ideal. This is an area where there is still work to be done in the financial markets in allowing more flexibility with feedback loops delivering value when implementing technology. It has been my observation that often management does not really want to be involved once a software project has been approved. This is fine if everything goes perfectly and the user stories are clearly defined, the problem is that this is a Utopian situation which does not ever happen in the real world. Stakeholder engagement is key but is so often very difficult to get. That is one of the biggest challenges of building financial software for large financial institutions.

Review and lessons learned

There are two ceremonies at the end of each Sprint, the Review and Retrospective. The Review is when the stakeholders are given a demo of the latest version of the product and can give their feedback. In many projects that I have worked on, there are defined governance and regularly project meetings. The problem is that often these meetings do not happen or are postponed after the first one or two. This is where your interpersonal skills as a product manager are critical. Management needs to understand that if they do not get involved early and often, they risk being surprised by the results. Additionally the budget is likely to be at risk. Now while each Sprint has a fixed cost in a traditional Scrum approach, the important thing for a financial services company is that the features are delivered on time and the budget is not exceeded, or if it is, that the increase is approved ahead of time. This needs to be part of the Sprint Review discussion or in a separate Stakeholders meeting. Of course this is an issue for any kind of development, but incomplete financial software usually does not add much value. Applying this to the phased approach, the complete phase needs to be completed with all requirements otherwise it will not be deployable and the project risks being killed.

The Retrospective is a meeting typically held without stakeholders and just the Scrum team present. This is a good time to identify stakeholders concerns and realign with the road map. It may also be necessary to add resources or even change the length of the next Sprint depending on what still needs to be done.

Release frequently to validate product features and quality

This is usually a problem in large financial institutions. It is often very difficult to implement new versions of anything. It is critical to have as much informal influence as possible with the local IT department who inevitably will be responsible for installing and granting access to the new version. Often new releases need to run through a Penetration Test, Disaster Recovery Tests and User Acceptance as a minimum. This makes releasing software challenging to say the least and also has cost implications. The best strategy I have found is to implement new versions on a test system with fewer technical requirements and to deploy to the live system less frequently. However, if the test system is also behind the firewall and the development team is external, this will still be a problem.

Another way to go about solving this conundrum is to have the software provider host a test version themselves and use that for the Sprint reviews. Then the new version of the software will be deployed to the live environment only every 3 months or even 6 months including the additional overhead of various implementation tests and review.

Engage with the customers including surveys and face-to-face interviews

For financial software, surveys, for example to calculate the Net Promoter Score, can be important and for sure can add value but the focus should be on customer interviews. Usually financial software is quite a big ticket item and has a relatively small number of users. The install base itself will be measured in thousands not millions (in some cases hundreds). Getting feedback from the end user is a fantastic way to understand how the software is being is used and whether they are happy with it. They will also be the best source for defining new product features and refining the road map. Clients will inevitably ask for additions to the road map regularly and then a decision needs to be made as to whether the desired features are relevant for all clients or if this is really customization. From a revenue perspective this is an area where additional fees can be earned although any financial benefit needs to be balanced against client goodwill.

Develop a range of KPIs to monitor and improve the product

Growth Metrics

The two most important metrics here are:

• number of installs (as opposed to the number of users)
• volume (e.g. Assets Under Management or the number of Mortgages on the system).

Usually B2B software earns fees for each installation plus some component of sharing in the volume flowing through the system.

Total users is important as well and mostly there is some per user fee as well, but it will usually be part of the initial cost calculation and is not the primary revenue driver.

Retention Metrics

The best retention metrics for this kind of product are things like:

• average number of years clients have used the system
• average percentage of clients renewing year-on-year

However, given the limited size of the install universe, these metrics should be accompanied by lists of clients, including new clients and clients that have left.

Engagement Metrics

This is probably the least important area of metrics for this type of product. The reason being is that the point is not how often people use the software but rather how important it is to their business. Therefore Growth Metrics will tell you much more about how engaged clients are than metrics such as the amount of time that users are logged into the system. Also, very often, the operations staff using the system will be logged in all day anyway so that number may not tell you very much.

There are situations where time logged in and usage of certain features can be relevant. If the product is a web app then it might be important to understand which pages were used the most frequently and how often certain functions were used but that would be more for optimization than for engagement.

User Happiness Metrics

The simplest user happiness metric is:

• Net Promoter Score (NPS)based on periodic or ongoing surveys.

This is very important and will tell you a lot about how much value you are adding. The NPS essentially tells you how likely clients are to recommend your product to others.

Revenue Metrics

This will be already be covered to a large degree by some of the growth metrics, especially AUM. However, it can be useful to calculate metrics such as:

• average lifetime value of clients

This should be broken down into installation and ongoing fees. Another important metric is

• the “P&L” of the software or the net margin

This is simply the revenue from clients minus development and maintenance cost over a period of time (often something like the current year and the next 3 years). From the perspective of the client themselves, this is an important metric as well and relates to how much revenue will the software generate for them (or save them) over time minus how much will it cost them to buy and maintain.

Summary

B2B financial software is a very specific type of animal. There are a relatively limited number of clients and the size of each purchase is relatively large. The competitive landscape can be challenging to navigate and often is somewhat opaque depending whether it is a mainstream product or more of a niche market. It is important to include indirect competitors such as services providing a similar service on demand. As a result, Product Management is very hands-on and inevitably involves a lot more direct contact with clients than for other types of B2B or B2C software. This will ensure that your clients are getting the greatest possible value out of their software purchase. In the end that is the definition of product management — to maximize the value of the product for your clients.