Problem logging is the habit of writing down problems the moment they surface — instead of trying to hold them in memory or fix each one in isolation — so patterns and priorities become visible over time.
The idea
Problems that only live in someone’s memory tend to get lost, downplayed, or fixed piecemeal without anyone noticing they keep recurring. Keeping a running log — a notebook, an issue tracker, a simple list — turns scattered annoyances into a dataset: which problems repeat, which ones cluster around the same root cause, and which ones are worth fixing versus tolerating. It also separates the act of noticing a problem from the act of solving it, so a busy moment doesn’t force an immediate, half-considered fix.
When to use it
- Any time work interruptions (“this is broken”, “this is annoying”) threaten to derail focused work
- Recurring operational issues that no one has connected to a common cause
- Personal or team retrospectives, where a log becomes the raw material for review
How to apply it
- Capture the problem as soon as it’s noticed, briefly, without stopping to solve it.
- Note when and where it happened.
- Periodically review the log for repeats or clusters.
- Prioritize fixes based on frequency and impact, not just recency.
Watch out for
- Letting the log become a graveyard that’s never reviewed.
- Logging so much detail that capturing a problem becomes its own chore.
- Using the log as a substitute for actually fixing anything.
Related models
- Root Cause Analysis — a well-kept log surfaces the recurring problems worth root-causing.
- Problem Solving — logging feeds the intake stage of the broader process.