Client Success Driven Product Management

Behind-The-Scenes January 22nd, 2020
0Shares

Moolahsense is a digital lending platform that helps SMEs access the Capital Market to meet their business financing requirement. We focus on delivering the best returns for investors by continuously improving on our credit assessment and collection efficiency.

In this article, we highlight the “multi-linguistic” skill of a  MoolahSense Product Manager. This vital skill helps us quickly adapt to the market forces and demand, leveraging on technology as an enabler to reduce friction to market.  

In the digital age where the lines between business and technology have been blurred, product managers need to be multi-linguists in order to align business requirements to actual tangible delivery. Why? Because they need to interact with individuals across multiple disciplines to deliver the client centric product.

Product Managers need to be able to converse in  “Finance-speak”, “Tech-speak” and “Operations-speak” in order to build products that are aligned to the needs of our investors.

These languages could be even be recategorized into its second order dialects, illustrated in the diagram below,

Whilst some languages have evolved over time to have a distinct label (especially in the technology space), others are made up of a collection of terminologies that together, is a universe of concepts that make up a language. 

Even so, challenges still do arise in distilling the key requirements of an idea, that requires establishing links between the finance, operations, and technology disciplines where having multi-linguistic skills can be useful especially when interacting with the various actors within the relevant disciplines. 

The below is an example of how these languages inter-play in a Product Manager’s day to day.

We want to launch a new Product !

These words kick-off the start of ideation to delivery journey of a product/feature.

With Moolahsense products,  the following terms gives Product Managers an understanding of the product characteristics that will later on inter-play with the operational lifecycle and technology options. 

  • Notional/Principal – the amount borrowed by the borrower from the investor. 
  • Tenor/Term – the length of time that the borrower will intend to borrow from the investor 
  • Interest rate – the agreed upon rate that the investor charges the borrower, also simplistically known as the cost of funds. Interest rate is usually quoted as the interest rate per year (or per annum in “Finance-speak”). This can be defined in its monetary term through the formula,

Interest = Principal x Interest Rate x Day Count Fraction

  • Repayment period – the length of time that the borrower agrees to pay the investor some returns. This could be monthly, quarterly, annually or even customised to suit the borrower’s needs. 
  • Day Count Fraction – market convention that defines the number of days in a  repayment period and the number of days in a year. By establishing this, it allows for ease of calculation. Common financial industry based day count fraction are A/365, A/360 and 30/360. 
    • A/365 – the number of days in a repayment period is the actual number of days in a month as an example and the number of days in a year is assumed to be 365 days (even on a leap year)
    • A/360 – the number of days in a repayment period is the actual number of days in a month as an example and the number of days in a year is assumed to be 360 days (factually based on the Gregorian calendar, not correct but stated as a convention for ease of calculation)
    • 30/360 – the number of days in a repayment period is assumed to be 30 days in a month regardless of whichever month, and the number of days in a year is assumed to be 360 days (factually based on the Gregorian calendar, not correct but stated as a convention for ease of calculation)

Let’s design the processes to support this product !

The actors involved in the interplay to make this product alive are the 

  • Investors – individuals who will need to assess if the product makes sense for them in generating superior returns.
  • Borrowers – the eventual business that will be able to meet its capital needs by providing this product to Investors.
  • Operations – internal staff that will interact with the Investors, Borrowers and Product throughout its life. 

In designing the processes to support this product, it is important to have an appreciation of the respective actions that each actor needs to achieve. Examples of these actions are, 

  • Investors – I would like to view details about who the borrower is, how much returns I will be able to make and over time, how much has been collected.
  • Borrowers – I would like to view how much more needs to be repaid
  • Operations – I would like to make sure that the Investors receive what the Borrower will repay on a monthly basis. 

Within the operations language, there are multiple terms that achieve an operations objective. Whilst there may be many other sub-processes involved, for simplicity, the below items lists the main terms,

  • KYC (Know- Your-Client) – these processes apply to the validation of borrowers and investors through the submission of valid documents provided by these actors. Once these actors have been onboarded to the platform, then the interactions between these borrowers and investors can proceed
  • Confirmation – these processes apply to the contractual arrangement involving the borrowers and investors to agree to the terms and conditions of the arrangement. Documents involved in this process may require explicit mention of the terminologies described as “Finance-speak”.
  • Settlement – these processes apply to the actual cash movements to the product. With this, there are 2 key cash movements, 1) when the funds are transferred from the investor to the borrower and 2) when repayments are repaid by the borrower to the investor. 
  • Reconciliation – to ensure that the settlement processes are working as expected, the cash movements are reconciled, thereby ensuring that what funds repaid by borrowers equal funds received by investors. 

Collectively, all of these languages then need to be translated to “Tech-speak” to define a solution that is fully digitized and automated to enable investors, borrowers and operations to act seamlessly.

Putting it all together!

Having the foundation to appreciate “Finance-speak” and “Operations-speak” then lends itself to “Tech-speak”. A simple illustration of a web-design architecture will give you the best visual in understanding what tools are available to put it all together, 

Simple Illustration of a Web Based Architecture

Within these 3 constructs is where the multiple technology languages live, 

  • UI/UX – HTML, CSS, JS (and its multiple versions like AngularJS,  ReactJS) 
  • Business Logic – Java, C#, NodeJS, Python 
  • Database – SQL, T-SQL

While simplistic in nature, the web-based architecture could become more and more complex as you apply more in-depth questioning in developing the product

The below brainstorm map gives you an idea of how much more complex this can become. Thus becoming well-versed in having these languages in your bag will make you an effective communicator.

The product is ALIVE!

Now that the product is born, take stock of the multiple languages that you’ve used along the way, add to your growing vocabulary to use in your next product/feature development. 

Languages are spoken by actors within the development journey. The more Product Managers are able to exhibit multi-linguistic abilities, the less likely he will procrastinate and execute better. 

Here are a list of online resources that will give you a flavour on the multiple languages explained in this article:

Article by: Talib Mattar, Technology & Operations