Stop Making Pros and Cons Lists
The 4-level framework that turns endless debates into clear decisions
When I was young, I had to choose between two technical systems.
Two different hardware systems.
Two different software systems.
A Nintendo Entertainment System or a Sega Genesis.
So I did what any reasonable software engineer would do.
I created a list of Pros.
And I created a list of Cons.
And in my career in software engineering and leadership, I've seen far too many pros and cons list.
Because Pros and Cons list suck.
They are terrible and you should stop using them.
Here are the three levels of Pros and Cons lists, all the way up to nirvana.
Level 0: The Empty List
Junior engineers have a task to do. A problem to solve.
So they go out and figure out the solution. Or more accurately, *a* solution.
Example:
Problem: Users complaining about slow app performance
Solution: Add loading spinners everywhere
Brings to product review
"Are you just masking the real problem?"
"What about actual performance improvements?"
"Did you measure what's actually slow?"
"Have you considered caching?"
Back to square one.
In some companies, they may have to get approval for their solution first, like a design review.
So they bring their solution, and a bunch of senior engineers poke holes in their perfect design.
Back to the drawing board.
The reason that this approach fails is because of blindness.
It's because of the unknown unknowns.
It's the lack of diversity.
When you consider several potential solutions, you get to see different ways to solve the same problem. And this highlights the different tradeoffs. It brings them to the surface. It makes them visible.
Level 1: The Unstructured Approach
You have a problem to solve.
You've learned your lesson.
So you explore 2-3 different solutions.
This gives you a better sense of the Problem Space.
You choose the best option and document the alternatives that you considered.
Example:
Problem: Users complaining about slow app performance
Option 1: Add loading indicators (quick fix)
Option 2: Optimize database queries (backend work)
Option 3: Implement caching layer (infrastructure)
Chose loading indicators because we can ship fast.
Product review drags on for 2 hours
"But this doesn't solve the root cause..."
"What's our long-term strategy here?"
And the design review meeting never ends. Endless discussion. A pile of follow-up work before the next review. Rinse and repeat.
And this is if you're lucky.
If you're not, you'll just go ahead. You'll build something mediocre and never even know it. Maybe a few years later someone will refactor your work and you'll realize you could have done better. More likely you'll be in a different company by then.
This approach fails because it hides the trade-offs that *you* made.
It makes it harder for others to understand *why* you chose one option and discounted the others.
You can do better.
Level 2: The Lists
You found a great mentor.
They teach you to document the pros and cons of each option.
So when you get a new problem to solve, you don't just consider several solutions, you also catalog and document the strengths and weaknesses of each option. Your design document now contains a list of pros and cons.
Example:
Loading Indicators Pros:
- Ships in 2 days
- Low engineering effort
- Improves perceived performance
Loading Indicators Cons:
- Doesn't fix real problem
- Band-aid solution
- Users still wait
Database Optimization Pros:
- Solves root cause
- Permanent fix
- Better user experience
Database Optimization Cons:
- 3-week timeline
- High complexity
- Risky deployment
And the design review meeting goes great.
There's some good feedback, the discussion is productive, and the meeting ends on time.
At least, that's how it usually goes.
Sometimes, it doesn't.
Sometimes it gets heated, and you're not sure why.
Sometimes people disagree and you just can't get to a decision.
Pros and Cons lists do a reasonable job of surfacing tradeoffs.
They make visible what was invisible.
Except for the most important part.
Pros and Cons lists are so deceptive because of this. They highlight 80% while hiding the most important 20% below the surface.
Level 3: The Table
The problem with Pros and Cons lists is that they are lists.
Every alternative has their own list.
There is no centralized schema.
What you need is a table.
You need consistent rows.
Instead of disjoint evaluation criteria, you evaluate each alternative solution using the same set of criteria.
Example:
Priority order:
1. User Impact (customer satisfaction is dropping)
2. Time to Ship (demo to investors next week)
3. Long-term Value (sustainable solution)
4. Engineering Cost
5. Risk Level
| Criteria | Loading UI | DB Optimization | Caching |
|------—————--———-—|------------|-----------------|---------|
| User Impact | Low | High | High |
| Time to Ship | 2 days | 3 weeks | 6 weeks |
| Engineering Cost | Low | Medium | High |
| Long-term Value | Low | High | High |
| Risk Level | Low | Medium | High |
Your document now captures the evaluation criteria for each option in a consistent manner. And this means adding two new sections to the document.
At the end of the document, add a summary table that shows the strengths and weaknesses of each option in a single location.
But if you stop here, you will miss out on the most important part.
If you stop here, you will notice that you still get unproductive friction.
Over time, you may notice an interesting trend.
The debate is rarely about the contents on this table.
The debate is about the order of the rows.
That's where the real disagreement lies.
That's the heart of every hard decision.
And so you add the second part to your document. You list out the rows, or evaluation criteria, at the start of the document. And you sort it based on importance.
And that's where you focus your team's energy