When You Are Planning a Project With AI

A reference for turning a rough idea into documents an AI can actually build from

How to Use This Guide

This guide is organized by the planning moments where things go sideways, not by theory. Skim the “When You Might Open This Guide” list, find the moment you are actually in, read the two or three principles under it, and go do the thing. The guide does not care that you have read it end to end. It cares that you open it before you commit to a plan your AI is about to execute against.

Every principle points at the specific place in the Day 2 material it came from, so if you want the longer version you know where to go.

When You Might Open This Guide

• You have a rough idea and the team is staring at you. You have one hour to turn it into something you can start scoping.
• You finished a Perplexity market-research session and the output is fifty bullet points you don’t know what to do with.
• You are about to write a PRD and you do not know what actually belongs in it versus what belongs in the plan doc.
• You are about to hand the AI a “build this” prompt and you are not sure whether your PRD, plan doc, roadmap, and research doc are all supposed to exist separately.
• The AI coded for two hours and built something that is not what you asked for, and you cannot tell whether the prompt was wrong or the plan was wrong.
• Your feature touches a library you have never used before, and you are watching the AI invent API calls that don’t exist.

When You Are Still in the Rough-Idea Stage

Use AI to generate quantity, then you filter for quality. This is the first heuristic of the lecture. The model is fast and shameless about bad ideas, which is what you want at the start. Ask for fifteen, ask for three weird ones, then cut. Do not ask it for “the best idea,” because it does not know, and neither do you yet.

Source: Day 2 slides — Key Takeaways (generate quantity, filter for quality)

Run devil’s advocate on your own idea before anyone else does. Paste your idea back to the model and ask why it might fail, who wouldn’t use it, and what you are probably underestimating. This is cheap and it is the step people skip because they want to feel good about the idea. If you cannot survive your own devil’s-advocate pass, you are not ready to pitch the team.

Source: Day 2 slides — Challenging Ideas: Devil’s Advocate

Name the assumption and ask what happens if it is wrong. Every idea has one or two load-bearing beliefs under it (“people will pay,” “this is a problem,” “our team can build this in eight weeks”). List them. Ask the model whether each holds, and what the consequence is if it doesn’t. The assumptions that would kill the project are the ones you test first.

Source: Day 2 slides — Assumption Testing

When You Are Doing Market Research and Tempted to Trust the First Answer

Perplexity is your research assistant because it is web-connected and cites sources. That citation is the point. Any claim it makes you can click into. If you are doing market research inside a tool that cannot show you where the number came from, you are not doing research, you are doing vibes.

Source: Day 2 slides — Key Takeaways (Perplexity for web-connected research)

Ask for substitutes, the “do nothing” option, and the 800-pound gorilla, not just direct competitors. Most students only name the three apps that look like their app. That misses how people actually solve the problem today, which is usually a spreadsheet, a habit, or nothing. The strongest competitor is almost always “the status quo.” Name it before you write the PRD.

Source: Day 2 slides — Finding Competitors

Use Context7 or Perplexity to pull current docs for libraries you do not know, before you plan. This is one of the biggest uses for MCP research tools: getting accurate documentation into ai/guides/ before the plan is written, so the plan is built on real APIs rather than what the model half-remembers from training. If a feature touches a library you have not used, the Context7 pull is a required step, not a polish step.

Source: Day 2 slides — Research Phase: External Research with MCP Tools

Write the founding hypothesis in one sentence. If you can’t, you don’t understand the market yet. For target customer, who has problem, our approach will solve it better than competition because of differentiation. That is the whole sentence. If your version has five clauses and three adjectives, it isn’t a hypothesis, it’s a pitch deck pretending to be one.

Source: Day 2 slides — Founding Hypothesis

When You Are About to Write the PRD

PRD is immutable. Plan and roadmap are working documents. This is the rule that keeps your project from drifting. The PRD captures what you and the team agreed to build and it does not get edited silently. Plan docs and roadmap docs change as you learn. If a requirement changes, you version the PRD; you do not reach into it and quietly flip a bullet.

Source: Day 2 slides — PRD as Immutable Source of Truth

Write down what is explicitly out of scope. An “Out of Scope” section is not a courtesy. It is the only thing stopping a cooperative AI from building three features you did not ask for because they sounded related. The list of things you are not building is as important as the list of things you are.

Source: Day 2 slides — PRD Structure (Out of Scope)

Add the “DO NOT MODIFY” comment at the top of the PRD once it is finalized. It is a one-line HTML comment and it is load-bearing. Future-you, your teammate, and the AI all will treat a finalized document differently once that line is on it. Docs without that note drift; docs with it survive.

Source: Day 2 lecture — PRD “DO NOT MODIFY” HTML comment convention (detail lives in Tier 1 only)

When You Are About to Let AI Start Building and You Have Just a PRD

Run the PRD, research, plan, roadmap pipeline. All four are different documents for different reasons. PRD is the what and why (immutable). Research is what currently exists (facts only, no opinions). Plan is the what and how (the thinking). Roadmap is the checklist (the doing). Skipping a step saves time on the document and loses it three times over on the rebuild.

Source: Day 2 slides — PRD → Research → Plan → Roadmap Pipeline

Research before planning means the AI documents what exists with no opinions. When you ask an AI to “plan this feature” it does two things at once: researches your codebase and forms opinions about it. The coupling is what bites you. The separate research step asks only what files are involved, how they connect, what patterns are in use, and explicitly forbids suggestions. Opinions go into the plan doc, not the research doc.

Source: Day 2 slides — Research Phase: Document Before You Plan

A plan tells a human how to think about the work. A roadmap tells the AI what to do next. One is for understanding, one is for execution. The AI refers to the plan for “how” and the roadmap for “what is next.” If you only write one, you get an AI that either loses the strategy or loses the thread.

Source: Day 2 slides — Plan vs Roadmap

Date-prefix plan and roadmap files in ai/roadmaps/ and archive them when done. File name is ai/roadmaps/YYYY-MM-DD_feature-name_plan.md. When the work is complete, move it to ai/roadmaps/completed/. The whole point is that future-you and future-AI can see the history without guessing which doc was the live one.

Source: Day 2 slides — Plan Documents: file naming in ai/roadmaps/

When You Are Defining the MVP and the Scope Is Getting Too Big

Be ruthless about cutting. You can always add features later. The MVP is not the small version of the whole product. It is the one core problem, solved minimally enough to get a real user in front of it. The prompt in the lecture literally says “be ruthless about cutting scope” for a reason; every student in class overshoots.

Source: Day 2 slides — MVP Definition: Be Ruthless About Scope

Pressure-test the MVP against real time and real people. “I have X weeks with Y developers, is this realistic?” is the second prompt in the MVP section and it does the same job a skeptical senior engineer would do if you had one. Run it. The answer is almost always that you are underestimating integration, testing, and the last twenty percent.

Source: Day 2 slides — MVP Reality Check

Check for scope creep by comparing the MVP back to the original problem statement. If your MVP has drifted from what the PRD problem statement said, that is a signal, not a feature. Ask the AI to find features that do not directly serve the core problem. It will.

Source: Day 2 slides — Scope Creep Detection

When You Want to Review What You Wrote Before the Team Sees It

Read it back as the developer who will implement it. The prompt in the lecture is literal: “What’s unclear? What could be interpreted multiple ways? Rewrite any ambiguous sections to be crystal clear.” A spec that reads fine to the author almost always has three places a second reader would guess, and those guesses are where AI-built code goes wrong.

Source: Day 2 slides — Clarity Check

Run the four-perspective peer review even when you have no peers. CEO, lead developer, user, investor. Four concerns. It takes five minutes and catches the business-case weakness, the technical infeasibility, the user who would not care, and the funding question before any of them cost you a sprint.

Source: Day 2 slides — Stakeholder Perspectives

The 2x2 differentiation check: if you are clustered with competitors, your differentiation is not radical enough. Plot yourself and three competitors on the two dimensions customers actually use to evaluate. If you land in a crowded quadrant, reframe. Being “a little better” is not a position. Being alone in the quadrant is.

Source: Day 2 slides — Differentiation Check

The Planning Document Stack (Keep This Nearby)

These are the six documents the Day 2 lecture has you create, in order. If an AI asks you which one to update, the PRD is almost never the answer.

Go Deeper