terminalskills Productivity Mental Models
Overview
Productivity isn't about working more hours. It's about removing the friction between knowing what to do and actually doing it. The Personal MBA identifies several mental models that explain why smart people fail to execute — and how to fix it.
This skill covers the most actionable productivity frameworks: overcoming akrasia, achieving monoidealism, reducing cognitive switching costs, identifying your Most Important Tasks, and using the 5-Fold Why/How to drill into problems and solutions.
Instructions
When a user asks about productivity improvement, time management, focus, or root cause analysis, apply these mental models.
Model 1: Akrasia — The Knowing-Doing Gap
Definition: Akrasia is the state of acting against your better judgment. You KNOW you should write that proposal, but you're scrolling Twitter instead.
Akrasia isn't laziness. It's a failure of the system around you. Your environment is optimized for distraction, not execution.
Fixes (environment design, not willpower):
- Remove friction from good behavior — Keep your IDE open, close Slack, block social media during work blocks
- Add friction to bad behavior — Use website blockers, put phone in another room, log out of distracting sites
- Pre-commit — Schedule work blocks on your calendar. Tell someone what you'll deliver by when.
- Reduce decision fatigue — Decide the night before what you'll work on tomorrow. Morning decisions = depleted willpower.
- Start pathetically small — "Write one sentence" is easier to start than "write the proposal." Starting is 90% of the battle.
Example: Developer who can't start a difficult refactoring task:
- Bad: "I'll work on the refactor today" (vague, easy to postpone)
- Good: "At 9:00 AM, I'll open
auth.ts, delete the deprecated function, and replace the first call site. That's it." (specific, small, no ambiguity)
Model 2: Monoidealism — Single-Task Focus
Definition: Monoidealism is the state of focusing on exactly ONE thing. It's the opposite of multitasking — and it's where all your best work happens.
The science: Your brain cannot parallel-process complex tasks. What you call "multitasking" is actually rapid context switching, and it destroys performance.
How to achieve monoidealism:
- Pick ONE task for the next 60-90 minutes
- Eliminate interruptions — close email, silence notifications, use DND mode
- Define "done" — "I'm done when I've written the first draft of the API docs for the /users endpoint"
- Set a timer — External structure helps. 60 or 90 minutes. When it rings, take a break.
- If interrupted, write down where you are — "I was in the middle of implementing the validation logic for the email field." This reduces restart cost.
Team application: "Focus Fridays" — no meetings, no Slack, just deep work. One company reported 35% more code shipped per week after implementing this.
Model 3: Cognitive Switching Penalty
Definition: Every time you switch between tasks, your brain needs ~23 minutes to fully re-engage with the new context (University of California, Irvine research).
The math is devastating:
Developer's day: 8 hours = 480 minutes
Switches between tasks: 8 times (Slack ping, meeting, different ticket...)
Switching cost: 8 × 23 minutes = 184 minutes LOST
Actual productive time: 480 - 184 = 296 minutes (4.9 hours)
That's 38% of the day wasted on switching.
Reducing switching costs:
- Batch similar work — Do all code reviews at 2 PM, not scattered throughout the day
- Protect focus blocks — 3-hour minimum blocks for complex work. One meeting in the middle destroys it.
- Async by default — Slack messages don't need instant replies. Check at 10 AM, 1 PM, 4 PM.
- Meeting-free mornings — Complex work in the morning, collaborative work in the afternoon
- Two-pizza calendar — If your calendar has more than 2 meetings per day, something is wrong
For managers: Every time you ping a developer with "quick question," you cost the team 23 minutes. Batch your questions. Send them all at once. Let them respond when they're at a natural stopping point.
Model 4: Most Important Tasks (MITs)
Definition: Each day, identify 2-3 tasks that would make the day a success even if nothing else gets done. Do these FIRST.
The process:
- End of previous day: Write tomorrow's 2-3 MITs
- Morning: Start MIT #1 immediately (before email, before Slack)
- Don't move to MIT #2 until #1 is complete or blocked
- Everything else goes on a "could do" list — handle only after MITs are done
Choosing MITs:
- Which task, if completed, would have the biggest impact this week?
- Which task have I been avoiding the longest? (Usually the most important)
- Which task, if NOT completed today, would create a problem tomorrow?
Example daily plan:
MITs:
1. Ship the payment integration PR (blocks 3 other team members)
2. Write the investor update email (deadline: tomorrow)
3. Review and approve the Q1 budget (finance team waiting)
Could do (if time permits):
- Refactor the notification module
- Reply to non-urgent Slack threads
- Read the competitor analysis doc
Model 5: The 5-Fold Why
Definition: Ask "why?" five times to drill from symptom to root cause.
Example: "Our sales are declining"
Why are sales declining?
→ Because fewer leads are converting to customers
Why are fewer leads converting?
→ Because our sales cycle has lengthened from 14 to 45 days
Why has the sales cycle lengthened?
→ Because prospects need 3-4 demos instead of 1
Why do they need more demos?
→ Because the first demo doesn't address their specific use case
Why doesn't it address their use case?
→ Because we use a generic demo script instead of customizing per industry
ROOT CAUSE: Generic demo script. Not "sales are bad."
FIX: Create 5 industry-specific demo templates. Expected impact: cut sales
cycle back to 14-21 days, increase conversion by 30-40%.
Rules for effective 5-Fold Why:
- Don't accept "because people are lazy/stupid" — that's a process failure, not a people failure
- At each level, verify with data if possible
- The root cause should be something you can FIX (actionable)
- Sometimes 3 whys is enough. Sometimes 7 is needed. Five is a guideline, not a law.
Model 6: The 5-Fold How
Definition: The reverse of 5-Fold Why. Start with a goal and ask "how?" five times to break it into concrete actions.
Example: "I want to reach $10k MRR"
How do I reach $10k MRR?
→ Get 200 customers at $50/month average
How do I get 200 customers?
→ Convert 5% of 4,000 qualified leads
How do I get 4,000 qualified leads?
→ Run content marketing + paid ads targeting SMB owners
How do I run effective content marketing?
→ Publish 2 SEO articles/week + 1 case study/month + distribute on LinkedIn
How do I publish 2 articles/week consistently?
→ Block Tuesday and Thursday mornings for writing. Use an outline template.
Batch 4 outlines on Monday. Write Tuesday + Thursday. Edit Friday.
ACTIONABLE PLAN: Block mornings, use templates, batch outlines.
Much more concrete than "reach $10k MRR."
Model 7: Externalization
Definition: Get it OUT of your head and INTO a system. Your brain is for generating ideas, not storing them.
What to externalize:
- Tasks → Task manager (Todoist, Linear, even a text file)
- Ideas → Notes app or capture inbox
- Decisions → Written pros/cons list
- Plans → Written documents with dates and owners
- Recurring processes → Checklists and SOPs
Why it matters: Every item you hold in your head consumes cognitive bandwidth. A brain juggling 15 "I should remember to..." items has less capacity for creative problem-solving. Write it ALL down.
Implementation: End each work session with a 5-minute "brain dump" — write down everything that's in your head about what needs to happen next. Tomorrow-you will thank today-you.
Examples
Example 1: Design a productive daily routine
User request: "I'm a solo founder and I feel like I'm busy all day but accomplish nothing. Help me fix this."
Output:
Productivity Diagnosis: Busy but Unproductive
Likely causes:
1. No MITs defined → everything feels equally urgent
2. Reactive mode → email/Slack drives your day, not priorities
3. Context switching → jumping between coding, marketing, support, admin
Recommended Daily Structure:
EVENING BEFORE:
- Write tomorrow's 2-3 MITs (5 min)
- "The day is won or lost before it begins"
MORNING BLOCK (8:00-11:30) — Deep Work:
- Phone in another room, Slack closed, email closed
- MIT #1 (90 min), break (15 min), MIT #2 (90 min)
- This is where 80% of your real output happens
MIDDAY (11:30-13:00) — Communication:
- Process email (batch, not trickle)
- Respond to Slack
- MIT #3 if time permits
AFTERNOON (13:00-16:00) — Collaborative/Admin:
- Meetings (batch them here, NEVER in the morning)
- Customer support
- Admin tasks
END OF DAY (16:00-16:30) — Shutdown:
- 5-minute brain dump
- Set tomorrow's MITs
- Close all work apps (real shutdown, not "I'll just check one thing")
Key rules:
- Morning block is sacred. No exceptions.
- If it's not an MIT, it can wait until afternoon.
- Check email 2x/day max, not continuously.
Example 2: Root cause analysis for a team problem
User request: "My dev team keeps missing sprint commitments. We've tried adding more developers but it didn't help."
Output:
5-Fold Why Analysis: Missed Sprint Commitments
Why do we miss sprint commitments?
→ Stories aren't completed by end of sprint
Why aren't stories completed?
→ Developers start stories but get blocked mid-sprint
Why do they get blocked?
→ Dependencies on other teams (design, API team) aren't resolved in time
Why aren't dependencies resolved?
→ They're discovered DURING the sprint, not before
Why are dependencies discovered late?
→ Stories enter the sprint without technical breakdown or dependency mapping
ROOT CAUSE: Inadequate sprint planning / story refinement
NOT "we need more developers" (adding people made it worse — Brooks's Law)
Fix:
1. Require dependency mapping before any story enters a sprint
2. Add a "refinement" session mid-week for NEXT sprint's stories
3. Rule: if a story has an unresolved external dependency, it doesn't enter the sprint
4. Track "blocked time" as a metric — make the problem visible
Expected result: 70-80% sprint completion (from current ~50%)
within 3 sprints of implementing this change.
Guidelines
- Productivity advice should be specific and actionable, not generic. "Focus more" is useless. "Block 9-11:30 AM, close Slack, work on MIT #1" is actionable.
- When doing 5-Fold Why, push past comfortable answers. "People aren't trying hard enough" is never the root cause — it's always a system/process issue.
- Context switching costs are usually the #1 hidden productivity killer. Flag it aggressively.
- Prefer environment design over willpower. Willpower is finite and unreliable. Systems are consistent.
- For teams, always consider Brooks's Law: adding people increases communication overhead (n×(n-1)/2).
- MITs should be outputs ("ship the PR"), not activities ("work on the code"). Outputs are measurable.