Hindu College, University of Delhi: Product Management Internship Tasks from Research to Roadmaps

A product management internship at student level comes down to three tasks: finding out what users need (research), ordering the work (backlog grooming) and explaining what comes next and why (roadmap drafting). Each task leaves behind an artefact, and each artefact can support one honest resume bullet. This guide gives Hindu College, University of Delhi students a task-to-evidence map for turning short internship work into bullets a recruiter can verify.

What this guide covers, and what it does not

This is an independent guide written for students of Hindu College. It is not issued, approved or endorsed by the college or the university. The institution-specific part is deliberately narrow: rules on internships, credits, and which cells or societies can support you differ by programme and year, so they are handled through a verification list near the end rather than through assumptions.

Everything else is practical. You get a map from task to evidence to resume bullet, a scorecard for judging your own bullets, a worked illustrative example, templates for the three core artefacts, and FAQs.

What a student product management internship usually looks like

Real product managers decide what a team builds. A student intern almost never owns that decision. What you can do is the thinking that sits underneath it. That is why project-based, short internships are common entry points: they let you practise the method on a bounded problem.

A typical short internship in this domain involves:

• Choosing or being given a product (an app, a campus service, a website, a feature).
• Talking to a handful of users, or analysing existing feedback.
• Converting findings into a list of problems and then into backlog items.
• Ranking those items with a stated method.
• Drafting a roadmap for a short horizon and presenting it.

If you are looking for a free way to practise exactly this sequence, the free two-week online internship from CareerSwami has 26 tracks, a free offer letter, and a free completion certificate after successful completion. The certificate confirms completion. It does not stand in for the evidence described below, which is what makes a bullet credible.

The task-to-evidence map

The rule behind this map is simple: a resume bullet is only as strong as the artefact you can show behind it. Before you write any bullet, name the file, link or document that proves it.

Stage 1: User research

What to do

Start with a research question, not with a feature idea. “Why do first-year students stop using the library booking page after one try?” is a research question. “Add a dark mode” is a solution wearing a question’s clothes.

1. Write one research question and two or three things you want to learn.
2. Recruit five to eight people who fit the user group. For a student product, classmates in other courses are a reasonable start, though you should note that they are a convenience sample.
3. Prepare open questions about past behaviour (“Tell me about the last time you…”) instead of opinions about the future (“Would you use…”).
4. Take notes in a sheet with columns for participant, quote, observation and theme.
5. Group notes into themes and count how many participants raised each.

Evidence to keep

• The interview guide.
• An anonymised notes sheet. Remove names, and ask permission before recording or quoting anyone.
• A one-page summary of themes with counts.

Common mistakes

• Asking leading questions that make users agree with you.
• Treating five interviews as statistically representative. Say “among eight participants”, not “users prefer”.
• Skipping the summary. Raw notes alone are not evidence of synthesis.

Stage 2: Backlog grooming

A backlog is the list of work items for a product. Grooming (also called refinement) means keeping it clear, deduplicated, sized and ordered. This is where research turns into decisions.

A simple grooming routine

1. List every problem or idea from your research as a candidate item.
2. Merge duplicates and split anything that bundles several changes.
3. Rewrite each as a user story: “As a [user], I want [action] so that [outcome].”
4. Add two or three acceptance criteria per story, written so that someone could check them.
5. Score and rank using one stated method.

Choosing a scoring method

RICE (Reach, Impact, Confidence, Effort) and ICE (Impact, Confidence, Ease) are widely used. MoSCoW (Must, Should, Could, Won’t) is simpler when you have no numbers. Pick one and say why. For a student project, effort and reach are estimates, so label them as estimates in the sheet.

Illustrative figures only. The RICE score is Reach × Impact × Confidence ÷ Effort, and all numbers above are invented to show the arithmetic.

Evidence to keep

• A before-and-after view of the backlog (for example, 30 raw items reduced to 14 groomed stories). Record the real counts from your own work.
• The scoring sheet with your assumptions written beside each number.
• Three fully written stories with acceptance criteria.

Stage 3: Roadmap drafting

A roadmap is a statement of direction, not a delivery contract. For a student project, a Now/Next/Later format is honest and easy to defend because it avoids false date precision.

Roadmap template

Product goal: [one sentence]
Primary metric: [name, definition, current baseline if known]
Guardrail metric: [something that must not get worse]

NOW (next 2-4 weeks)
- Item | Problem it solves | Evidence (interview theme or data) | Risk

NEXT (1-2 months)
- Item | Problem it solves | Evidence | Dependency

LATER (not committed)
- Item | Reason it is parked | What would change our mind

The “Evidence” column matters most. Every item should trace back to a theme from Stage 1, which is what separates a roadmap from a wish list.

Evidence to keep

• The roadmap document itself.
• A short rationale explaining why the top item outranked the second.
• Any feedback you received on it and what you changed.

Worked illustrative example

Scenario (illustrative, not a real project): A student works on a hypothetical campus event-discovery app. The assignment is to recommend what to build next.

1. Research. The student interviews eight students. Five say they learn about events only through WhatsApp forwards and often miss them. Three say they do not know which events suit first-years. Notes are tagged “discovery” and “relevance”.
2. Framing. Problem statement: “Students miss relevant events because information reaches them late and unfiltered.”
3. Backlog. The student turns 22 raw ideas into 11 stories after merging duplicates. One story reads: “As a first-year student, I want to filter events by year and interest so that I only see events I can attend.” Acceptance criteria: filters appear on the home screen; results update without a page reload; an empty result shows a clear message.
4. Prioritisation. RICE scoring ranks the filter story first, with reminders second.
5. Roadmap. NOW: filters. NEXT: reminders. LATER: personalised recommendations, parked because there is no usage data yet.
6. Metric. Primary: share of sessions that end with an event saved. Guardrail: time to first result.

From this, a student could write the bullets below, provided the numbers match their own real files:

• Interviewed 8 students and synthesised notes into two themes (late discovery, low relevance) that shaped the product problem statement.
• Reduced a 22-item idea list to 11 user stories with acceptance criteria and ranked them using RICE.
• Drafted a Now/Next/Later roadmap with a primary metric and a guardrail metric, and presented it for feedback.

Notice what is missing: no claim that the filters improved engagement, because nothing was shipped or measured. Proposed and defined are honest verbs here. “Increased” is not.

Bullet scorecard

Score each draft bullet against these six checks. A bullet that fails the first two should be rewritten or removed.

Weak versus strong, side by side (illustrative)

• Weak: “Worked on product strategy and user research.”
  Stronger: “Ran 6 user interviews and grouped findings into 3 themes used to rank a 12-story backlog.”
• Weak: “Improved user experience by 40%.”
  Stronger: “Proposed a checkout simplification and defined completion rate as its success metric.”
• Weak: “Managed a roadmap.”
  Stronger: “Drafted a three-horizon roadmap and documented why the top item outranked two alternatives.”

Templates you can copy

Interview guide skeleton

1. Warm-up: role, how they currently solve the problem.
2. Recent behaviour: “Walk me through the last time you…”
3. Pain points: “What was hardest about that?”
4. Workarounds: “What did you do instead?”
5. Close: “Is there anything I should have asked?”

User story card

Title:
As a [user type], I want [action] so that [outcome].
Evidence: [interview theme / data point]
Acceptance criteria:
1.
2.
3.
Out of scope:
Metric affected:

One-page decision brief

• Problem and who has it.
• Evidence in three bullets.
• Options considered, with a line on each.
• Recommendation and why.
• Risks and what you would measure.

Hindu College and a product management internship: what to check before the resume line

Hindu College is described by a third-party listing as a constituent college of Delhi University offering undergraduate and postgraduate programmes. In practice, a student doing a product management internship should expect that rules on internships, credits and permissions may sit at the university level, the college level, or both. Which applies to a given course and year has to be confirmed in writing before any work is described as academic.

The same listing mentions a placement cell called Disha that links students and recruiters. This comes from a third-party page, not an official one, so treat the name as a lead rather than a fact. If the cell exists, it is the natural first contact for questions such as whether an unpaid or remote product internship needs any vetting, and what a verification letter should look like.

No official internship or credit rules for Hindu College were confirmed, so the article’s three artefacts (an interview guide with synthesis, a scored backlog, and a draft roadmap) are best presented as practical work evidence. Describe them as exactly what they are: a self-directed project, an external internship, or a society proposal. Do not label them as college-credited unless the department confirms it in writing.

Because course mixes differ, choose the stage that matches your coursework. Students with survey or statistics exposure can lead with research and metric definition, while those with programming exposure can lead with acceptance criteria in backlog work.

Questions to settle in writing before listing product work

• Ask your department office whether an internship or project component exists in your scheme this year, and request the scheme or regulation year it falls under.
• Email the teacher-in-charge to ask whether an external or online product internship can count for credit, and what documents (offer letter, completion certificate, supervisor report) are required.
• Find the placement cell’s contact on the official college website or notice board, and ask whether Disha, or any equivalent cell, reviews internships and issues letters.
• Ask the relevant society convenor whether projects are open to first-years, and get permission before interviewing members or proposing changes to society processes.
• Check whether permission is needed to intern during term time, and get the answer by email.
• Confirm who may approve any document that uses the college name or logo before it goes into a portfolio page.

A 14-day plan to produce all three artefacts

Turning the work into a portfolio page

A short public or shareable page often does more than a resume line. Include the problem statement, a redacted notes summary, the scored backlog, the roadmap and a short reflection on what you would do differently. Remove any personal data of interviewees. If the product belongs to someone else, get their permission before publishing any internal details.

A reflection paragraph is valuable because it shows judgement. Examples of honest reflections: your sample was too narrow, you estimated effort without engineering input, or your top-ranked item depended on an assumption you could not test.

Questions interviewers may ask about these bullets

• How did you choose your interviewees, and what bias does that create?
• Why did you rank this item above that one?
• What would make you change the order?
• Which metric would you watch first, and what would a bad result look like?
• What did you decide not to build, and why?

Prepare a two-sentence answer for each. If you cannot answer, the bullet needs rewording.

Frequently Asked Questions

Do I need coding skills for a product management internship?

Not for entry-level project work. You need to write clear stories, read simple data and talk with engineers sensibly. Basic spreadsheet skills matter more than code at this stage.

Can a two-week product management internship go on my resume if I can show a research summary, scored backlog and roadmap draft?

Yes, if you state its real length and the real tasks. Describe the artefacts you produced and avoid implying a full-time role. A completion certificate confirms you finished the programme, and your artefacts show what you can do.

How many users should I interview?

For a short project, five to eight is a workable range for spotting repeated themes. Report the number honestly and avoid generalising to all users.

Which prioritisation method should I use?

Use RICE or ICE when you can estimate numbers, and MoSCoW when you cannot. What matters is that you state the method, show the inputs and explain any override.

What if I have no real product to work on?

Choose a product you can observe: a campus service, a society process or a public app. Label the work as a case study or proposal. Hiring teams read labelled case work more favourably than inflated claims.

Should I put metrics on my bullets if nothing was launched?

Use counts of what you did (interviews, stories, criteria) and use “proposed” or “defined” for outcomes. Never invent percentage improvements.

Will this internship give me academic credit at Hindu College?

That depends on your programme’s rules and on whether your department accepts it. Ask in writing and keep the reply; the verification list above shows what to ask.

What is the difference between a backlog and a roadmap?

A backlog is the detailed, ordered list of work items. A roadmap is the higher-level plan showing direction and sequencing, with reasons. The roadmap should be traceable back to backlog items and research themes.

Related Product Management guides

• Lady Shri Ram College for Women Students: Product Management Internship Report Structure and Evidence
• Miranda House Students: Product Management vs Product Analyst Internships, Compared
• Product Management Internship Guide for University of Delhi Students: Skills and Case Preparation
• All Product Management internship guides