Write down what you shipped and why
Two months from now you'll look at your project history and wonder what 'fix layout' actually fixed. Release notes are the breadcrumbs that help future-you.
Every time you ship something, write a short note about what changed and why. Not for anyone else. For you, six months from now, trying to figure out when a particular feature was added or when a specific bug was fixed.
Before each release or deploy, summarize: what's new, what's fixed, what changed. Group by type: features, fixes, improvements. Highlight anything that might break existing behavior.
Keep it short. Three bullet points is better than a novel nobody reads. The goal is a breadcrumb trail, not documentation.
Before every production deploy. The act of summarizing what changed is also a pre-deploy sanity check. If something's in the summary that shouldn't be shipping yet, you know to hold the deploy.
Product leader shipping across enterprise SaaS, AI in production, and 0→1. Writing about what actually ships — not what sounds good in a deck.