Choosing Your MVP: Letting AI Expand the List So You Can Make the Cut

You’ve got an idea for an app. Let’s call it a tool that helps freelance dog walkers manage their schedules. You sit down to figure out what goes in version one, and the blank page stares back. So you do the reasonable thing: you ask AI to give you a feature list for a dog-walker scheduling app. Thirty seconds later you’ve got a beautiful list. Calendar sync, automated invoicing, GPS route tracking, client messaging, photo sharing, recurring bookings, a review system, push notifications, payment processing. It looks comprehensive. It looks like a real product.

And that’s the trap. The list looks like an answer, but it’s actually just a pile of possibilities with no priorities attached. You read it, nod, and start thinking maybe you should build most of it, because it’s all right there and it all sounds useful. The lazy version of this job isn’t asking AI for features. It’s letting the list AI hands back quietly become your scope. You didn’t decide to build twelve things; you just failed to decide not to.

What this job actually is

Choosing your MVP is two different jobs wearing one coat. The first job is generating possibilities: what are all the things this product could conceivably do? That’s a breadth problem, and breadth is exactly what AI is good at. It can brainstorm wider than you can, surface features you’d never have thought of, and do it without getting attached to any of them.

The second job is making the cut: deciding which small handful of those features actually ships in version one, and (this is the hard part) which ones you deliberately leave out. That’s not a breadth problem. It’s a judgment problem. It depends on who your first users really are, what single thing has to work for the product to be worth opening at all, what you can afford to build before you run out of money or patience, and what you’re willing to look unfinished about.

Here’s the distinction that matters: AI can generate the candidate features, but the cut is yours. A longer list is not a better list. The value of an MVP comes almost entirely from what you chose to exclude, and exclusion is a decision about your specific users and your specific constraints. AI doesn’t know your runway, your users, or what you’re trying to prove first. Handing it the cut would mean letting a system that knows none of that decide the one thing that defines your product.

How to delegate the generation well

So lean on AI for the part it’s good at: go wide. Don’t ask for “the features for my app,” because that quietly invites AI to pre-prioritize, and you’ll get back a tidy list that smuggles in someone else’s idea of what matters. Instead, ask it to expand. Ask for every feature a product like this could plausibly have, grouped by the job each one does for the user. Ask it to push past the obvious into things you might not have considered. Ask it for features that competitors have, features that would delight a power user, features that would help a complete beginner.

The goal here is range, not a recommendation. You want the widest honest menu you can get, because you can only make a sharp cut if you can see everything you’re cutting from. A good delegation produces a list that’s almost uncomfortably long, organized clearly enough that you can reason about it.

Tell it about your product and your users so the possibilities are relevant, but stop short of asking it to rank or choose. The moment you ask “what should I build first,” you’ve handed off the cut. Keep the ask firmly on generation: show me everything, organized, so I can decide.

The judgment you keep

The cut is the whole job, and it’s yours alone. Looking at that long list, you have to decide the one thing your first version must do well, and then you have to be ruthless about everything that isn’t in service of that one thing.

This is hard because most of the features on the list are genuinely good ideas. Cutting bad features is easy. The judgment is in cutting good features, the ones that would help, the ones a user might ask for, because they’re not essential to the single thing version one has to prove. For the dog-walker app, maybe the entire product lives or dies on whether scheduling a recurring walk takes ten seconds instead of two minutes. If so, invoicing and photo sharing and reviews are all good ideas that don’t ship yet, and saying no to them is the work.

AI can’t make this call because it doesn’t know what you’re betting on. It can’t feel the difference between a feature that’s nice and a feature that’s load-bearing for your specific users, because that difference lives in context AI doesn’t have: your budget, your timeline, the one user you’re building for first, the thing you most need to learn from shipping. Get the cut wrong and you build a bloated version one that took twice as long and still doesn’t clearly do anything. The cut is where the product gets its shape.

Before you ship this job

Here’s what good delegation looks like, and what it can’t include.

The sample prompt. A real prompt you might use:

I’m building WalkWise, a scheduling app for solo freelance dog walkers. My main user is someone like Priya, who walks twelve regular dogs a week, manages everything from her phone between walks, and currently juggles texts and a paper notebook. I’m a solo developer and I want to understand the full landscape before I scope version one. List every feature WalkWise could plausibly include, grouped by the user job it serves (scheduling, client communication, payments, record-keeping, growth, and any categories I haven’t thought of). For each feature, one sentence on what it does. Go wide; include obvious table-stakes features, power-user features, and things competitors offer. Don’t rank them or tell me what to build first; I just want the complete menu.

Use this prompt and you get a map. Copy it as-is and you’ve let me choose your features, not you. The product is Priya’s, not mine, and the menu only matters if it’s drawn around her.

The part you can’t hand off is the cut: which small set of features ships in version one, and which good ideas you deliberately leave on the floor because they don’t serve the one thing your first version has to prove.

How to check AI did its part: scan the list for the obvious features a competitor already has and confirm they’re present. If AI quietly skipped table-stakes features (the boring, expected ones), the list isn’t wide enough to cut from, and you’re choosing out of a sample someone already narrowed. A menu with gaps will push you toward the wrong cut.

What you get for doing it this way

Go back to that blank page and the tempting thirty-second list. The difference between letting AI’s list become your scope and using it as raw material is the difference between a version one that’s a vague pile of half-features and one that does a single thing convincingly. When you let AI go wide and you make the cut yourself, you ship something smaller, faster, and clearer, and you actually learn whether the thing you were betting on is true.

AI can hand you every possibility there is. Which ones become your product is the one decision that was always going to be yours. That’s the whole job: let the list get long, then have the nerve to make it short.