PM interview field notes · 5 minute read

Explain your contribution without taking credit for the team

Product work is collaborative. An interview answer needs to show your contribution clearly while giving other people their credit. You can do both by separating the team's result from the decisions and actions you personally owned.

Give the team context, then make your role visible

Begin with a short description of the product problem and your role at the time. State the boundary of your responsibility: discovery, backlog ordering, stakeholder alignment, delivery coordination or another area you actually owned. A title alone does not establish decision authority.

Use 'we' for the shared goal and result. Use 'I' for a decision, analysis or action you can describe in detail. Move between the two deliberately. An answer consisting entirely of 'we' hides your contribution; an answer consisting entirely of 'I' can erase the people who designed, built and operated the product.

Map ownership before writing the story

Make a simple three-column record: what I owned, what we did together and what others owned. For each personal item, add a concrete verb and the evidence behind it. 'Led the project' is broad. 'Compared the two sequencing options, documented the trade-off and obtained a decision from the sponsor' explains the work.

Be precise about recommendations versus authority. If you recommended the scope and the sponsor approved it, say that. If engineering selected the implementation, do not describe it as your technical decision. Clear boundaries make follow-up questions easier to answer.

  • My responsibility: what I was accountable for and which decisions I could make.
  • My actions: what I analysed, decided, created, negotiated or changed.
  • Shared work: where another person's expertise or agreement was essential.
  • Team outcome: what happened and what evidence supports it.

Describe the decision, not just the meeting

Fictional example — 'I ran stakeholder workshops and managed the backlog' tells the interviewer that activities happened. It does not reveal your judgement.

A stronger account might be: 'Support wanted broader coverage while engineering identified a dependency that put the date at risk. I compared a narrow release with waiting for the dependency, documented the users each option would leave unsupported and recommended the narrow release. The sponsor approved that scope. Design and engineering developed the solution; I maintained the acceptance criteria and coordinated the decision about the deferred cases.'

This example is deliberately limited. It names the contributor's recommendation, the approving authority and the team's work. Add the real outcome and its evidence from your own experience; do not borrow the fictional scenario as personal history.

Check whether your claim survives a follow-up

For each use of 'I', ask what an interviewer could reasonably ask next. Which alternatives did you consider? What information changed your view? Who disagreed? What happened because of your action? If the answer belongs to a colleague, revise the ownership wording.

For each use of 'we', ask whether you have explained your contribution to that part of the work. You do not need to force personal credit into every step. You do need enough detail for the interviewer to understand your judgement, responsibility and collaboration.

Try this with your experience

A practical next step

Take an existing interview answer and highlight every 'I' and 'we'. Beside each 'I', write the action and evidence. Beside each 'we', name the relevant collaborators. Rewrite one vague ownership claim with a specific decision and its boundary.

Build one story in your browser →