Builder-PM working on AI-first products — discovery and PRDs through hands-on development, then instrumentation of what users actually did.
Final-year Computer Science student, graduating August 2026. I’ve led a 10-person build, delivered a marketplace for a paying client as sole developer, and shipped a platform that processed 4,000+ submissions in live use. Currently interning at Docmize on an AI hospital management system while building CuteHelper, a voice-first AI desktop companion.
Availability
Open to Associate and Technical Product Management roles · Gurugram, India · IST (GMT+5:30)
Product
Build
AI
Data
01 · Now
All three are live right now — a team codebase, a client product built and handed over, and one of my own in active development.
Software Developer Intern
Frontend interfaces and dashboards for an AI-integrated hospital management system, working inside an existing engineering team and codebase.
Freelance Product Developer
Sole developer on a paid client engagement — a two-sided services marketplace, built and handed over.
Founder & Product Engineer
Voice-first AI desktop companion, instrumented to test whether its core loop actually works.
Each of those has a full write-up below — the problem, the calls I made, and what the numbers said afterwards.
02 · Work
Each write-up covers the same ground: what the problem was, how I scoped it, what I built, what broke, and what I’d do differently. Ordered by what I think is hardest to fake.
Founder & Product EngineerAI Desktop Companion
A transparent, always-on-top AI companion that listens instead of waiting to be typed at. RICE-scoped to two workflows, built front to back, instrumented to test whether it teaches or just answers.
Voice input
Groq Whisper
On-screen context
LLaMA 4 Scout
Response surface
Product ManagerInstitutional Complaint & Document Management Platform
Led a 10-person team building an AI-assisted complaint and document management platform. 4,000+ submissions processed in live use, three user roles reconciled, resolution time cut 30% in load testing.
Freelance Product DeveloperServices Marketplace
Sole developer on a paid engagement. Requirements elicited from the client, MVP scoped against a fixed budget, one role-based application serving two distinct experiences plus an admin panel.
Shared authentication
Role-based routing
Customer marketplace
Provider experience
Admin panel
Software Developer InternAI Hospital Management System
Frontend interfaces and dashboards for an AI-integrated hospital management system covering appointments and patient workflows, built inside an existing team and codebase.
Screens pending client clearance
Also published
Two end-to-end case studies, written up and published. Different muscle from the builds: no code to hide behind, just the argument.
The case studies above are products I built or helped build. These two are products I analysed — the discipline of taking something already in the world and reasoning about what should happen to it next, without the safety net of being able to just go build it.
Building a product you specced yourself is a closed loop — if the analysis is wrong, you find out in the build and quietly fix both. Analysing a product you don’t own removes that. The reasoning has to stand up on its own, in writing, to a reader who can check it.
Both of these run the full arc: what the problem actually is, what users said, how large the opportunity is, who else is solving it, and what I’d build first. The prioritization section is the one I’d point an interviewer at.
Methods
Published
End-to-end analyses covering problem discovery, user research, opportunity sizing, competitive analysis and feature prioritization. Written alongside final-year coursework and the product management certifications.
What each write-up covers
Problem discovery
Establishes the problem exists and is worth solving, before proposing anything
User research
Grounds the problem in what users said, not what seemed likely
Opportunity sizing
Puts a magnitude on it — the difference between a real problem and an interesting one
Competitive analysis
Who’s already solving this, how, and where the gap is
Feature prioritization
What ships first, and the reasoning that makes that defensible
03 · Method
Five steps, in the order I actually run them. Each example below is from a real build, not an illustration.
Find out what has to become true, not what features were asked for. On ServiceHub I elicited requirements directly from the client — which is what surfaced the operational needs that became a separate admin panel.
Decide what doesn’t ship. On CuteHelper I ran a RICE framework across the candidate feature set and cut the MVP to the two highest-impact workflows. Prioritization only means something when it removes things.
Write it down so it can be disagreed with. PRD, user stories, acceptance criteria, system architecture. On UrbanIQ that meant reconciling three user roles — requester, handler, administrator — into 15+ prioritized stories where “done” meant the same thing to all three.
Ship it myself where I can. React, Next.js, TypeScript, Electron, Supabase, Prisma. On ServiceHub, one role-based application served two distinct experiences instead of two parallel codebases — a decision I could only make because I was the one maintaining it.
Find out whether the spec was right. On UrbanIQ I ran EDA on 4,000+ submissions and fed SLA-breach patterns back into prioritization. On CuteHelper I’m tracking follow-up rate, average query length and response gap. A roadmap that never changes after launch wasn’t a roadmap.
The loop matters more than any single step. Step 05 is what makes step 02 honest next time.
04 · Toolkit
Every item below appears in work I’ve done. Hover a skill to highlight where it was used.
Opportunity Sizing and Competitive Analysis belong to the published case studies too — they’re in the product analysis method list rather than repeated here.
Product Discovery
User Research
PRD Authoring
User Stories & Acceptance Criteria
Feature Prioritization (RICE)
Roadmapping
MVP Definition
Stakeholder & Client Management
KPI Definition
Agile & Scrum
Opportunity Sizing and Competitive Analysis belong to the published case studies too — they’re in the product analysis method list rather than repeated here.
LLM Integration
AI Workflow Design
Prompt Engineering
Voice Interfaces
Context-Aware Systems
Electron
React
TypeScript
Next.js
JavaScript
Python
Supabase
Prisma
REST APIs
Git
CH CuteHelper · UIQ UrbanIQ · SH ServiceHub · DZ Docmize · CS Published case studies
The empty cells are the point — they’re what makes the filled ones mean something.
Used in shipped work
Working knowledge — coursework and certification
The list is short on purpose. Nothing on it is here because it looks good on a list.
About
The pattern is consistent across everything I’ve built: run the discovery, write the PRD, decide what doesn’t ship, build it, deploy it, then instrument it to find out whether the spec was right. On UrbanIQ that meant leading ten people and reconciling three user roles with different definitions of “resolved.” On ServiceHub it meant negotiating scope directly with a client against a fixed budget. On CuteHelper it means owning every layer, from the RICE score that killed features to the Electron main process.
I’m not a PM who can read code, and I’m not an engineer who writes tickets. I do both, and the reason I keep doing both is that the specs get better when you know what they cost to build.
Journey
UrbanIQ was ten people and three user roles that disagreed about what a resolved complaint looked like. I learned that the hard part of product isn’t deciding what to build — it’s getting three groups to accept the same definition of done. It shipped, and it processed 4,000+ submissions in live use.
After launch I ran exploratory analysis on all 4,000+ submissions in Python and Metabase. SLA breaches clustered by department in a way nobody had predicted. That’s when instrumentation stopped being a checkbox on the roadmap and became the reason I trust or distrust my own specs.
A year of deliberate practice alongside coursework: two published end-to-end case studies covering problem discovery, user research, opportunity sizing, competitive analysis and prioritization, done alongside the product management certifications. Writing product thinking down for an audience is a different skill from doing it.
Now: a client product where I’m the only developer and the requirements come straight from the person paying, a team codebase at Docmize where I have to fit someone else’s architecture, and CuteHelper, where every decision is mine and every mistake is too.
Current focus
What I’m working on right now: whether CuteHelper’s “teach, don’t do” principle survives contact with real users. I’m instrumenting follow-up rate, average query length and response gap to find where the loop breaks down — because a companion that answers for you and a companion that teaches you look identical in a demo and completely different in the data.
What I’m getting better at: working inside an existing codebase and someone else’s architectural decisions. Docmize is the first environment where I’m not the one who chose the structure, and it’s made me a better spec writer — a requirement reads differently when you know what it costs the person implementing it.
What I’m looking for: an Associate or Technical Product Management role on a product where the technical layer is the product, not a delivery detail. AI products, developer tools, or anything where the spec has to be written by someone who understands what the model can and can’t do.
Based in Gurugram, Haryana. Graduating August 2026.
05 · Background
The formal version, for anyone who needs it in this shape.
AI Hospital Management System
Services Marketplace
AI Desktop Companion
Institutional Complaint & Document Management Platform
Education
I.K. Gujral Punjab Technical University
Expected August 2026
Final year. The coursework has run alongside the builds rather than behind them — UrbanIQ and the published case studies were both done during it.
Certifications
Achievements
Drawn from the shipped work — no separate awards to list.
submissions processed in live use
UrbanIQ went into real institutional use, not a demo
resolution-time reduction in load testing
Achieved by reordering the approval workflow, not by adding features
client engagement delivered solo
ServiceHub — requirements through handover, inside a fixed budget
10-person team led
UrbanIQ, as a student, alongside final-year coursework
user roles reconciled into 15+ prioritized stories
With acceptance criteria precise enough to build against
product case studies published
End-to-end, independently, alongside final-year coursework
Leadership
I led a 10-person team as a student. In that setting alignment comes from documents precise enough to be self-executing: a PRD, 15+ prioritized user stories, and acceptance criteria reconciled across requester, handler and administrator. That constraint is the reason I write specs the way I do.
Sole developer on a paid engagement means being the person who says “that costs this much of that.” I ran the requirements conversation and the trade-off negotiation directly, in terms the client could make decisions in.
Founding something removes the person who tells you a feature isn’t worth it. RICE and the instrumentation plan exist because I needed an external check on my own judgment.
06 · Contact
I’m looking for an Associate or Technical Product Management role, ideally somewhere the technical layer is the product rather than a delivery detail.
If you’re hiring for something like that — or you want to argue with a decision in one of the case studies above — email is the fastest way to reach me.
Direct