Tarya is a financial company focused on non-bank loans. Your operational needs cover the entire development flow of a loan.
Within the plan to modernize all the systems that we carry out at Tarya fintech (Tarya’s sister company), the system for the collection of late fees was special since it had never been developed as a product. One of the main needs was a Dashboard with data on the entry of money for late fees
i was the Product designer in a team made up of two Product managers and occasionally a data engineer.
The team for the collection of late fees was managed with a series of Excel spreadsheets from which they developed the work. The value of data provided by these forms was of low quality.
build a dashboard with data of significant value so that users can make decisions
We conducted three different interviews with the executive positions of the company who, due to their role, would have access to the Dashboard
“The most important thing is the amount of money in relation to debt” was the most important conclusion of the 3 meetings.
The first necessary analysis had to be about the flow of money coming in due to late installment payments. This was the only thing that mattered to the executives who were not part of the debt collection section.
Those who led the debt collection team were also interested in the flow of money since they had to report on this but they needed to know how the debt was divided in terms of time and origin of the loan.
Previously, for this section, we had used a CRM platform for the collection of due fees. We had worked closely with the operators to understand what the workflow and tasks were.
This immersion helped us, in this case, to really know the KPi’s that would be necessary in the dashboard since this would have to be a reflection of the team’s work
We set out to develop a clear definition of the problem with the 4W technique
Our problem can be framed as:
The manager cannot analyze the team’s work because he does not have valuable information about the collection of late installment payments.
Having defined the problem, we got to work devising hypotheses and functionalities that could solve it. We elaborated a lot of ideas that we grouped according to what data the functionality would work on.
And with a Moscow board we debated which ones we should carry out in the MVP. Which ones were achievable and which ones did not add value