03 · Complex UX · Fintech · Product strategy

Mis Resultados: from patch to product

A module to manage sales performance in banks. The real challenge wasn't the interface. It was understanding the true size of the problem and deciding what not to build yet.

Drawing: a person in a suit, standing on spreadsheets and a calculator, looking up at a building whose floors are numbered 1 to 5.

00·

The problem

Banks have large sales teams, with goals, rankings and incentives that change every month. Managing all of that is chaos: Excel spreadsheets, manual configuration, scattered information. Nobody has a clear view of their own performance in real time.

The first version of this platform existed, but it was designed to solve the specific problems of one particular bank. With no admin module, targets and goals had to be configured by hand every month, at an enormous cost the support team absorbed internally.

It wasn't a product: it was a patch.

01·

The problem was bigger than it looked

When I dug into the real scope of the project with the PO, the first thing that became clear was that this wasn't about improving screens: it was about building a platform that could be implemented in any bank, with different business rules, different organizational structures and different incentive models.

The analysis led us to define three user profiles with completely different needs: the Sales rep, who wants to know how they are tracking against their targets; the Supervisor, who needs to see their team's performance; and the Administrator, who configures the system's rules.

Feature map for the Sales rep: a three-branch tree that fits entirely on one screen. — The two feature maps at the same size. The contrast speaks for itself: one is contained and direct; the other is the heart of the problem.

Feature map for the Administrator: a tree of the same kind with dozens of nodes spreading sideways across four levels. — The two feature maps at the same size. The contrast speaks for itself: one is contained and direct; the other is the heart of the problem.

The admin module turned out to be that heart. Without it the system can't scale: someone always has to configure something by hand. But designing it properly was enormously complex, and that is where it differs from any traditional incentive system.

A loyalty system for a clothing store is relatively direct: you sold X, you hit the goal. In banking the rules are another matter. If an executive's target is to sell 15 cards in a month and they sold 15, but 3 clients cancelled, their real result is 12. And that is the simplest case. If on top of that 3 of those cards were sold by a call center agent to clients in that executive's portfolio, the count can be half a card, a whole one or none at all, depending on the bank's rule.

Every bank has its own version of that logic. Covering every case without the administrator interface becoming unmanageable was the real product challenge.

Admin screen: on the left, a library of six items and four collapsed product groups; on the right, three columns —only the first one filled in— where each card carries its threshold and its weight. — The configuration sidebar for a single target: tiers, locks, accelerators, rate tables and cross-team incentive models. Each node is a screen, and all of it has to coexist without losing the user.

The project was sold for implementation at a large bank in Peru. The scope was ambitious, the timeline tight, and the parties never found the flexibility needed to move forward. The project was left unfinished.

Wireframe board: dozens of grey screens connected by arrows and grouped by flow. — The v1 wireframes: the information architecture before the screens. That work was not lost: it is what made it possible to narrow the scope of the next version properly.

02·

The decision

When v2 started, the question was how to move forward without repeating the same mistake.

Start where there is the most immediate value and the least risk of infinite complexity.

We prioritized Mis Resultados, the performance viewer for sales reps and supervisors, the module with the most impact on the commercial user's day to day. And for the administrator, in this first pass, we went with Excel templates that map the configuration straight into the system: a pragmatic bridge that lets the bank operate without blocking all development on the hardest problem.

Configurator: Targets and Periods tabs, and a table with creation date, name, identifier, category, unit of measure and a toggle per row. — The MVP configurator: Excel as the admin interface. It is not the final solution. It is the right solution for this moment.

3 countries of implementation

3 user profiles

4 months from v2 to pilot

v3 product iterations

03·

The product

A platform that lets a bank's sales teams see their performance in real time —targets, results, rankings, incentive status— without depending on manual reports or on someone updating a spreadsheet.

Sales rep screen: photo, ranking and total attainment on the left; in the center, one column per target with the goal at the top and progress marked in green, blue or red. — The Sales rep's main screen: the month's targets, real-time progress and incentive status, without having to ask anyone for anything.

Ranking view: four indicators at the top —own attainment, position, average and gap to first place— and below, the list of positions with photo, percentage and change. — The three profiles covered by the same system: each one sees the slice of performance they are responsible for.

Supervisor view: the team spread across ten deciles and, below, a card for each person they manage with their attainment. — The three profiles covered by the same system: each one sees the slice of performance they are responsible for.

What matters most about this case is not the product itself, but the process of figuring out where the problem actually was. v0 solved symptoms. v1 found the real size of the challenge. v2 made the hardest call: narrow the scope with judgment, without losing sight of where the system has to go.

Today it is in production in Panama, in implementation in Chile, and coming to Brazil.

The request came in as a screen. "We need a results view." The most expensive move in this case was refusing to design it on day one: had I designed it, I would have solved the symptom and left the real problem intact, waiting to show up in the next ticket.

correction I underestimated the size of the problem and lost time over it. I started mapping one role and halfway through it turned out there were three, with different and sometimes opposing incentives. I had to go back and redo the whole mapping. The lesson was not "do more research": it was that when a request comes from a single role, there is almost never a single role.

This is the decision I am proudest of and the one you can see the least. Choosing a pragmatic bridge instead of blocking all development on the hardest problem shows up in no screenshot. It is the difference between a v2 in pilot in four months and a perfect v1 that never ships.

correction v1 shipped unfinished and I defended it anyway. That is where I learned to tell narrowing the scope apart from delivering half of something: the difference is whether what you ship stands on its own. v1 did not; v2 did, with fewer features.