Frequently Asked Questions About Lenaghan Friction-First Productivity System Builder
22 answers covering everything from basics to advanced usage.
// Basics
What does 'systems are designed for someone else' mean?
It means any published productivity system—PARA, GTD, or any app's default structure—was built by its creator to fit their own needs and thinking. When it doesn't work for you, the system isn't broken and neither are you. It simply wasn't designed for how your brain organizes information, which is why customization beats adoption.
What is natural retrieval and why does it matter?
Natural retrieval is when you instinctively navigate to the correct folder or project group without pausing to reason about it. It matters because it's the single success metric for any structural change. If retrieval feels natural, your system matches your mental model; if you still hesitate, the mismatch isn't resolved yet.
What are life silos in this framework?
Life silos are top-level categories that map to distinct domains of life—like personal, business, and family. They're an alternative organizing axis to status-based categories like active versus inactive. Many people think in life silos but use systems organized by status, which creates constant friction when filing items that could belong anywhere.
What is a visual working model of a system?
A visual working model is a diagram—mind map, outliner, or plain-text outline—that shows your current folder hierarchy, tags, and project groups. You keep it live and update it with every tweak. It lets you spot structural problems visually and drag-and-drop test new arrangements before committing them to your actual system.
// How To
How do I audit my current system for friction points?
Recall the last several times you paused while saving a file, searching for one, adding a task, or deciding which project group something belonged to. List each hesitation specifically—the vaguer ones like 'I can't find files I saved last week' still count. The list itself becomes your fix-it roadmap.
How do I identify my true mental model?
For each friction point, ask yourself: 'Where did I expect that thing to live?' The gap between where you expected it and where the system actually put it reveals how your brain naturally organizes. Common patterns: thinking by life silo but using a status-based system, or thinking by topic while your system is organized by time.
How do I make the smallest possible structural change?
State what your current structure expects you to do, state what you naturally expect, then choose the minimal edit that closes the gap—rename a folder, move a category up or down a level, or split or merge two categories. Avoid rebuilding surrounding structure; you only want to resolve this one mismatch and validate it.
How do I decide whether to start from scratch or customize?
If you're unsure, default to customizing your existing system. Starting from scratch works only if you truly have no system—then you create folders and tags only as new items refuse to fit anywhere. Customizing is safer because it preserves what already works and lets you fix mismatches one at a time.
How do I run the natural retrieval test?
After making a change, watch the next several times you need to save or find something in that area. Notice whether you go there instinctively or still pause. If you still hesitate, the change didn't fully resolve the mismatch—return to redesign that spot. If it feels effortless, the change is validated and you move on.
What do I do when I encounter a new productivity method online?
Don't restructure everything based on it. Extract only the specific elements that address a friction point you're currently experiencing, and ignore the rest. This is the no-overhaul rule: chip away at what doesn't work, keep what does. Adopting a whole system because one part sounds appealing is the exact trap this framework exists to break.
// Troubleshooting
I fixed a friction point but still hesitate there—what went wrong?
The change didn't fully resolve the underlying mismatch. Go back and re-examine where you naturally expect that item to live versus what the current structure demands. You may have made a partial fix or misidentified the mental model. Try a different small change, then run the natural retrieval test again on that specific area.
My small change created new friction elsewhere—is that normal?
It can happen, especially if the change was bigger than necessary. Big-bang changes introduce new friction points before old ones are validated as fixed. Prefer the smallest possible edit next time. Treat the new friction as fresh diagnostic data, add it to your list, and resolve it with its own targeted change.
I keep feeling like I'm the problem, not my system—how do I break that?
Reframe every hesitation as a signal, not a failure. The system you're using was designed for someone else's brain, so friction is expected and informative. Instead of blaming yourself, write down what you expected to happen. That expectation is your mental model, and it's exactly the data you need to make the system fit.
I never finish migrating before switching systems again—how do I stop?
Recognize you're working on your system, not in it. Stop the overhaul cycle: take whichever system is most recent and refuse to migrate again. List three specific friction points, fix only those with minimal changes, and commit for two to three months. Resolve new friction incrementally as it appears instead of rebuilding.
// Comparisons
How is friction-first different from just picking a better app?
Switching apps almost always means importing the same mental-model mismatch into a new tool—so the friction returns. Friction-first works at the structure level, not the tool level. It fixes why you hesitate, not where. A well-customized structure in a basic app beats a default structure in a fancier app every time.
How does friction-first compare to a full GTD or PARA setup?
GTD and PARA give you a complete, prescribed structure upfront; friction-first gives you a process for shaping structure to yourself over time. You can start from PARA and customize it—for example, elevating life silos above Projects—but you never adopt the full method just because it's popular. You keep only the parts that solve real friction.
Is friction-first better than a big annual system overhaul?
Yes, for most people. Big-bang overhauls feel decisive but reset everything and introduce new friction before old fixes are validated. Gradual personalization converges on a system that fits your thinking with far less lost work. It also keeps you working in your system continuously instead of taking it offline for a rebuild.
How does this differ from generic 'just be more disciplined' advice?
Generic advice blames you and demands willpower to fight a mismatched system. Friction-first blames the structure and removes the need for willpower by aligning the system with how you already think. When retrieval is natural, you don't need discipline to file correctly—you just do it instinctively, because the structure matches your brain.
// Advanced
How long before my system converges to something that fits?
Expect weeks to months of incremental fixes rather than a single sitting. Each friction point you resolve nudges the system closer to your mental model. The creator recommends committing to one system for at least two to three months so genuine friction has time to surface and be addressed, one small change at a time.
Can I apply friction-first to more than folders and files?
Yes. The same logic applies to tag taxonomies, project group hierarchies, task capture workflows, and even email or reference systems. Anywhere you pause to decide where something goes or where to look, that's a friction point. Map your mental model, make the smallest change, and run the natural retrieval test.
How do I use the visual working model to test changes safely?
Keep a live diagram of your folder hierarchy, tags, and project groups. Before committing a change in your real system, drag-and-drop the new arrangement in the diagram and reason through whether items would now have an obvious home. This catches structural problems visually and lets you iterate cheaply before touching your actual data.
What's the deepest reason friction points matter more than methods?
Because friction points are personalized data about your specific cognition, while methods are generalized guesses about everyone's. A published method can only approximate the average user's brain, but your friction reveals exactly where your brain diverges. Following your friction produces a system no off-the-shelf method could design, because it's built from your own retrieval instincts.