Durga Batchu
← Selected Work
  • Lead Designer
  • ·
  • Hissa
  • ·
  • AI / Decision systems

Building an AI-assisted compensation modelling tool.

A decision system for balancing cash, equity, and future value.

Compositionv.04
Cash42%
Equity68%
Performance26%
Tenure horizon54%
4 of 9 leverslocked · 1
Target total
₹2,84,50,000
per annum · 4-yr horizon
Y1Y2Y3Y4
Suggested adjustmentwhy →

Shift +6% from cash into equity. Improves expected value at Y4 by ₹26L, reduces near-term liquidity by ₹6.7L.

Reasoning
  • · role band · L5 IC
  • · market p65 · cash floor met
  • · vesting cliff cleared at Y1
Role
Lead Product Designer
Scope
Composition · Simulation · AI proposals · Audit
01 · Problem

Compensation is a decision system, not a spreadsheet

In private companies, every offer is a small policy decision. Cash, equity, refresh cadence, performance multipliers — each lever moves three other levers, and the consequences play out over four years instead of four weeks.

The tooling never caught up. Comp teams reason through these tradeoffs across four spreadsheets, two Notion docs, and a valuation model someone built two funding rounds ago. The numbers eventually agree, but the reasoning behind them evaporates between meetings.

Equity is the worst-served lever. It is the largest part of most offers and the least understood — discussed in percentages, granted in units, taxed in rupees, and worth something only at an event nobody can date.

The product had to do two things at once: hold the math, and hold the reasoning. A calculator was never going to be enough.

Fragmented
4–6 tools per offer
Opaque
equity reasoning rarely captured
Slow
days to model a counter-offer
Unauditable
decisions live in Slack threads
02 · Positioning

Not a calculator

“We weren’t designing a salary calculator. We were designing a decision-making system for balancing cash, equity, and future value.”

Calculators answer a question. Decision systems help you ask better ones. The product had to make tradeoffs visible — show what each lever cost, who it favoured, and when it paid out — and then let the human make the call. The AI sits inside that loop. It does not own it.

03 · Principles

Designing AI you can argue with

P.01

Explainability over automation

Every recommendation arrives with its inputs, its weights, and its uncertainty band. The model never says ‘trust me’. Comp teams can disagree with a proposal — and disagreement is captured as data, not lost in a meeting.

Recommendationconfidence · 0.82
Increase equity weight to 68%

Compared to your role band median, current equity is 11pp light.

  • Role band L5weight 0.42
  • Market p65weight 0.28
  • Retention curveweight 0.18
  • Pool capacityweight 0.12
Inputs are visible. Weights are editable.
P.02

User control and freedom

The user sets constraints; the AI proposes within them. Locks, floors, ceilings, and refresh policies are first-class objects. Anything the model is allowed to move is editable; anything it isn’t, isn’t.

Constraints
Cash floor
≥ ₹1.17 Crlocked
Equity ceiling
≤ 0.45%locked
Refresh cadence
24 molocked
Vesting shape
4y · 1y clifflocked
AI proposes within constraints the user owns.
P.03

Progressive disclosure

Three layers of depth — summary, breakdown, derivation. The first screen answers ‘what is the offer’. The second answers ‘why this shape’. The third answers ‘where did each number come from’. Most decisions never need to leave layer one.

Composition · summary
Cash 42Equity 38Bonus 14Other 6
Expand · equity
  • RSU grant₹76,50,000
  • Refresh (Y2)₹23,30,000
  • Performance multiplier×1.10
Three layers: summary · breakdown · derivation.
P.04

Trust through transparency

Every state change — human or model — is timestamped, attributed, and reversible. The audit trail is not a compliance feature; it is the product. It is how the team learns from its own decisions over time.

Audit trail
  • 13:42AISuggested +6% equity
  • 13:43YouAccepted suggestion
  • 13:44SystemRe-ran simulation · 1,000 paths
  • 13:45YouLocked cash floor at ₹1.17 Cr
  • 13:47AIConstraint binding · revised proposal
Every state change is attributable.
04 · Process

Modelling the model

Subsection

AI multiplier logic

The recommendation engine is a weighted multiplier across role band, market data, retention curves, pool capacity, and user-set constraints. We made the weights visible from day one — not as a ‘power user’ feature, but as the default surface. A weight you cannot see is one you cannot trust.

Role bandMarket dataRetention curvePool capacityUser constraintsMultiplier modelΣ wᵢ · fᵢ(input)Composition proposalWhy this proposalSensitivity rangesfig 01 · multiplier weights are visible and adjustable — the model is not a black box.
Subsection

Equity vs cash balancing

The two largest levers move on different time horizons. Cash compounds in the bank account; equity compounds in the cap table. We modelled the tradeoff explicitly — every rupee shifted from cash into equity gets a projected Y4 value and a near-term liquidity cost, so the conversation moves from ‘how much’ to ‘when’.

Archetype
Liquidity-first

Higher cash floor, lower equity multiple. Suited to candidates with short horizons or near-term obligations.

Archetype
Upside-first

Lower cash, larger equity grant with a refresh at Y2. Higher variance, higher P50 at Y4.

Archetype
Balanced

The default. Cash at market p65, equity sized to retention curve, modest performance multiplier.

Archetype
Performance-weighted

Smaller base, larger bonus tied to milestones. Used for senior IC and leadership offers.

05 · How I worked

How I worked

Early explorations

Three early framings of what the product could be, before we committed to a decision system.

Salary calculator

The obvious starting point. It answered "what is the total?" but not "why this shape?" Comp teams could get the number; they couldn't explain or defend it. We needed a system, not a calculator.

Spreadsheet replacement

Tried to reproduce the familiar tool inside the product — rows, columns, formula cells. It felt safe to users but it inherited all the original problems: no reasoning capture, no audit trail, no AI in the loop.

Recommendation-first UI

AI surfaced a proposal upfront; the user accepted or overrode it. Fast, but it put the model in control. Comp teams wanted to reason, not just approve. We inverted it: the human sets constraints first, the model proposes within them.

Key decisions
Should AI recommendations appear proactively or on demand
Options considered

Proactive (always visible) vs. on-demand (triggered by the user)

Why we chose this

Proactive felt presumptuous for high-stakes decisions. Comp leads wanted to form their own view first, then pressure-test it against the model. On-demand kept the human in control without hiding the AI.

How visible should the model's weights be
Options considered

Hidden (black-box output only) vs. visible and editable

Why we chose this

A weight you can't see is one you can't trust. Making weights visible and editable meant comp teams could argue with the model — and disagreement became data rather than noise.

How to handle constraint conflicts
Options considered

Prevent them at input vs. let the model surface them

Why we chose this

Blocking constraints at input frustrated power users who needed to explore edge cases. Letting the model surface conflicts inline — with an explanation of which constraint was binding — taught users the system faster.

What didn't work
06 · Interfaces

Selected interfaces

InterfaceComposition builder
Composition builder · L5 · IC
Base cash42% · ₹1,16,55,000
Equity (RSU)38% · ₹90,00,000
Performance bonus14% · ₹21,90,000
Sign-on6% · ₹8,30,000
Total · ₹2,84,50,000locked · 1 of 4
Annotations
  • A · slider
    Drag to re-weight; locked levers stay fixed.
  • B · numerics
    Percent and rupee values move together.
  • C · totals
    Sum is the only non-editable field.

The primary surface. Sliders are linked to rupee values, rupee values are linked to constraints, constraints are owned by the user. Locking a lever pins it; the model re-solves around it.

InterfaceScenario comparison
Scenarios · side by side
Current
  • Cash48%
  • Equity32%
  • Bonus14%
P50 · Y4
₹8.7 Cr
Proposal
  • Cash42%
  • Equity38%
  • Bonus14%
P50 · Y4
₹10 Cr
Aggressive
  • Cash36%
  • Equity46%
  • Bonus12%
P50 · Y4
₹12.2 Cr

Side-by-side scenarios are how comp teams actually think. We made comparison structural rather than modal — three columns, the same axes, no hidden differences. The conversation moves from ‘which one is right’ to ‘which one are we willing to defend’.

07 · Shipped

What went live

Org chart builder
Org chart builderStep 1 — an AI-generated org structure, fully editable. Roles carry level, department, and band-aware salary ranges before a single number is set.
Model dashboard
Model dashboardStep 2 — the compensation surface. Pool, valuation, and per-role multipliers sit on one screen; every change re-solves the totals in place.
Scenario comparison
Scenario comparisonSide-by-side models with pinned key differences. Comp teams defend a choice instead of guessing which spreadsheet was latest.
08 · Reflection

What this project taught me

The most useful thing AI did inside this product was not give answers. It was hold the long, messy chain of reasoning that a human comp lead used to keep in their head — visible, editable, and persistent across conversations.

In financial UX, trust matters more than automation. A model that is 90% accurate but legible is more useful than one that is 95% accurate and opaque: the first can be argued with, the second can only be obeyed or ignored.

Interpretability is not a feature you bolt on. It is a layout decision, an interaction decision, and a copy decision, made every time the model touches the screen. Designing AI products is, in the end, mostly a design problem.

← Back to selected workCase study · 02