Marcus is a junior at UC San Diego, studying cognitive science. He's been telling anyone who will listen that he's "building an AI app for students." He has a Notion doc, three logo concepts, and a domain name. He does not have a product.
When his roommate asks what the app actually does, Marcus says: "It like... uses AI to help you study. You know, personalized learning. Flashcards but smarter. Maybe a chatbot. Could also do scheduling. Or maybe it summarizes your notes. Still figuring out the exact scope."
Marcus has been "figuring out the exact scope" for four months. His roommate — who spent two weeks building a $40/month Notion template business — is now on her third paying client.
Here's what's brutal about the vague idea stage: it's genuinely fun. You're in possibility space. The app could be everything. You haven't failed yet. You haven't built anything embarrassing. Every time you explain the concept to someone new, you get to enjoy the moment where their eyes light up with "oh that could be huge."
The problem is that vagueness is not a stage you grow out of naturally. Left alone, it compounds. Each new feature you mentally add makes the project feel more substantial — and simultaneously less likely to ever actually exist. Marcus's app isn't too ambitious. It's too undefined. There's a big difference.
An ambitious idea has a clear shape. A vague idea is just a fog of possibilities that feels ambitious when you're standing inside it.
Most people in your orbit who are "building something" are in Marcus's position. They have a concept, a name, maybe a domain. The people who actually ship are a small fraction — and the consistent difference isn't skill level or resources. It's specificity. They answered the hard scoping questions early instead of deferring them indefinitely.
Scoping gets taught as a project management concept — timelines, resources, deliverables. Forget that framing. For a side project, scoping means answering one underlying question: Is this idea specific enough that I could build a first version in four to six weeks, and would someone actually pay for or use that version?
That question has two parts that both need a yes. The first part — "could I build a first version in four to six weeks" — forces you to confront the gap between what you're imagining and what you're capable of executing. The second part — "would someone actually use it" — forces you to confront whether the idea exists for you or for other people.
Marcus's app fails both tests. He can't build "AI-powered personalized learning with chatbots and note summarization and scheduling" in six weeks. And "students" is not a customer — it's a demographic. Fifty million people is not a target market.
Not all vague ideas are vague in the same way. Before you can fix the problem, you need to know which kind of vague you're dealing with:
Before your next work session on any idea, write a single sentence that answers: Who specifically has what specific problem, and how does my thing specifically solve it? If you can't write that sentence cleanly in under 30 seconds, you are in the vague zone — regardless of how much work you've done on it so far.
There's a tempting and counterproductive way to use AI during the scoping phase: you dump your vague idea into ChatGPT and ask "is this a good idea?" and it tells you yes, it has potential, here are some features you could consider. Congratulations, you've used AI to make your idea feel more legitimate while doing zero actual scoping.
AI tools become genuinely useful in scoping when you use them to challenge and constrain rather than validate and expand. The right prompts push AI to narrow the audience, stress-test the assumptions, find the closest existing competitors, and define what the smallest possible useful version would look like.
That's a discipline problem more than a tool problem. The next three lessons walk through a specific framework for doing exactly that — using AI to move systematically from fog to something you can actually build. But the first move is yours: you have to want a real answer more than you want a comfortable one.
You're going to pitch a side project idea — real or hypothetical — to an advisor who will probe it for vagueness. The advisor's job is not to tear it down, but to surface exactly where your idea is still fog. Your job is to defend and sharpen it.
Start with your best pitch of the idea in one or two sentences. The advisor will ask you hard questions. After three or more exchanges, you'll get a diagnosis of which "flavor of vague" the idea sits in — and what to do next.
Two students from NYU's entrepreneurship program pitch their AI side projects to a small group of friends who agreed to give honest feedback.
Priya goes first. Her app helps "busy professionals manage their inbox." When asked who specifically, she says "anyone who gets too many emails." When asked what makes it different from Gmail's smart filters or Superhuman, she says those are "too expensive or too complicated for most people." The feedback session gets awkward.
Devon goes second. His tool helps "first-generation college students fill out financial aid appeals after getting a low initial offer." He knows his first ten users by name — they're from his high school. He has already sat with three of them while they used a rough prototype. The feedback session becomes a conversation about growth.
The difference isn't that Devon's idea is "better." It's that Devon's customer is real. Priya's is hypothetical.
There's a speech pattern that shows up in almost every vague side project pitch: "this could help anyone who…" or "basically everyone has had this problem at some point." Both of those statements might be true. They're also functionally useless for building anything.
When your customer is "everyone," you have no way to make a single concrete decision. What feature do you build first? You don't know — everyone wants different things. What does the onboarding flow look like? You don't know — everyone needs different explanations. What's the pricing? You don't know — everyone has different budgets and willingness to pay.
Every design decision in a product is actually a statement about who the product is for. The more specific you are about that person, the faster and better your decisions become. The fuzzier your customer is, the more every decision becomes a debate with no resolution.
Think of target customer definition as a ladder with five rungs. Most people building side projects are stuck on rung one or two and think they're already at four or five:
Most people you know who are "building for students" or "targeting freelancers" are at rung one or two and calling it market research. Getting to rung four or five before you've written a single line of code or built a single page is not overcautious — it's the move that makes everything else faster.
This is where AI tools genuinely earn their keep. You can use them to conduct a structured interrogation of your assumed customer — the kind of conversation you'd have with a good mentor who refuses to let you get away with vague answers.
The specific prompts that work well here follow a pattern: describe your assumed customer, then ask the AI to identify all the unstated assumptions in that description. Then ask it to generate five or six alternative customer profiles that might have the same surface-level problem but completely different root causes and solutions.
For example: if you say "my customer is a freelancer who struggles with invoicing," a good AI prompt will surface that "freelancer" includes everything from part-time tutors making $500/month to creative agencies billing $30,000 per project — who have nothing in common in terms of needs, willingness to pay, or existing tools. That's not one customer. That's twenty.
The goal of this exercise isn't to pick the "right" customer — it's to pick a customer who is specific enough that you could find ten of them this week and ask them three questions. If you can't do that, you haven't scoped the customer yet.
Write your current assumed customer description. Then ask an AI to list every assumption baked into that description that you haven't verified. For each assumption, rate it: I know this is true / I think this is probably true / I have no idea if this is true. The last category is your research list, not your feature list.
There's a simple test you can run on any customer definition: could you find ten of these people and call them this week? Not survey them — actually have a ten-minute conversation. If the answer is no, your customer definition isn't specific enough yet.
This isn't just a theoretical exercise. Customer conversations at the pre-build stage are one of the highest-leverage things you can do. Not to validate that your idea is good — to understand the actual shape of the problem from the inside. Devon didn't ask his friends "would you use my app?" He sat with them while they tried to navigate the financial aid appeals process and watched where they got stuck.
That's a different kind of information than any AI tool can generate — and it's the kind that makes everything else sharper. But you can only have those conversations once you know who to call. And you can only know who to call once you've done the specificity work described in this lesson.
You're going to work through the Customer Specificity Ladder for your side project idea. Start by describing your current assumed customer. The advisor will systematically probe the assumptions embedded in that description and push you up the ladder — rung by rung — until you can pass the "could I call them this week" test.
This is a working session, not a pitch. Be honest about what you actually know versus what you're assuming.
Jasmine is a 21-year-old who spent three months building a "better résumé builder" after watching her roommate spend a weekend struggling with Canva and Google Docs to format a résumé for a job application.
She built clean templates, a drag-and-drop editor, ATS-optimization tips. Genuinely good work. She soft-launched to 200 people. Got some signups. Then flatlined.
Six months later, a friend pointed out what she had missed: her roommate's actual problem wasn't formatting. It was not knowing what to put on a résumé as someone with minimal experience. The formatting took a weekend because she was rewriting bullets 40 times trying to sound competent. The design was a proxy for insecurity about her credentials.
A tool that helped recent grads translate their actual experiences into credible-sounding résumé language — using AI to bridge the gap between "I worked retail for two summers" and something a recruiter would notice — that would have solved the real problem. Jasmine had solved the symptom.
When people describe problems they want solved, they almost always describe the symptom — the part of the problem that's most visible and most annoying. "I need a better to-do list." "I need a faster way to respond to emails." "I need help staying focused." These are real experiences. They're also surface-level.
The root problem is usually one layer deeper. Why do they need a better to-do list? Because they're overwhelmed and can't prioritize — which means a to-do list isn't actually the solution, a prioritization framework is. Why do they need faster email responses? Because they've agreed to too many things and email is where that cost shows up — which means inbox tooling addresses the symptom but doesn't change the underlying overcommitment.
Building a product that solves a symptom is very easy. It's also a common reason smart products with clean UX fail to get retention — they fix the visible friction without touching what's actually causing it.
AI-powered products have a specific version of this problem. Because AI can automate almost any information-processing task, it's tempting to reach for "AI can do that faster" as the product value. But faster is almost never the root need. The question isn't "how do I do this thing faster" — it's "why am I doing this thing at all, and what's preventing me from doing it well." Those are different questions with different answers.
The "Five Whys" technique was originally a manufacturing quality-control method, but it maps perfectly onto problem scoping. The idea is simple: take the stated problem and ask "why is that a problem?" five consecutive times. Each answer reveals a deeper layer of the actual need.
Example: "Students procrastinate on assignments."
Now we're somewhere interesting. The root problem isn't a productivity failure — it's a social-anxiety-driven information gap. A product that helps students privately clarify assignment expectations without the social cost of asking publicly is solving the real thing. A productivity timer is not.
You don't always need exactly five whys. Sometimes three gets you there. Sometimes you need seven. The number is less important than the practice of refusing to stop at the first visible answer.
This is one of the most useful applications of AI in the scoping phase. The friction is that doing Five Whys on your own idea feels weird — you keep arriving at the answer you already believe. An AI interlocutor can push you past that by generating alternative "why" paths you wouldn't have considered.
The structure that works: describe the problem your product is solving, then ask the AI to generate three different "why chains" — three separate paths through the Five Whys that lead to different root causes. Then look at which root cause your product actually addresses, and whether that's the right one for your target customer.
You will often discover that your product solves Why 2 while the real pain lives at Why 4. That's important information. It tells you either that you need to redesign the product, or that you're targeting the wrong person (someone for whom Why 2 actually is the root).
Take the core problem your product claims to solve. Run three separate Five Whys chains — don't stop when you think you've found "the" answer. Map where in each chain your product actually intervenes. If you're consistently stopping at Why 1 or Why 2, you're building a symptom-solver, not a root-problem solver. That's a pivot moment, not a build moment.
One thing worth saying clearly: symptom-level products can work. Ibuprofen doesn't cure inflammation — it manages the symptom. There's a massive market for pain management. The question isn't whether your product is a root-cause solution or a symptom-solution; it's whether you know which one it is and have built your scope accordingly.
A symptom-level product needs to be priced and positioned differently than a root-cause product. It will have different retention dynamics — people will use it when the symptom is acute and stop when it isn't. That's fine, but it shapes everything from how you build the MVP to how you think about monetization.
What's not fine is building a symptom-solution and expecting root-cause retention. Jasmine's résumé builder was a decent symptom-solution — but she priced and expected it to behave like it was solving the fundamental problem. The mismatch between what it actually did and what she expected it to do is where it fell apart.
Describe the core problem your product claims to solve. The advisor will run multiple Five Whys chains from that starting point, exploring different causal paths — and then map where your product's actual intervention sits in each chain. Your job is to engage honestly with what that reveals.
This will sometimes be uncomfortable. That's the point. Better to find the mismatch now than after you've built the thing.
Theo spent his junior year planning a platform that would connect college students with local small businesses for freelance work — a kind of "Upwork but for hyperlocal campus talent." He had the full vision mapped: profiles, reviews, payment processing, dispute resolution, categories for design, writing, video, social media, coding, tutoring.
He never built it. Every time he sat down to start, the scope was so large that "starting" felt meaningless. He'd open Figma, sketch for two hours, realize he hadn't designed the payment flow yet, and close the laptop.
A friend who heard the pitch asked a different question: "What's the first transaction you need to make happen? Like, what's the first dollar from the first student to the first business — what does that actually require?"
Theo thought about it. The first transaction required: a way to post a job, a way to apply, and a way to pay. That's it. No ratings. No categories. No dispute resolution. He built that in two weeks. Forty-three students used it in its first month. He figured out the rest from watching them.
The term "MVP" — minimum viable product — has been so overused and misused that it's worth just defining it from first principles. An MVP is not a cut-down version of your vision. It's not a prototype. It's not a landing page that says "coming soon."
An MVP is the smallest possible thing that actually delivers the core value to a real user. The word "viable" is doing the real work in that sentence. A viable product is one that someone can use to solve their problem right now — not a demo, not a teaser, not a "we'll build the real version later." It's genuinely useful to the person it's for, even though it's missing most of what the eventual product will have.
Theo's two-week version was an MVP. It was missing most of what he'd planned. It was also genuinely useful — 43 people used it to complete real transactions. That's the standard.
The most common MVP mistake isn't building too little — it's building too much in the wrong direction. People strip out features but keep complexity. They remove the "extras" but the core is still overbuilt for what a first user actually needs. Ask not "what can I remove?" Ask "what's the minimum the first transaction requires?" Those are different questions.
Theo's friend gave him the right question without knowing it had a name: the First Transaction Framework. The idea is to identify the single most important transaction your product enables — the moment when value actually transfers — and then ask what is strictly necessary for that transaction to occur.
Everything that isn't strictly necessary for the first transaction is a later version. Not never — later.
The framework forces clarity because it makes you identify what "value transfers" actually means for your specific product. If you can't articulate the first transaction in one sentence, you haven't scoped the product yet. You're still scoping the vision.
By this point in the scoping process, you have a specific customer, a specific root problem, and a general sense of your solution. Now you need a concrete first version. This is where AI tools are genuinely powerful — but again, only if you're prompting them to constrain rather than expand.
The prompt structure that works: describe your full product vision, then ask AI to identify the single minimum-viable version that delivers the core value — defining "delivers the core value" as "enables the first transaction." Then ask it to argue for cutting each non-essential feature, one at a time, and to tell you why each one is probably not strictly necessary for v1.
Most people use AI to brainstorm features. Using it to argue for removing features is counterintuitive but far more useful at this stage. You want an adversary, not a brainstorm partner. Ask the AI to tell you what you can cut, not what you should add.
For your current idea, write down: (1) the full feature set you're imagining; (2) the single first transaction you want to enable; (3) the features strictly required for that transaction. Everything outside column 3 goes on a "later" list, not a "never" list. Build column 3 first. Then evaluate everything else based on what you learned from real users.
The entire arc of this module has been about a single underlying skill: forcing your idea through a sequence of increasingly specific questions until you arrive at something real enough to build and test. Customer → problem → root cause → minimum viable first transaction. That's the chain.
What changes when you complete that chain is not the quality of the idea — it might not even be a better idea than what you started with. What changes is the relationship between your idea and your ability to learn. A scoped idea generates learning. A vague idea generates more ideas.
Theo didn't know if his two-week MVP was going to work when he built it. He didn't have research proving that students wanted to hire local freelancers. He had a specific product doing one specific thing for a specific person, and he found out by shipping it. That's the only way to actually know.
Scoping isn't about being right. It's about building something small enough that you can find out whether you're right before you've spent six months being wrong.
Describe your product's full intended scope — all the features, all the functionality. Then work with the advisor to identify the First Transaction and strip everything else to a "later" list. The advisor will push back on every feature you try to include in v1 and demand justification in terms of the first transaction. Your job is to defend what's truly necessary and concede everything else.
By the end of the session, you should have a v1 spec you could actually build in 4–6 weeks.