Problem Solving
Systematic approaches to tackle problems
All Cards in This Deck
Explanation
Italian economist Vilfredo Pareto noticed that 80% of Italy's wealth was owned by 20% of the population. This pattern appears everywhere: a small portion of causes typically creates a large portion of effects. The exact ratio varies, but the principle is consistent—most results come from a small number of inputs.
Example
Microsoft found 20% of bugs caused 80% of crashes—fixed those first, stability improved dramatically. SaaS company: 18% of features had 87% of usage—killed the rest, saved 40% maintenance. Your week: Track everything. Bet ~3 hours created 80% of your value. Protect those hours.
Explanation
Before beginning a project, imagine it has completely failed and work backwards to figure out what could have caused that failure. Unlike post-mortems that happen after problems occur, pre-mortems help prevent problems by identifying risks while you still have time to address them. Psychologist Gary Klein developed this technique to help teams think through potential failure modes.
Example
Product launch failed. Why? No one used it. Why? Didn't solve real problem. Why? Never talked to users. Prevention: Interview 50 users first. Startup failed. Why? Ran out of money. Why? Grew too fast. Why? Hired before product-market fit. Prevention: Stay lean until PMF.
Explanation
Systems thinking means looking at how all the parts of a situation connect and influence each other, rather than trying to understand each piece in isolation. When you change one part of a system, other parts react in ways that might surprise you. Most problems that seem like 'people problems' are actually system problems—the structure and incentives that shape behavior.
Example
Adding more developers to late project makes it later (Brooks' Law)—communication overhead exceeds productivity gain. Lowering prices increases sales but trains customers to wait for sales, decreasing future sales. Antibiotics kill bacteria but also create resistant bacteria, making future infections worse.
Explanation
Every problem has symptoms (what you can see) and root causes (the underlying reason it's happening). Treating only the symptoms might provide temporary relief, but the problem will return. Root cause analysis digs deeper to find the fundamental issue that, when fixed, prevents the problem from recurring. Most people stop too early and only address surface-level symptoms.
Example
Customer complaints up 50%. Symptom: Long wait times. First cause: Not enough staff. Root cause: Poor forecasting system. Fix: Better demand prediction. Server crashes daily. Symptom: Out of memory. First cause: Memory leak. Root cause: No code review process. Fix: Mandatory reviews.
Explanation
Many programmers keep a rubber duck on their desk and explain their problematic code to it line by line. Surprisingly often, the act of explaining the problem out loud reveals the solution. This works because verbalizing forces you to think sequentially and clearly, often exposing assumptions or gaps in logic that weren't obvious when the problem was just in your head.
Example
Developer stuck for hours. Explains to duck: 'This function takes user input, validates it, then... oh wait, I'm not validating negative numbers.' Problem solved. Writer with plot hole explains story to teddy bear, realizes timeline doesn't work. Manager explains staffing problem to coffee cup, sees obvious solution.
Explanation
Business consultant Eli Goldratt's Theory of Constraints states that every system is limited by a single bottleneck at any given time. Making improvements anywhere else in the system won't increase overall performance—only improving the constraint will help. Once you fix that bottleneck, a new constraint will emerge somewhere else in the system.
Example
Restaurant can seat 100, kitchen can make 50 meals/hour. Kitchen is constraint. Improving service speed won't help. Website: Server handles 1000 requests/sec, database handles 100. Database is constraint. Faster server won't help. Team productivity: Everything waiting on designer. Designer is constraint. More developers won't help.
Explanation
When facing a complex problem that feels overwhelming, break it down into smaller, more manageable pieces. Each individual piece will be simpler to understand and solve than the whole problem. Once you solve the pieces independently, you can combine the solutions. This approach is used everywhere from computer algorithms to military strategy to project management.
Example
Building app feels impossible. Break down: authentication, database, UI, API. Each is manageable. Writing book overwhelming. Break down: outline, chapters, sections, paragraphs. Each is doable. Debugging complex issue: isolate components, test each separately, find which fails.
Explanation
Psychologist Edward de Bono created this method to help groups think more effectively by focusing on one type of thinking at a time. Each 'hat' represents a different perspective: White for facts, Red for emotions, Black for critical thinking, Yellow for optimism, Green for creativity, and Blue for process management. By wearing one hat at a time, groups avoid the common problem of criticism killing good ideas before they're fully developed.
Example
Team evaluating new feature: White: '10% of users requested this.' Red: 'Feels like feature creep.' Black: 'Will increase complexity.' Yellow: 'Could differentiate us.' Green: 'What if we made it a plugin?' Blue: 'Let's spend 5 minutes per hat.' All perspectives heard, better decision made.
Explanation
Instead of following logical, step-by-step reasoning (vertical thinking), lateral thinking involves making unexpected connections and approaching problems from unusual angles. Edward de Bono coined this term to describe creative problem-solving that challenges assumptions and uses techniques like random stimulation or reversing the problem. Many breakthrough solutions come from this sideways approach rather than just thinking harder in the same direction.
Example
Factory had elevator complaints. Vertical: Faster elevator. Lateral: Install mirrors—people stop noticing wait time. City had bridge jumpers. Vertical: Higher barriers. Lateral: Install phones to counselors—suicides dropped 50%. Company needed office space. Vertical: Rent more. Lateral: Go fully remote.
Explanation
This problem-structuring framework from McKinsey consulting ensures that when you break down a problem, your categories are Mutually Exclusive (no overlap) and Collectively Exhaustive (nothing is left out). This prevents you from double-counting things or missing important areas. If your analysis isn't MECE, your conclusions will be unreliable.
Example
Customer segments: 'New vs Returning' is MECE. 'Young vs Urban' is not (young urban people counted twice). Revenue breakdown: 'Product vs Services' is MECE. 'Online vs International' is not (overlap). Age groups: '0-17, 18-34, 35-54, 55+' is MECE. '0-20, 18-35, 30-50, 45+' is not.
Explanation
Rather than making changes based on hunches or opinions, frame your ideas as testable hypotheses with specific predictions and measurable outcomes. This approach, borrowed from the scientific method, makes your assumptions explicit and creates systematic learning opportunities. It prevents teams from building things based on what they think will work rather than what they can prove will work.
Example
Not: 'Users will love this feature.' But: 'We believe adding social sharing will increase user retention by 15% as measured by 30-day active rate.' Not: 'This will improve performance.' But: 'Caching will reduce load time by 50% as measured by p95 latency.'
Explanation
A/B testing is the gold standard for proving that changes actually cause improvements rather than just correlating with them. You randomly assign users to different versions of your product and measure the difference in outcomes. This controlled experimentation approach is used by every major tech company because even small improvements can compound into significant results over time.
Example
Google tested 41 shades of blue for links—extra $200M revenue. Amazon tests everything: one pixel change in button placement = $300M/year. Booking.com runs 1000+ tests simultaneously. Your test: Red vs Green button might seem trivial, but could mean 5% more conversions.
Explanation
This framework borrowed from journalism ensures you fully understand a problem before trying to solve it. Most problems are poorly defined initially, and jumping to solutions without clarity leads to solving the wrong problem. By systematically asking Who, What, When, Where, Why, and How, you force yourself to gather complete information and define the problem clearly.
Example
System outage: Who was affected? (Enterprise customers) What happened? (API timeout) When? (3am-5am PST) Where? (US-East region) Why? (Database backup lock) How did it manifest? (503 errors). Now you can solve the right problem.
Explanation
Instead of trying to build a perfect solution from the start, create the simplest version that can test your most critical assumptions. The goal is to learn quickly and cheaply whether you're on the right track. This approach, from design thinking and lean startup methodology, recognizes that most initial ideas are wrong—prototypes help you discover this before you've invested too much time and money.
Example
Zappos: No inventory, bought shoes from stores after orders came in. Tested if people would buy shoes online. Dropbox: Video of non-existent product got 75k signups overnight. Tested if people wanted it. Your idea: Build with no-code tools first. If no one uses free version, they won't pay for polished version.
Explanation
Instead of accepting conventional approaches or making incremental improvements, first principles problem solving means stripping away all assumptions and rebuilding solutions from the most basic truths. This approach can reveal entirely new ways to solve old problems by questioning everything that's typically taken for granted.
Example
Traditional car manufacturing assumed cars must be built on assembly lines in sequence. Tesla questioned this assumption and built cars in parallel modules, reducing production time. Traditional education assumes students must learn in age-based groups at fixed paces. Some schools rebuild from 'how do humans actually learn best?'
Explanation
How you frame a problem determines what solutions you can see. By deliberately reframing the same situation in different ways, you can discover solution approaches that weren't visible with the original problem statement. Often the breakthrough comes not from solving the problem better, but from solving a different problem entirely.
Example
Original: 'How do we make elevators faster?' Reframe: 'How do we make waiting for elevators less annoying?' Solution: Install mirrors so people check their appearance. Original: 'How do we reduce crime?' Reframe: 'How do we increase community connection?' New solutions emerge around building relationships.
Explanation
Design thinking is a structured approach to solving problems that puts human needs at the center. Instead of starting with technology or constraints, you start by deeply understanding the people you're solving for, then systematically work through defining the problem, generating ideas, building prototypes, and testing with real users.
Example
Traditional approach: Build better healthcare software based on technical specifications. Design thinking: Spend time with doctors and patients, understand their real frustrations, define the core problem (not what you assumed), generate multiple solution ideas, prototype the most promising ones, test with actual users, iterate based on feedback.
Explore More Decks
Get Full Access in the App
Unlock AI-powered conversations, create custom decks, and track your learning progress.
Download on App Store