Product · AI · Automation
I turn messy problems into useful systems.
I’m Mahitha, a Data Science and Business student at Northeastern. I combine product thinking, technical depth, and business context to build experiences people can trust and use.
Selected work
Three ways I approach product problems.
Consumer product strategy
BeReal Product Externship
Exploring what may cause users to post late or skip posting, then translating behavioral observations into a focused product opportunity and validation plan.
AI product development
SMBC AI Governance Platform
Redesigning a fragmented bank-wide AI review process into a structured, traceable workflow supported by a five-agent system.
Product automation
REBA Validation System
Shadowing implementation work and client calls to turn a repetitive onboarding process into adaptable validation tools for three property-management systems.
01 · BeReal
From behavior to a testable product opportunity.
Product Management Extern · 2026
Understand what may contribute to late or skipped posting.
BeReal’s daily notification creates a distinct posting moment. I examined where hesitation could enter that journey, including the possibility that seeing friends’ more exciting moments may increase social comparison for some users.
Research
Map journey
Frame problem
Define metrics
I completed a product teardown, mapped the end-to-end user journey, synthesized behavioral observations, and reframed the initial idea as a user-centered problem rather than jumping directly to a feature.
Test the social-comparison hypothesis through interviews, surveys, and posting behavior. Key signals include notification-to-post conversion, on-time posting, retakes, and 30-day retention.
02 · SMBC Group
Making AI governance faster without losing control.
AI Intern · AI Enablement & Governance
A high-stakes review process was fragmented and manual.
AI requests arrived with inconsistent information. Analysts checked for missing details, drafted clarification emails, and tracked status manually across more than 200 use cases.
Guide requesters and validate information upfront.
Three agents examine different governance dimensions.
Generate traceable outputs and next steps for analysts.
Measured impact
The goal was not maximum automation. I designed structured conversation flows, validation logic, guardrails, and a shared data layer so analysts could retain oversight while removing repetitive work. I also supported adoption through training and banking-specific guidance.
03 · REBA
Turning a manual onboarding process into a scalable validation product.
AI Development Intern · Product Automation
The team was not simply comparing two numbers. They first had to find the right report, property, table, date range, and metric definition.
During client onboarding, implementation teammates manually reconciled REBA Cube metrics against exports from Yardi, Entrata, and AppFolio. Reports varied by customer, workbook, sheet, filename, and metric definition. Even a matching total could hide the units or records causing a discrepancy.
I learned the workflow before deciding what to automate.
I shadowed different implementation team members as they refreshed Cube data, searched client reports, calculated metrics, and investigated mismatches. I also joined client calls to understand the questions clients asked, the evidence they expected, and where the onboarding process slowed down. I paired those observations with Cube training, the existing validation guide, stakeholder working sessions, and real customer reports.
Shadow the manual process
Listen to client needs
Map pain points and exceptions
Translate findings into requirements
Key product insightReliable validation depended on identifying the correct context before comparing values. Automating the comparison alone would not solve the team's real problem.
Keep the experience inside Excel, require no Python setup, support inconsistent report structures, show the source value even when it mismatched, and return an explicit result for every Cube property.
I started with frequent Unit Analytics checks and individual reports where the workflow was clearest, then expanded into metrics and formats with more ambiguity. This created usable value while I learned the edge cases.
Automate the repetition, preserve the investigation.
- Refresh Cube data for the client and period
- Find the correct source report and property
- Locate the metric and interpret its definition
- Calculate and compare values manually
- Trace the records behind every mismatch
- Refresh the Cube data in the existing workbook
- Select the folder containing client reports
- Run a metric-specific check from the ribbon
- Review aligned source values and match status
- Investigate only the exceptions that need judgment
A familiar interface with a hybrid validation engine.
Refresh Cube data and launch checks
Pass the workbook and report folders
Resolve ambiguous properties and layouts
Calculate, compare, and verify completeness
Write source values and results into Excel
AI assisted with fuzzy property matching, inconsistent headers, irregular workbook layouts, and structured field extraction.
Python handled arithmetic, formulas, numeric validation, exact comparisons, completeness checks, totals, and final writeback.
Iteration that changed the product
The first Entrata approach silently omitted properties.
A stress test compared 57 Cube properties against an Entrata workbook with 43 property sheets. One large AI request returned only 36 properties, which also understated the Grand Total. A technically valid response was still a product failure because missing outputs could mislead the implementation team.
I moved bulk parsing and calculations into Python, narrowed AI to ambiguous tasks, added numeric guards, continued past blank rows, and made one result per Cube property an explicit acceptance requirement.
I evaluated correctness, completeness, and usability.
100% of Cube properties receive a result
100% accuracy for deterministic formulas
≥95% field extraction accuracy across supported formats
0 invalid model values written into Excel
Outcome
Product quality depended as much on metric definitions, exception handling, and user independence as it did on model performance. The strongest solution was not the one with the most AI. It was the one that gave the team a dependable result, made mismatches explainable, and fit naturally into how they already worked.
About
Technical enough to build. Curious enough to ask why.
I study Data Science and Business Administration at Northeastern University. My work spans banking, real estate, AI evaluation, and automation, but the thread is consistent: understand the people and decisions behind a process before choosing the technology.
Outside of work, I led a 40-member competitive Bollywood fusion team and previously managed its $16,000 budget, increasing fundraising by 20%.