Product design

Self-Serve Formula Builder

Cut first-model implementation time by 20% enabling teams to onboard with less hand-holding.

Finicast was a B2B financial modeling platform for analyst teams outgrowing Excel. While the product supported powerful calculations over large datasets, formula creation relied on a SQL-like syntax and fragile references preventing analysts from working independently.

The Challenge

Analysts had access to powerful modeling capabilities but couldn’t use them independently. Creating formulas required a SQL-like language and precise dimension references, so Customer Success ended up building formulas during onboarding—slowing activation and limiting scalable adoption.

Proposal

Introduce an Excel-aligned expression layer on top of the existing SQL engine, add guided referencing (autocomplete + point-and-click), and implement guardrails (explicit apply/confirm, invalid selection prevention) to reduce errors and performance-heavy processes. Support advanced needs through progressive complexity (basic formulas → scoped conditions).

Tools

Figjam and Figma

Year

2024

Why this mattered (Product framing)

Problem

Formula creation was the main barrier to user autonomy. Analysts depended on Customer Success to set up and maintain formulas, which created an operational bottleneck and reduced the product’s self-serve value.

Success Definition

  • Analysts can create and adjust formulas without needing SQL knowledge

  • Users can select the right dimensions confidently (less fragile referencing)

  • Advanced users can still express complex logic via scoped conditions

The Process

process

Discovery

Inputs
  • Reviewed Customer Success interview recordings and onboarding feedback
  • Worked with CS and internal financial SMEs to understand common modeling patterns
  • Assessed the formula workflow through internal usage and dogfooding
Risks and Constraints

  • Must map cleanly to SQL engine.

  • Large dataset recompute cost.

  • Multi-table workspaces.

Key insights

  1. Language mismatch: Users thought in arithmetic and Excel patterns, not SQL commands.

  2. Referencing friction: Selecting the correct rows/columns/dimensions was fragile and error-prone.

  3. Hidden complexity: Some users “used SQL” without realizing it, leading to low confidence and frequent mistakes.

  4. Performance risk: Editing formulas could trigger expensive recomputation on large datasets, impacting system stability.

Design principles

principles

The Solution

1. Excel-aligned expression
layer (on top of SQL)

2. Autocomplete +
point-and-click

3. Explicit Apply/Cancel
interactions

Excel-aligned expression layer (on top of SQL)

We replaced SQL-style operations with familiar arithmetic operators and readable tokens so analysts could express intent without thinking like developers. Syntax highlighting helped users parse grouping and structure at a glance.

Move 1
Move 2

Autocomplete + point-and-click

To reduce fragile typing, users could reference fields/dimensions by:

selecting from suggestions while typing (autocomplete), and
clicking directly on the table to insert valid references (point-and-click)

This reduced reliance on recall and minimized syntax mistakes.

Guardrails for performance and error prevention

During internal testing, we found that “live” formula edits could trigger heavy calculation on large datasets, causing slowdowns and system instability. We introduced explicit "Apply" and Cancel controls, allowing users to review changes before running expensive processes.

move 3
Move 4

Progressive complexity via scoped conditions (“Where”)

Basic formulas needed to be easy, but real modeling required context. We used a scope builder so formulas could apply to:

Version (Actual vs Budget/Plan)
Time period (Month/Quarter)
An specific Cell (point and click)

This kept the default path simple while supporting advanced logic when needed.

Formulas as reusable objects

As the product evolved into multi-table workspaces, formulas needed to behave like first-class objects, not ephemeral text inputs. A workspace could contain multiple tables, and each table could have multiple formulas attached. Naming made formulas:

Identifiable - Clear editing context across tables
Collaborative - “Budget calc”, “Revenue forecast”
Reusable - duplicate and apply logic across scopes/dimensions
move 5

More Context

Collaboration

  • PM led the initiative; I owned the end-to-end design work

  • Partnered with Engineering to ensure the Excel-like layer mapped cleanly to the underlying SQL engine

  • Used Customer Success and internal analysts as domain proxies for early validation

Key trade-off: robust conditions vs simplicity

We recognized the conditions system could feel complex, but it was necessary to support real-world financial modeling. We kept the system robust while making the default path lightweight and progressively revealing complexity.

Validation and outcomes

Validation approach

  • Pre-launch validation was internal (CS + internal analysts) due to time/access constraints
  • Post-launch feedback informed iteration.
  • What we tracked: success rate, average task time.

Results

Better and shorter onboarding

  • Before: CS building formulas during onboarding

  • After: analysts can self-serve; CS shifts to enablement

  • Metric: 20% reduction first model implementation time + NPS improvement

new layout