Why second Notions fail
Your work already has places where the truth lives. Tickets, pull requests, project docs, client folders. A personal wiki built alongside them starts as a good idea and turns into a shelf of outlines nobody opens again, including the person who wrote them.
The failure is not laziness. It is structural, and it happens in three predictable ways.
It competes with the real home. You paste a paragraph into your private notes "for later." The ticket description stops being updated. Now two versions exist, and the stale one is the one you can find fastest.
It creates a retrieval question that did not exist before. Was the billing decision in the ticket, the meeting note, the personal wiki, or a chat thread? Every extra home multiplies that question. A note system earns its place by reducing the number of places worth searching, not by adding attractive ones.
It absorbs the best hour of the day. Designing databases, properties, and tags feels like progress and produces nothing. Setup work is the most convincing form of avoidance available to people who enjoy organising things.
A blunt test: if a note is not attached to a ticket, doc, or PR you will open again this week, it is clutter.
Three homes, and nothing else
1. Scratchpad, for today only
Links, half sentences, commands you ran, the staging URL, a permalink you will need in an hour. It lives in one place: quick notes on the dashboard, or a single daily note. Throwaway by design, cleared weekly.
2. Decisions, next to the project
Only the ones that would be expensive to rediscover. "Monthly billing only for launch." "API v1 stays until September." "Refund copy approved as written."
These go where the work is. A Decision heading in the project doc, a line in the architecture record, or a comment on the issue beats a personal knowledge base every time, because the next person to need it will not have access to yours.
3. Next actions, always
One clear next action per active thread, written where you will see it when you sit down. This is the layer that makes the other two optional (why remote workers need a clear next action).
The filing rule underneath all three is proximity. Put the note where the work it affects already lives:
- A decision about code goes in the issue, the pull request, or the architecture record
- A client approval goes in the shared folder or the project thread
- A meeting action goes in the task system with an owner and a date
- A temporary URL or command stays in today's scratchpad and dies there
Link rather than copy when another system owns the truth, and add one sentence saying why the link matters. Refund copy approved by the client: [proposal section 4] is more useful than four pasted paragraphs that will quietly go out of date while still looking authoritative.
Capture during a focus block is a separate skill with different rules, covered in taking notes during focus work. Mid-block, the goal is speed. Filing happens on the break.
Ten minutes a week, and no longer
Once a week, read the scratchpad from top to bottom. Every surviving line gets exactly one of four outcomes:
- Delete it, because the work is done
- Move it to the project's durable home, if it is a real decision
- Turn it into a clear next action, if it is an unfinished thought
- Keep it one more week, with a reason
Ten minutes is the limit, and it is a diagnostic as much as a deadline. If the review needs an afternoon, the fix is capturing less, not reviewing harder.
Do not spend the review making headings prettier; the goal is removing ambiguity before Monday. And look hard at copied status information. If a ticket has moved on, update the ticket and delete your copy. Private notes should never quietly outrank the place your colleagues actually read.
The same discipline is what makes handoffs short. Notes that stayed close to the work are already most of a handoff (leaving work someone else can pick up), and the end-of-day write-up becomes a summary rather than an archaeology project (end-of-day status update).
When to refuse a new tool
New note tools are easy to justify and hard to abandon. Before adopting one, name the retrieval problem it solves. Real ones exist: onboarding people, passing an audit, maintaining a service for years, coordinating decisions across teams that do not talk daily.
If the answer is closer to "it would be nice to have everything in one place," refuse it. That is a feeling, not a requirement, and the tool will not resolve it.
When a bigger system genuinely is justified, it needs the things that keep documentation alive: named owners, review dates, and links from the places people already open. Documentation with none of those is a graveyard with better typography. Two limits hold regardless of tooling: personal notes stay temporary, and they never hold credentials, contract terms, or customer data that belongs in a controlled system.
The working version of all this is smaller than it sounds. A scratchpad you delete, decisions filed where the project can see them, and one next action per thread. That is a note system. Everything else is a product you have volunteered to maintain.