Show the decisions, not more screenshots
Screenshots show what a product looked like, but not how a PM made the hard calls. Build each portfolio case around the decision, evidence, trade-off and result a reviewer can inspect.
On this page 6 sections
- Start each case with a consequential product decision, not a feature tour.
- Show the evidence available at the time and what it could not tell you.
- Make your contribution and the outcome legible without claiming sole credit.
A portfolio can contain polished screens and still leave a hiring manager unsure how its author thinks. Screenshots prove that an interface existed; they rarely explain why one option was chosen over another. The strongest case study is not a gallery. It is a decision trail that lets a reader follow the reasoning from uncertainty to action.
Choose a decision that had real alternatives#
Start by naming a decision, not the project. “We built an onboarding flow” describes activity. “We chose to let an operator review incomplete applications rather than reject them automatically” gives the reader something to assess.
A useful test: can you name at least two plausible options that were considered? If not, the case may be a feature description rather than a product decision. The alternatives need not be elaborate. They might be ship now versus wait for more evidence, automate versus keep a human checkpoint, or solve the common path versus handle an exception first.
Use a compact opening card:
- Decision: What choice needed to be made?
- Constraint: What made the choice difficult (time, risk, data, dependencies, or user behavior)?
- My role: Which parts did I own, influence, or support?
- Outcome: What changed, and how do I know?
For example, a hypothetical case might say: “We needed to decide whether to launch an automated document check or first improve the manual review queue. I owned the problem framing and workflow proposal; engineering and operations shaped feasibility. The available evidence was a small set of observed review cases, not a representative sample.” That is more informative than a long introduction to the company or product.
Be precise about responsibility. “I led” can mean anything from setting the direction to coordinating a meeting. Name the work: framed the problem, compared options, wrote acceptance criteria, designed the evaluation, or aligned the launch gate. A collaborative result does not become less impressive when the reader can tell who contributed what.
Show what you knew when you chose#
A decision trail is strongest when it separates what was known then from what became clear later. Otherwise, a successful outcome can make an uncertain decision look obvious in retrospect.
Include the evidence that actually informed the choice: user interviews, support themes, workflow observations, a prototype test, operational records, or an evaluation set. State its limits in the same breath. “We reviewed 18 cases” is not a claim about all users; it tells a reader what the sample was. If the evidence was qualitative, say what pattern it suggested and what it could not establish.
A simple evidence block is enough:
| Evidence at the time | What it suggested | What it could not prove |
|---|---|---|
| A handful of observed handoffs | Reviewers repeatedly needed missing context | How often the issue occurred across the full user base |
| A prototype walkthrough | The proposed status labels were understood in that session | Whether users would complete the workflow in production |
| Existing operational notes | Exceptions consumed attention | Whether automation would reduce total work |
Use real details only when you can substantiate them and are permitted to share them. If confidentiality prevents naming a client or showing data, describe the structure of the problem at a safe level. Do not replace missing evidence with an invented metric. A clear limitation is a sign of judgment, not a weakness in the case.
Make the trade-off visible#
The reader needs to see why the chosen option beat the alternatives. Put the options side by side and make the deciding criterion explicit. A paragraph can do this, but a small comparison is often faster to scan:
| Option | Benefit | Cost or risk | Why it did or did not win |
|---|---|---|---|
| Automate the full check | Less manual handling on the common path | Mistakes could reject a valid case | Deferred because the evidence did not cover enough exceptions |
| Add context to manual review | Improves the existing decision step | Keeps a human in the loop | Chosen as a narrower, reversible first move |
This is a hypothetical illustration, not a universal recommendation. In a different setting, the costs may reverse. The point is to expose the criterion: safety, time-to-learn, reversibility, customer effort, or operational capacity.
Also include the cost of the option you chose. Every product decision leaves something undone. If you chose a narrow launch, say what capability remained out of scope. If you chose speed, say which uncertainty you accepted and how you planned to watch it. A case that only lists benefits reads like a pitch; a case that names the compromise reads like product work.
Connect the artifact to the decision#
Screens and diagrams are useful when they answer a question. Show the old and proposed workflow if the decision changed the sequence of work. Annotate the interface where a status, prompt, or fallback embodies the trade-off. Include a short excerpt of a spec or evaluation rubric if that artifact makes the reasoning concrete.
For each visual, add a caption with three parts: what the reader is seeing, what decision it represents, and what changed because of it. Avoid decorative device mockups that enlarge a screenshot without adding context. One annotated diagram can explain more than six screens in a carousel.
When the work cannot be shown, use a redacted or reconstructed artifact and label it honestly. Never imply that synthetic examples are production data. The purpose is to make the decision inspectable while respecting the boundaries around the underlying work.
Close the loop without overclaiming#
End with the outcome and the next decision it enabled. Use a measured result if you have one, along with its denominator and time window. If measurement was unavailable, report the observable operational change and say what remained unmeasured. “The team shipped the workflow” is an output, not proof that the user problem improved.
Separate three things that portfolios often blur:
- Delivery: What was released or changed?
- Effect: What user or business outcome was observed, and by what measure?
- Learning: What would you change now, given what happened or what you later learned?
Do not claim causality from a before-and-after number unless the evidence supports it. If other changes happened at the same time, describe the result as an observed movement, not an effect caused solely by your work. If the launch was too recent to judge, say so and name the signal you would monitor next.
A useful final paragraph is often short: “We released the narrower review aid. It made the missing-context decision visible, but we did not yet have enough evidence to claim that it reduced total handling time. The next decision was whether to expand coverage after observing the exception types.” This gives the reader an outcome, a limit and a credible next step.
Use the same trail in every case#
A portfolio does not need a new storytelling format for every project. Repeating a decision structure helps reviewers compare how you work across different problem spaces. Keep the case concise enough to scan, then provide detail where the evidence or trade-off deserves it.
Before publishing a case, check:
- Is the central decision clear in the first few lines?
- Are at least two plausible options visible?
- Can a reader distinguish my contribution from the team’s work?
- Does each claim match evidence I can share?
- Is the trade-off and the option not chosen explicit?
- Does each screenshot or diagram explain a decision?
- Are delivery, measured effect and learning kept separate?
- Have I removed confidential names, data and identifying details?
If a reviewer can trace what you knew, what you chose, what you gave up and what happened next, the portfolio is doing more than displaying finished work. It is showing how you make decisions when the answer is not yet obvious.