Several replies to my last post made me rethink how much needs to be connected. A project log can be enough. A task with a link to the folder can be enough too. Not every file needs a project built around it.
That leaves a more specific case I’d like to understand: the plan and the files are already linked, and you know the next action. How do you use the relevant part of that plan once you start working on the files?
Say you’re updating a report or presentation. The draft, spreadsheet, and reference PDFs are in a folder. The feedback from the last discussion is in a project note in Notion or Apple Notes. Your task manager says to update the presentation, with a link to the folder.
The link gets you to the files. While editing, though, you may need to check which section the feedback refers to, what was agreed, or which figures need updating. You need a few details from the note, rather than the whole history of the project.
If those details are already attached to the task, that may be all you need. A ReadMe might work just as well. I’m interested in the cases where the information is still being updated in another app, and in how people keep the useful part at hand. Keeping the note open beside the document or putting a short instruction in the task are two ways of doing that.
If you use AI for part of the work, there’s a similar choice about which files and notes to include in the request. But this is also a question about working on the files yourself, without AI.
I don’t want to assume another app or another copy of the notes would improve this. The approaches people described already work for many of them. I’d like to understand what makes the handoff from planning to doing work well.
When a project’s plan lives in a note or task manager, how do you keep the relevant instructions at hand while working on its files?
I think you may be spending more time designing the handoff between planning and doing than the handoff actually warrants. Once you know what needs to be done and where the relevant information lives, start working. Keep the project note open if you need it, and refer to it as necessary. There’s no need to anticipate and solve every possible interruption to your workflow. A good system should make the work easier, not become another project in itself.
The glue between project data / notes and the final artifact is experience. Skill develops only from repeatedly, successfully completing the tasks at hand, not from fiddling with notes and wondering what to do next.
Just do it – make the report, then go back over your notes and make any edits.
I agree completely. Know where your information lives (the fewer drawers, the better), grab what you need, and start working.
I have two primary drawers for material: DT for research and Apple Notes for everything else, including project notes. While I occasionally grab something from Google Drive, linking to it isn’t necessary. Aside from internal links within Apple Notes, links are just one more thing to manage, a lesson I learned after trying for too long to connect Mail and Reminders.
My app setup is equally streamlined. I use only three writing apps: Ulysses for my book, iA Writer for my blog, and Pages for formal documents. If absolutely necessary, I can export to Word, but otherwise, everything goes out as a PDF. Once the book is complete, I’ll drop Ulysses entirely. Beyond that, I use one mail app (Mail), one task manager (Reminders), and one outliner (OmniOutliner).
This setup covers 99% of my work. I’ve substantially cut down on slides, and my use of Keynote, relying instead on strong verbal presentations. If I do use slides, it’s rarely more than two or three. I also use Excel strictly for reading spreadsheets rather than managing them. I have that luxury given my role.
Ultimately, I’m suggesting we simplify the management overhead of our work to focus on the work itself. I’ve made the mistake of doing just the opposite in the past. Now, I am making a concerted effort to focus on the output, not the workflow and tools. I’m even striving to reduce my device count from three to two. Less syncing, less updating, less cost.
Duplicate the project folder. Date stamp the copy. Put it in a (date stamped) ZIP archive.
State an aim for the revision sprint. List the key objectives. Put these notes in a date stamped file in the project folder or in a common revision-management app.
All planning is completed.
Now safely do your work on the required/desired revisions, entirely relieved that if you mess up something, you have a recovery path.