FP&A platform for finance teams

Problem

Financial software is complex by nature: inputs, formulas, permissions. The interface had to get out of the way without oversimplifying the tools finance people rely on, because the same tables are used daily by power users and by someone opening the product for the first time.

Hypothesis

If tables open the product and behave the way the tool finance people already use behaves, the product's complexity stops being the barrier.

Solution

The product lives on data: tables as the initial view, with filtering and sorting shaped around how finance users actually scan numbers.

Problem

People used dashboards in completely different ways: as a start page, for KPIs, for presentations. A sizeable group avoided them altogether because there was no clear place to begin.

Hypothesis

If there is a modular grid and ready examples, a dashboard stops starting from a blank sheet, and all three groups of users build one.

Solution

Widgets users add and customize: charts with filtering and scaling, tables, images, text, all linked to source files and updating automatically. A modular grid and example templates give every team a clear starting point.

Problem

Departments had to see different things inside the same file: a department head enters their own figures and sees nobody else's, while only management sees the whole picture. A permission model that is flexible and still safe took several rounds with the developers and testing on real data.

Hypothesis

If permissions are set per file and per cell, departments can work inside one report without seeing each other's figures.

Solution

Advanced tables with complex calculations and per-role access: department heads input their figures without seeing other departments; only management sees the whole picture.

Problem

Every client wanted their own report template, and each one was a separate development task.

Hypothesis

If users can assemble a template themselves by picking variables, reporting stops waiting on the development queue.

Solution

Users assemble their own report templates by picking variables, which gives tailored reporting without waiting for custom development.

Problem

Budgeting and forecasting run on datasets nobody can read raw. The job was to make trends and anomalies legible without flattening the numbers behind them.

Hypothesis

If the data is structured by dimensions, slicing it becomes a few clicks instead of a request to engineering.

Solution

The infrastructure view: large volumes of financial data with fast access and secure storage.

Problem

Financial data has to be sliced by time, region and product, and in raw tables that turned into manual work.

Hypothesis

If dimensions are modelled explicitly, slicing becomes a choice rather than a rebuild of the table.

Solution

The attributes that slice financial data, such as time, region and product type, modeled visually for analysis and reporting.

Problem

Source data arrived as files from everywhere, such as spreadsheets, documents and images, and lived outside the system.

Hypothesis

If everything uploads and lives in one place, the sources behind the numbers stop going missing.

Solution

Excel files, documents and images uploaded and organized in one place.

Problem

Access was configured person by person and file by file, and every new department made that less manageable.

Hypothesis

If permissions go to role-based groups, access scales with the company instead of against it.

Solution

Per-file permissions for viewing and editing; users belong to multiple groups, so access is configured by role instead of person by person.

Problem

Budgeting season ran on email: who had submitted what, and what was blocking, lived in threads.

Hypothesis

If the process is modelled as ordered tasks with owners, the state of the season is visible without a single email.

Solution

Structured processes with ordered tasks assigned to people: budgeting season as a managed pipeline instead of email threads.

Problem

Signing in gave no feedback: it was unclear whether an action registered, or what exactly was wrong.

Hypothesis

If states and validation are explicit, a person understands what went wrong on the first try.

Solution

Authentication reworked with clear states and validation feedback.

Problem

People who are not finance professionals still have to enter figures and read reports, and they arrive for an outcome, not for a course in the product.

Hypothesis

If the product guides by scenario and explains in context, non-financial roles will manage without a separate training session.

Solution

Finance professionals are the primary users, but executives and department heads work in the system too. The onboarding was rebuilt around guided flows, in-context tooltips and scenario-based tutorials.