Prioritisation of Features in Financial Services Software
Changing regulatory requirements and the emergence of newer and complex financial instruments have drastically reduced the time available for marketing a product. With increased competition, it has become imperative to offer new products at a quicker rate and at lower costs. Under ideal conditions one would like to deliver whatever customers wishes. But the product development teams, working under aggressive deadlines and with limited resources at their disposal, find it difficult to fulfill all the requirements and at the same time adhere to the timelines. This is where the product manager must play a key role. The functionalities must be evaluated on the basis of cost, technical complexity, risks involved, and time and resources required. Based on the above evaluation, the features must be classified into groups such as: critical, high priority, medium priority (nice to have) and low priority (frills) features. The decision to include a feature depends on the classification level and its alignment to overall product objectives.
Critical features are those features without which the product cannot exist. These features must be included in the release. For example, a portfolio performance and attribution system must include calculation of returns.
These features are not critical to the functioning of the application but without this the product will not be acceptable to the customer. Considering the same example of the portfolio performance and attribution system, if the client deals in multiple currencies, the ability to calculate returns based on asset positions held in multiple currencies is a high priority feature.
These are the features that are nice to have. These features must be evaluated on the basis of their inter-relationships with critical and high priority features. If the absence of any of the medium priority features severely limits the functioning of a critical feature, then such a feature must be included in the release. The rest of the medium priority features can be taken up depending on the availability of time and resources. Continuing with the same example, the ability to define a benchmark, when viewed in isolation could be a medium priority item, but calculating returns without having the ability to compare with benchmark return severely limits the utility of the system. Such types of medium priority items must be included in the release.
These features are generally cosmetic in nature. Some of these features can be included if there is spare resources available after the critical, high and medium priority items are taken care of. The rest can be pushed to subsequent releases.
It is not easy to categorise features into the above-mentioned categories; it is more of an art than a science. It depends on the experience, level of understanding of user requirements, and maturity of users and technical complexity associated. A multitude of factors must be taken into account while determining the priority of a feature. A number of issues must be addressed while prioritising the features.
Every feature delivered to customers has a cost associated with it. The costs eventually have to be passed on to the customers. The customers would be willing to bear the cost if they feel the feature provides substantial value. The value could include, but is not limited to, cost savings, reduction in number of errors, improved productivity, ability to process new financial instruments and access new markets. The customers must feel that benefits accrued from the feature exceed the price paid for it. The feature that is valued by the market must be given higher priority. It does not make any sense to provide a feature that is not valued by the market.
Consider the case of an order management system that caters to a single asset class and has access to execution systems within the domestic market. Any enhancement that will provide the user the ability to deal in multiple asset classes and access to markets located in different countries would be welcomed by large international customers even if it is priced high.
There could be cases where customers may not be aware of the potential value of a specific feature. In such cases one of the approaches could be to roll out the product without the feature and include it in the next higher version as an enhancement. Once the users start using the functionality they will realise the benefits of the feature. Based on their experience in using the feature they might come up with suggestions to fine-tune it.
One of the biggest risks in categorising the features arises when there is a strong technical bias in evaluating the features. There could be a big gap between what the technology developers believe is suitable and what the user actually wants. Some of the essential features may be classified as low priority items if they are difficult to achieve from a technical perspective. On the other hand some non-essential items may be classified as a high priority item if they are easy to code. Customers rarely understand the technical complexities involved in implementing a specific functionality. The product manager must avoid this pitfall and ensure that the essential features are not assigned a low priority due to technical reasons.
Continuing with the example of an order management system, functionalities such as pre-trade analytics and ability to create and execute trading strategies should be given high priority irrespective of the technical complexity involved.
Involvement of stakeholders has a significant effect on the quality, cost and delivery schedule of the product. In the financial services space there are two types of stakeholders:
A product must address the requirements of the direct stakeholders and at the same time cannot ignore the concerns of the indirect stakeholders. Usually these stakeholders do not agree on the relative priority of the features. The differences arise due to insufficient communication, incorrect perception, control over resources and, most importantly, the belief that their own requirements must dominate. It is essential to develop a common list of priorities to avoid last minute surprises.
Consider a scenario where a broker workstation interfaces with a cost basis engine, both the systems maintain the market value at account level, but the values do not match. This could be due to different valuation methods used or different source of price data. For the market value to match, changes have to me made to one or both systems. The teams working on both the systems must be involved from the beginning in deciding the changes to be made so that they are fully aware of the priorities attached with the changes and their impact on priorities of other features.
Existing customers play a significant role in determining the relative priority of features. Usually in the financial services industry, the clients are big institutions who can influence the product development process due to their sheer size. The product manager is faced with the challenge of balancing the demands of existing customers and the market requirements. Catering to market requirements is essential to penetrate the existing market and make inroads into newer or parallel markets. The product manager must evaluate the relative importance of existing customer demands (bug fixes, enhancements etc.) and market requirements (new features) while finalising the priority list.
If a product has established players as competitors then the product managers cannot ignore the features provided by the competitors. In such a scenario, a product having the bare essentials would not be perceived well by the market. If the features provided by the existing products are valued by the customers then such features must be given higher priority. Sometimes the additional features provided by the competitors could be frills attached to the core product, which do not add much value. But the market tends to get used to such frills and often complains if they are not provided with the product. In such cases a better approach would be to improve upon the frill so that it adds value to the product. If the product manager feels that no such value addition is possible and the benefits of copying the feature do not justify the cost, then the features should not be considered for inclusion.
Continuing with the example of a broker workstation, the ability to customize the dashboard may not be a critical functionality but it is a feature that is provided by most of the existing products and any new entrant to the market must provide this feature.