Last month, I had a project go sideways. Not just a little off-track, but a full-blown, 2 AM-staring-at-the-ceiling kind of sideways. We were building a new client portal for a mid-sized financial firm. Everything seemed fine until the client’s marketing department, who’d been mostly quiet, suddenly decided they needed a complete overhaul of the user interface, two weeks before launch. Their reasoning? “It just doesn’t feel right.” No specifics, just a gut feeling. My team was already stretched thin, and this last-minute curveball felt like a punch to the gut. The project manager was panicking, the developers were muttering about scope creep, and I was stuck trying to figure out how to salvage the timeline without burning everyone out or blowing the budget.
It’s in moments like these that you realize just how much mental clutter we carry. We react, we stress, we try to solve the immediate fire, often making things worse. This is where having a few solid mental models for problem-solving comes in handy. They aren’t magic bullets, but they’re frameworks that help you cut through the noise and see what’s actually happening. They give you a way to think, not just react. I’ve found a few of these, pulled from the Stoics and others, to be incredibly useful for navigating the daily grind of deadlines, difficult clients, and those inevitable bad days.
First Principles: A Core Mental Model for Problem-Solving
When that client portal project started to unravel, my first instinct was to jump into damage control. How many extra hours? Can we cut features elsewhere? Can we push the launch date? All valid questions, but they’re reactions to the problem, not an examination of the problem itself. This is where First Principles thinking helps. It means breaking down a problem to its fundamental truths, the things you know are true and can’t be broken down further. Forget analogies, forget assumptions, forget how it’s always been done. What are the absolute basics?
For the client portal, the “problem” was a vague “doesn’t feel right.” Applying First Principles, I asked: What is the purpose of this portal? It’s to provide secure access to financial data, allow clients to view statements, and communicate with their advisors. What are the essential elements for that? A login, a dashboard, data display, a messaging system. Everything else—the specific color palette, the exact button shape, the fancy animations—is secondary. The client’s marketing team was focused on the secondary, the “feel,” without articulating the primary function they were trying to achieve. They wanted a “modern” feel, but what did “modern” actually mean in terms of user interaction and data presentation? We had to strip away the layers of expectation and get back to the core job the portal needed to do.
I’ve used this approach countless times, especially when dealing with software. Take, for instance, a complex project management tool. Many teams get bogged down trying to use every single feature, customizing dashboards until they’re unreadable. They’re trying to replicate their old, inefficient workflow in a new system. Instead, ask: What is the absolute minimum we need this tool to do? Track tasks, assign owners, set deadlines. That’s it. All the Gantt charts, burn-down reports, and custom fields are optional. If you’re paying for something like Asana’s Business plan—which, honestly, is probably overkill for most small teams at $24.99 per user per month if you’re not managing huge portfolios—you’re probably not using it to its first principles. You’re paying for features you don’t need, and then you’re spending time trying to justify that cost by forcing your team to use them. It’s a waste of time and money. Focus on the core job, then build up only if necessary.
Inversion: What Would Make This Worse?
This is a favorite of mine, often attributed to the mathematician Carl Jacobi, but it’s got Stoic roots too. Instead of asking, “How do I solve this problem?” ask, “How could I make this problem worse?” Or, “How could I guarantee failure?” It sounds counterintuitive, but it’s incredibly powerful. By identifying what leads to failure, you can then avoid those things. It’s a back-door approach to success.
Letters to My Younger Self
30 short essays applying ancient philosophy to modern problems — career, relationships, money.
Read the Letters → $12
Back to the client portal. If I wanted to guarantee this project would crash and burn, I’d do a few things: I’d agree to every single last-minute UI change without pushing back. I’d let the developers work 16-hour days for two weeks straight, burning them out completely. I’d stop communicating with the client, hoping the problems would just disappear. I’d also probably start blaming specific team members in public, which, yes, is annoying and destructive. By listing these failure points, the path forward became clearer: we needed to push back on the client, negotiate a phased release for the UI changes, protect the team’s time, and maintain open, honest communication. It’s a simple shift, but it works.
I use inversion when I’m planning my week. Instead of just listing tasks, I ask, “What would make this week a total disaster?” Usually, it’s things like over-scheduling, not blocking out deep work time, or letting email notifications constantly interrupt me. So, to avoid disaster, I do the opposite: I schedule fewer meetings, I block out two-hour chunks for focused work, and I turn off all notifications for most of the day. It’s a concrete love of mine, this simple act of turning off notifications. It gives me back hours of focused time. The gripe? Most communication tools are designed to constantly pull your attention, making this discipline harder than it needs to be. Slack, for all its benefits, is a master at this. You have to actively fight against its default settings.