An AI PM portfolio should let a reviewer inspect a decision you made. Choose one project, explain the user problem and show the evidence behind a consequential trade-off. A working demo helps when it exposes that decision. It proves much less when the inputs were selected to make the model look good.
Start with an honest scope statement: a shipped feature, an internal pilot, a research collaboration or a personal prototype. Then name your responsibility. Someone should be able to distinguish what you decided from what the designer, engineers or research team contributed.
Atlassian's official PM interview handbook, checked on 22 October 2026, emphasizes explaining outcomes and working with others. It supports preparing evidence of those skills. It does not establish a universal AI PM portfolio format. The worksheet below is our original preparation method; confirm the actual interview instructions with your recruiter.
Audit the claims before choosing the slides
Write the strongest sentence you intend to say about the project. It might be "the assistant saved users time" or "we improved the model by collecting better data." Underline each part that needs evidence.
Use this worksheet on your own project:
| Claim to inspect | Evidence to bring | Boundary to state |
|---|---|---|
| Users had this problem | Interview notes, workflow observations or support evidence | Who you observed and who was absent |
| I owned this decision | A permitted decision record or a clearly labelled reconstruction | What your partners decided |
| This design helped | The prior flow, the changed interaction and an observed task | Whether a study or production use established the result |
| Quality improved | Case definitions, sample selection and failures from both versions | What the evaluation did not cover |
| The product created value | A metric definition and baseline with the measurement period | Observation, projection or causal estimate |
| I learned something | A decision you subsequently changed | What remains unresolved |
The last column often improves the story most. A precise limitation makes the evidence usable. Without it, a reviewer has to discover the boundary by challenging you.
Make collaboration visible in the artifact
An annotated product flow can explain a disagreement better than a slide saying you worked cross-functionally. Show where the designer wanted fewer steps, where the research team warned about uncertainty and where engineering identified a dependency. Explain what you accepted, what you challenged and why the final scope changed.
Use verbs that match your contribution. You might have proposed the launch threshold, negotiated a smaller rollout or changed the review workflow after observing users. Claiming that you built every part makes it harder to see those decisions.
If the interface changed, show the error it was meant to prevent. A confirmation button is not evidence that users detected mistakes. A study in which reviewers inspected deliberately incorrect outputs is more informative, provided you explain how the examples and participants were selected.
Separate a demo from a result
For a model-backed feature, show at least one failure that changed your plan. Preserve the input conditions and describe whether the cause was retrieval, permissions, model behavior or the surrounding workflow. Keep confidential data out of the presentation.
Then define the unit being measured. A field can be extracted correctly while attached to the wrong row. A tool can return successfully without accomplishing the user's task. The document-workflow exercise lets you practise explaining this distinction before applying it to your own project.
If a measured task takes less time, distinguish that observation from a business projection. State whether you counted review, retries and delayed corrections. A capacity estimate does not demonstrate that the team reduced spending or delivered more customer value.
Explain what you would buy or build next
A retrospective becomes more useful when it leads to a current decision. Identify the remaining failure and the evidence needed to justify the next investment. Avoid ending with "we would collect more data" without saying what the data must teach.
The data-acquisition exercise asks you to choose among demonstrations, preference labels and execution feedback under a fixed budget. Use the same discipline in your portfolio: explain the bottleneck and what would make you stop spending. A cheaper label is not automatically a better investment.
Rehearse the objection you least want to hear
Ask a partner to challenge your attribution, your metric or your design. Keep your first answer short enough that they can interrupt with a real question. If the challenge exposes a gap, revise the claim; do not invent evidence to rescue it.
For private projects, a reconstructed artifact can explain the reasoning. Label it as reconstructed, use synthetic content and state which original evidence cannot be shared. For personal prototypes, name the actual study or test. Neither requires pretending that production customers existed.
Open the portfolio practice workspace and write your decision, evidence and reversal condition before comparing the reference answer. The draft stays in your current browser tab. The reference retains its normal membership access, and the rubric is our teaching guide, not an employer scorecard.
Questions about this topic
A prototype can demonstrate problem selection, evaluation and iteration. State its scope and actual users. Do not describe a rehearsal, personal project or small usability study as production adoption.