Remote (Preference to folks based out of Bengaluru)
Adalat AI is building an end-to-end justice tech stack that automates manual and clerical pain points in courtrooms, giving judges back time to focus on what matters most: decision-making and delivering justice. Our solutions — from AI-powered transcription in Indian languages to case-flow management, document navigation, and the Paperless Courts platform — are now deployed across 10 states, covering nearly 25% of India's judiciary. Backed by leading technology companies and funders, and incubated at MIT and Oxford, Adalat AI is working to eliminate judicial delays and expand access to timely justice. Founded by a team with backgrounds in law, technology, and economics from Harvard, Oxford, MIT, and IIIT Hyderabad, we are scaling rapidly across India and the Global South.
Role Overview
We are hiring a Product Analyst to own the truth of what happens inside our products.
Every dictation, template, and error in a courtroom is a data point. Today those data points are not trustworthy enough to decide with. Teams add instrumentation without telling anyone. The result is that the company is making decisions on numbers nobody has verified.
You will fix that, and then build on top of it. You own the data going in — the taxonomy, the review gate, and the migration off Mixpanel onto analytics infrastructure we run ourselves. You also own the answers coming out — feature-level usage across states, the recurring report leadership plans around, and the analysis that settles arguments.
One thing to be upfront about: we are not moving from one SaaS analytics tool to another. Because we work with judicial data, our replacement for Mixpanel has to run on our own infrastructure, under our own control. That means this role sits closer to the metal than a typical product analyst job. You will help shape the event schema the new platform is built around, run the dual-send validation, migrate two and a half years of history, and reconcile the numbers on the other side. You do not need to be an infrastructure engineer, and you will not be on call. You do need to be the kind of person who is curious rather than alarmed when the answer lives one layer below the dashboard.
We have a preference (not a requirement) for people who have been the first analytics hire somewhere, with no standards to inherit. Our analytics function is young. We are not looking for someone to maintain a mature stack; we are looking for someone to build the thing that everyone else will later take for granted.
Key Responsibilities
Own data correctness — rebuild and document the event taxonomy, kill duplicates, and be the review gate through which every new event any team adds must pass
Catch drift before it ships — build alerting that detects new or changed events at the point of development, so we are never relying on teams to self-report
Own the migration off Mixpanel — design the target event schema, run dual-send validation, export and dedupe two and a half years of history, load it into the warehouse, and reconcile the numbers until we can retire the old system with confidence
Be the product voice on the platform build — we are standing up self-hosted analytics infrastructure alongside this hire. You will not own the servers, but you will own what goes into them: the schema, the PII handling, the data model the rest of the company queries
Build feature-level visibility — which feature, which state, which user type, trending which way, at a granularity that survives a CXO's follow-up question
Own the recurring reporting — the bi-weekly feature analytics report for leadership, and the state-level and feature-level reporting inside the partnership portal
Answer the questions that matter — correlation work against partnership OKRs across states, and one-off investigations where the answer changes a decision
Make the company self-serve — open up warehouse querying to other teams so routine questions stop routing through you
Treat privacy as part of correctness — our users are judges and court staff, and some of our existing data captures more about them than it should. Fixing that, and keeping it fixed, is part of owning the taxonomy
About You
You do not trust a number until you have checked how it was made. When someone shows you a chart, your first instinct is to ask what was filtered out. You have been burned before by a silent join, and you have not forgotten it.
You are fast with SQL and comfortable in Python, but you do not confuse tooling with the job. The job is that someone made a better decision because of you. A perfect query nobody acts on is a failure.
You write. Every number you produce comes with a sentence explaining what it means and, when it applies, a caveat you volunteer before anyone asks. You would rather say "I don't know yet, here is how I'd find out" to a CXO than guess confidently.
You are comfortable being the person who says no. Teams will want to ship events without review and pull numbers without context. Holding that line politely, every time, is a real part of this role.
You are not put off by an unfinished stack. Some of what you need in your first months will not exist yet, and you will be helping decide what it looks like rather than inheriting it. If you would rather join somewhere the pipes already work, that is a completely reasonable preference and this is the wrong role.
Qualifications
1–3 years working with product or business data with real ownership
Strong SQL — you write window functions without looking them up, and you notice when a join changes your row count
Working Python or equivalent for cleaning, reconciliation, and one-off analysis
Hands-on with a product analytics tool — Mixpanel, Amplitude, PostHog, GA4 or similar — and a real understanding of event, property, and user schemas. Comfort with open-source or self-hosted tooling is a plus
Ability to build a dashboard that someone other than you actually uses
Clear, tight writing — memos and caveats people can act on
Genuine interest in AI and legal-tech, and in how Indian courts take up technology
Especially valuable
Warehouse experience (Azure, BigQuery, Snowflake, Redshift) and a transformation layer such as dbt
Having run a platform migration or a taxonomy cleanup before, and being able to describe what went wrong
Comfortable around Docker and a Linux box — you do not need to be an SRE, but a terminal should not slow you down
Exposure to a columnar analytics store such as ClickHouse, DuckDB, BigQuery or Redshift, and a feel for why they are fast
Having worked somewhere data could not leave the building, and understanding what that constraint changes
Using LLM tooling for analysis; we are scoping an analytics agent
Experience in government, legal, public infrastructure, or other privacy-sensitive environments
What You Will Achieve in a Year
You will have made the event data trustworthy — documented, deduplicated, and gated, so no team adds instrumentation without review
You will have completed the migration onto infrastructure we run ourselves, with two and a half years of history carried across, the numbers reconciled, and Mixpanel retired
You will own the clearest read of product usage in the company, and leadership and partnership will plan around your reporting
You will have opened the warehouse to other teams, so the routine questions no longer come to you and you are free to work on the hard ones
We keep our process straightforward and transparent. Here's what to expect:
R1 — Intro Call (30 minutes) An introduction to Adalat AI — our mission, the problem we're solving, and an initial conversation around role fit.
R2 — Take-Home Exercise (3 hours, completed within 3 days) We'll send you a real, messy dataset and ask you to tell us what's wrong with it, answer one question using it, and show us the one chart you'd put in front of a CXO. We cap this at three hours and we mean it — we're looking at judgement, not endurance.
R3 — Work Deep-Dive and Working Session (60 minutes) A walkthrough of your exercise with the hiring manager and one other team member. Expect to be interrupted with questions about the calls you made, what you left out, and what would change your conclusion. Then a live conversation about situations this role actually runs into — a number that doesn't match another number, a stakeholder who needs an answer today, a question that hasn't been defined properly yet, and how you'd decide whether a migrated dataset is safe to trust.
R4 — Culture Fit — Founder Chat (30 minutes) A conversation with one or more of our founders to assess mutual fit and shared values.
R5 — Offer — One or two reference conversations, and if it's a great match on both sides, we'll move forward with an offer.
We aim to complete the full process within four weeks of your application, and to come back to you within a week at every stage.
Benefits and Perks
WFH with flexible work hours
Unlimited PTO
Contacts within the Harvard / MIT / Oxford ecosystem
Autonomy and ownership
Smart, humble, and friendly peers
Generous vacation
Maternity and paternity leaves
Learning & development resources