An AI study-group matcher — PRD and working prototype
Coursework · Product Management & Agentic AI, Vishlesan i-HUB IIT Patna · Feb 2026
Read this as a specification exercise, not a product outcome. The persona is constructed, there are no real users, and the KPIs below are launch targets I set, not results I achieved. What it demonstrates is how I write a spec.
Project
Campus Connect
Role
Learner
The problem
University students coordinate academic and social life across WhatsApp, Telegram,
Discord and physical noticeboards. The information is fragmented and noisy, forming
a balanced study group is manual work, and the result is missed opportunities and
avoidable academic stress.
Scoping the MVP
The temptation with a campus platform is to build the platform — events, resources, groups, chat, all of it. I cut the MVP to one thing: AI-assisted study-group matching, on three inputs (course interest, study style, weekly availability), producing three suggested groups with a reshuffle option.
Two scoping decisions I’d defend:
- No in-app chat: Groups hand off to WhatsApp, Telegram or Discord via invite link. Building chat would have consumed the entire MVP budget to compete with tools students already have open. The product’s value is the match, not the messaging — so the MVP proves the match and borrows the messaging.
- Rule-based matching before ML: The MVP matches on rules, with lightweight ML on the future roadmap. You can’t train a matching model without match-outcome data, and you can’t get match-outcome data without shipping matches. Rules first is the only sequence that works.
The user story I'd point to
Most of the user stories are standard onboarding and matching flows. This one isn’t:
As a female student, I want to see a verified badge on group members’ profiles so that I feel safe before connecting with strangers. A product that matches students into small groups and then sends them to a private WhatsApp chat is a stranger-introduction product, and the safety risk in that is not distributed evenly. Specifying college-email verification and a visible verified badge — before the join action, on the group detail screen — is the difference between a matching feature and a matching feature someone will actually use. I’d go further now than I did then: verification is a floor, not a solution. A production version needs reporting, group-leave, and a way to flag a member — and I’d want those specced before launch, not after an incident.
The feedback loop
After a week in a group, students get a three-option prompt — Good match / It’s OK / Not great — with a skip. Deliberately three options and one tap, because a matching system has no way to improve without outcome labels, and a long survey collects nothing. This is the mechanism that eventually makes ML matching possible.
Launch targets
Set as pilot-campus targets, framed against AARRR. Stated here as what I’d measure, not what was achieved:
- Acquisition — 100+ students complete onboarding.
- Activation — 60%+ of onboarded students join a group.
- Retention — 30%+ return to the dashboard within 48 hours.
- Referral — 10 students joining via shared links.
- Revenue — No monetisation in the MVP; the goal is problem-solution fit
Activation is the honest north star here. Onboarding numbers measure the pitch; join rate measures whether the matching is any good. If 100 students onboard and 20 join a group, the product doesn’t work regardless of how good acquisition looks.
What this exercise didn't include
- No real discovery. The persona is constructed from assumption, not interviews. In a real version this spec would come after talking to students, and the matching inputs would likely change.
- No validation of the matching logic. Course, study style and availability are reasonable guesses at what makes a study group work. They’re untested guesses.
- The prototype is a flow demonstration, not a working matcher — it shows the experience, not the algorithm.