2.3

Reviewing a Plan

How to evaluate Claude's suggestions before building

🔎 Technique ⏱️ ~10 minutes

Claude will give you plans. But how do you know if they're good plans? You don't need to be a developer to review effectively—you just need to ask the right questions.

✅ What to Look For

When Claude proposes a plan, check for:

  • Clarity: Do you understand what Claude is proposing? If not, ask for clarification.
  • Completeness: Does the plan cover everything you need? Are there missing pieces?
  • Simplicity: Is this the simplest approach? Could it be simpler?
  • Order: Does the sequence make sense? What depends on what?
✅

Plan Review Checklist

A systematic checklist for evaluating any plan Claude proposes

📄 Preview PDF
Download PDF

📊 Good Plan vs Bad Plan

Here's what the difference looks like:

❌ Bad Plan Example:

"I'll create a comprehensive user authentication system with OAuth integration, JWT tokens, password reset functionality, email verification, two-factor authentication, and a user management dashboard."

Why it's bad: Too much at once, no build order, unclear dependencies, overwhelming scope

✅ Better Plan Example:

"Let's build authentication in phases:

Phase 1 (MVP): Simple username/password login with basic session management
Phase 2: Add password reset via email
Phase 3: Email verification on signup
Later: OAuth and 2FA if needed

We'll start with Phase 1 and see if it meets your needs before adding complexity."

Why it's better: Phased approach, clear MVP, can ship something quickly, room to adjust based on needs

❓ Questions to Ask

Before saying "go ahead," try these:

Challenge the approach:

"Is this the simplest way to do this?"
"What alternatives did you consider?"
"Why this approach over [other approach]?"

Check for problems:

"What could go wrong with this plan?"
"Are there any edge cases we should consider?"
"What assumptions are we making?"

Clarify understanding:

"Can you explain step 3 in simpler terms?"
"What does [technical term] mean in this context?"
"Walk me through what happens when a user does X."

🎯 The "Explain It Simply" Test

If Claude's plan is good, it should be explainable in plain language. Try:

"Explain this plan to me like I'm not a developer. What are we building, and how do the pieces fit together?"

If Claude can't explain it simply, the plan might be overcomplicated.

✨ You're the Product Owner

You don't need to understand every technical detail. But you do need to understand what's being built and why. If something doesn't make sense, that's valuable feedback—the plan might need to change.

🔄 Iterating on the Plan

Plans aren't final until you say so. Common iterations:

  • "Let's start simpler—just do steps 1 and 2 first"
  • "I don't need feature X. Remove that from the plan."
  • "Can we do step 4 before step 3? I want to see results sooner."
  • "This is too complex. What's the minimum viable version?"

💡 Start Small, Expand Later

If a plan feels overwhelming, ask Claude to scope it down. "What's the absolute minimum we need to build to see if this works?" You can always add more later.

📋 The Review Checklist

Before approving a plan:

  1. Can I explain what we're building in one sentence?
  2. Do I understand what each step accomplishes?
  3. Is there anything that seems unnecessary?
  4. What's the first thing we'll see working?
  5. How will we know if it worked?

If you can answer these, you're ready to build.

✏️ Practice: Review This Plan

Claude has proposed this plan for adding a blog to your website:

🎯 Plan Review Exercise

Claude's Proposed Plan:

"To add a blog to your site, I'll:
1. Create a blog.html page with a grid of post cards
2. Add individual post pages (post1.html, post2.html, etc.)
3. Style everything to match your existing design
4. Add navigation links from your homepage
5. Create an RSS feed for subscribers
6. Add social sharing buttons to each post
7. Implement a commenting system"

Question: Is this plan clear and complete?
Question: How would you improve this plan?
What you'd say to Claude:

✅ Success Check

You'll know you've got this when: you can read a plan and immediately spot when it's doing too much, unclear, or missing something important.

💬 Response Templates

Useful phrases for giving feedback on plans:

Common Plan Feedback Responses

"This seems like a lot. What's the absolute minimum version?"
"Can you explain step [X] in simpler terms?"
"Why did you choose [approach A] over [approach B]?"
"I don't need [feature]. Can we skip that for now?"
"What could go wrong with this approach?"
"Can we do [step Y] first to see results sooner?"
"Break this into phases. What's Phase 1?"

📚 Resources & Further Reading

💭 Pause & Reflect

Before moving on, take a moment to consider:

  • Do you tend to accept plans as-is, or do you naturally question them?
  • What's your biggest challenge in reviewing technical plans?
  • How might this review process save you from problems later?

🎯 Review Skills Acquired

You can now evaluate plans effectively. Next: why this planning work pays off over time.

Topic 2.3 Complete • Up Next: 2.4 – The Compound Advantage