Product, project and program describe different responsibilities

Product management asks what to build and why. Project management organizes a defined delivery. Program management coordinates related work toward a wider objective. Atlassian describes that project/program distinction; BLS lists schedules, budgets and coordination among project-management duties.

For a technical internship, ask which systems and teams are involved. Understanding a dependency does not mean overruling an engineer's design decision. You need enough technical context to explain what one team needs from another and recognize who can decide when they disagree.

Sources[1][2]

Example: finishing one task earlier does not always finish the release earlier

Use the fictional schedule below. Start at day 0. Each task starts as soon as its predecessors finish, durations are fixed and there are enough people to run independent tasks in parallel.

Fictional finish-to-start schedule; days measured from day 0
TaskDurationMust followEarliest finish
A: agree the API contract2NoneDay 2
B: implement the service4ADay 6
C: implement the client3ADay 5
D: integration test2B and CDay 8
E: release review1DDay 9

The release finishes at day 9. The controlling sequence is A–B–D–E: 2 + 4 + 2 + 1 = 9 days. The client sequence A–C–D–E takes 8 days, so shortening C by one day does not change the release date; integration testing still waits for B.

If B takes two extra days, the finish moves to day 11. Shortening D by one day would recover only one day. That calculation is not a reason to remove necessary testing: discuss safe scope or sequencing changes with the responsible engineers.

Ask what must be agreed before a task is really ready

For the API contract, check whether fields, error behavior and version assumptions are agreed by both teams. A document labeled final can still leave the client team without a usable sample response.

Instead of ‘Task A is blocked,’ write: ‘The client cannot handle the proposed error format. The engineering owners need to choose between changing the response and adding a translation layer; the client estimate depends on that choice.’ Name the decision owner and the missing evidence. Do not promise a technical fix on another team's behalf.

When someone adds a feature, show the choices

Suppose a reporting feature is requested midway through the release. Ask what fails without it and which work it affects. The options may be deferring it, delivering a smaller version or moving the date.

Write the requested outcome, affected dependencies and uncertainties for the person authorized to decide. Once decided, update the scope or date. Keeping the old date while quietly dropping required work does not preserve the original commitment.

Bring a schedule and one useful decision note

Recreate the five-task schedule in a spreadsheet, calculate the two-day delay and write a short manager update explaining the decision needed. State the simplified assumptions. Real resource limits or uncertain durations could change the schedule.

Ask the internship manager which dependency, rollout or cross-team process an intern would support, what evidence they maintain and who reviews it. A role centered on meeting notes is different from one where you investigate and resolve a defined handoff. Choose based on that assignment, not the title alone.