How do I show my process when the final deliverable does not reveal how I worked?
Quick answer
Show the deliverable first, then add a short process note that answers three questions: what constraint or goal shaped your approach, what key decision or revision improved the work, and how you checked the result. Include only evidence that helps someone understand or assess the artifact. Label examples as hypothetical if they are not your work, and do not claim checks or outcomes you cannot support.
The question, the details, the next step.
I have a finished piece of work, but it does not show the thinking behind it. What should I add so a manager or reviewer can understand how I approached it?
Keep the finished artifact as the main evidence. Pair it with a short process note, not a diary of every action. A useful note explains the purpose, one or two meaningful decisions, and a check you actually performed. That lets a reader see how the work was shaped without making them reconstruct your whole workday.
Start by asking what the reader needs to assess: your judgment, how you handled a constraint, how you incorporated feedback, or how you checked the result. Choose evidence for that purpose. For example, if the work had a tight word limit, show how you prioritized the essential information and trimmed lower-priority details. Skip steps that do not help explain the choices or the artifact.
How do I choose which parts of my process are worth showing, especially if there were many drafts and small decisions?
Use a simple filter: include a process detail only if it explains a decision, a meaningful change, or a quality check that matters to the finished work. You might mention that you compared two possible structures, revised a section after a reader found it unclear, or checked that the final version covered the agreed requirements. Do not list routine actions just to make the process look longer.
A compact outline can be:
- Goal or constraint: What was the work meant to do, and what limited your options?
- Key choice or revision: What did you decide, and what prompted that choice?
- Check: What did you compare or review before calling it finished?
Be precise about what happened. If feedback was informal, say so; if you did not test the work with an audience, do not imply that you did.
Can you show me what that looks like next to an actual deliverable, rather than as a process outline on its own?
Here is a hypothetical example. Assume the deliverable is a short internal notice about a changed meeting time. The artifact might read:
“Planning meeting: Thursday at 2:00 p.m. in Room B. Please bring your current project update. If you cannot attend, send your update to [team contact] by Thursday morning.”
Place a process note beside or immediately below it:
“Purpose: make the new time and required preparation easy to find. Decision: put the time and location first, then state what attendees should bring. Revision: added an alternative for people who cannot attend after noticing that the first draft only covered attendees. Check: compared the final notice against the three details the organizer asked to include—time, location, and preparation. The example is hypothetical; it does not describe a real project or result.”
The artifact shows what you made; the note shows a few reasons behind its shape. The check should match what you really reviewed. If you only checked the notice against a request, describe that check rather than claiming it was tested for clarity or effectiveness.
What if I want to use this in a portfolio or performance conversation but cannot share the original work?
Use a sanitized or reconstructed example only if you can do so without exposing material you are not authorized to share. Mark it clearly as a summary, excerpt, or illustrative reconstruction; do not present altered content as the original. You can still explain the kind of constraint, decision, and review involved, while replacing names and sensitive specifics with placeholders such as [team] or [project].
Keep the account proportionate: one short paragraph or a few bullets is often enough. If you cannot show the artifact at all, describe its purpose and your contribution, then provide the process evidence you can substantiate. Avoid claiming a result, approval, or impact unless you can accurately support it. A reviewer should be able to distinguish the finished work, your explanation of the process, and any details you have intentionally generalized.
A practical checklist
State the artifact’s purpose and the main constraint that shaped it.
Choose one or two decisions or revisions that help explain the final form.
Name a quality check you actually performed and describe its scope accurately.
Put the finished artifact before or beside the process note so the connection is clear.
Label hypothetical, reconstructed, or generalized material, and use placeholders where needed.
Remove process details that do not help the reader assess the work.
A few more useful answers
How long should the process note be?
Use the shortest note that makes the important decisions and checks understandable. A few focused sentences or bullets can be enough; add detail only when the reader needs it to assess the work.
Should I include mistakes or rejected drafts?
Include one only if it explains a meaningful revision or decision. Summarize what changed and why rather than attaching every draft.
What if I did not keep notes while I was working?
Reconstruct only what you can confidently recall, and distinguish recollection from saved evidence. If you are unsure whether a check happened, leave it out rather than implying that it did.