An AI PM — an AI manager that takes charge of a project on your behalf, receives requests, and produces the deliverables — can be given the exact same task, and yet one person gets what they wanted on the first try while another has it bounced back three or four times. The biggest difference is the request itself. A good request carries four things: purpose, scope, format, and examples. This post takes those four apart one by one and sets a weak request and a strong request side by side as actual sentences.
Of course, the result isn't determined by the request alone. The model's own capability, the materials you've supplied, the tools it can use, and the conversation context built up so far all play a part (an Anthropic engineering piece covers these factors together too). But of all of them, the request is the lever the user can pull most directly.
An AI PM works off exactly "as much information as it's given," just like a human PM. Handed a vague instruction, it asks back to fill the gaps — and when that back-and-forth repeats, you end up stuck polishing your request every single time. A good request cuts down that round-tripping and raises the odds of getting the right deliverable from the start.
Think of a contractor. Say only "make the living room look nice" and the contractor builds it to their own taste, then hears "this isn't what I meant." But say "a 100-square-foot living room, white wallpaper with solid-wood furniture, a budget of three million won, done by next Tuesday" and even the quote comes back precise. Vagueness isn't a kindness — it just offloads the burden of judgment onto the other party.
| Element | Question | What goes wrong without it |
|---|---|---|
| Purpose (why) | Why is this deliverable needed? | The AI picks a direction on its own |
| Scope (how far) | How far do you go, and where do you stop? | Does too little, or sprawls too wide |
| Format (as what) | Web, app, document, or research piece? | The deliverable format itself is off |
| Examples / constraints | The standard to follow and the lines to hold | No bar for "right," so rework repeats |
You don't always have to fill in all four. How much information is needed depends on the nature of the task and the context already shared. It's better to start with the leanest possible request and, if the result comes out off, trace back to what was missing and fill it in (the Anthropic engineering piece likewise recommends testing with a minimal prompt and adding to it based on where it fails). Treat the four elements less as a mandatory checklist and more as a list for working out "what was missing" when the result doesn't match what you expected.
Purpose is the criterion the AI PM uses to judge "what to prioritize." Without it, you get a deliverable that looks the part but is useless.
✓ "A company intro deck for a Series A (the funding round where an early-stage startup takes on its first serious growth capital) investor meeting next Tuesday. The goal is to show our team's execution in numbers." → It drafts around a clear standard: "number-driven structure, execution emphasized."
✕ "Analyze this data for me." → Analysis isn't the point, yet the AI might stop at summarizing the data.
Scope is the boundary line that tells the AI PM "stop here." Without it, the work either comes out too narrow and thin, or sprawls too wide and overshoots.
✓ "Just five domestic peer services — compare only their pricing policies and free-trial terms in a table. Save the rest of the feature comparison for the next step." → The number of targets, the region, and the comparison fields all have clear boundaries.
✕ "Overhaul the whole landing page (a single promotional web page)." → "Whole" means different things to different people. Copy only, or layout too — unclear.
If you don't set the format, the AI PM picks one arbitrarily. You need a document and get a web page, or the other way around.
✓ "Make this promotion into a one-page landing page you scroll through on mobile, as HTML (the basic format for building web pages). I'll share it as a messenger link." → Both the format and the sharing path are locked in.
✕ "Just organize the survey results however works." → Table, chart, or a written report — undecided, so the form the AI picks may not fit where it'll actually be used.
Examples and constraints give the AI PM a standard to measure "what counts as right" against. Without them, there's little to judge whether what it produced is on target.
✓ "Write it like this company's blog post (link attached) — short sentences, a plain declarative style. No emoji." → A reference example (the link) and a prohibition both become the standard.
✕ "Draw up a quote that doesn't go too far over budget." → "Too far" is vague; there's no telling how much is allowed.
The request alone can't carry background knowledge. Brand tone, past decisions, existing materials — rather than re-explaining them in the chat each time, it's better to upload them to Knowledge ONTLE (a repository for related materials) up front. The AI PM consults the documents here before handling a request, so putting them in ahead of time spares you from repeating the same explanations.
The more material you accumulate, the shorter your requests actually get, because the place that remembers the context moves from the chat to the repository.
Throw several requests at once and the AI PM decides the processing order on its own — and when one of them goes wrong, it's hard to tell where things went off. On the other hand, chop things too fine and you only add round trips. There's one rule for splitting: does the output of this task become the input to the next one? If so, split; if they're independent of each other, you can bundle them.
The stopping point created by splitting this way is a checkpoint — the spot where the AI PM shows an interim result and the person checks the direction. The harder something is to undo, the safer it is to put the easy-to-undo steps first.
To see how the four elements actually work, let's follow a scene of building a weekend-sale promotion page in ONTLE.
Prep. First, upload the brand guide and the last promotion page to Knowledge ONTLE, so you don't have to explain the tone and format every time.
Request (carrying the four elements). Put purpose, scope, format, and examples all into a single request.
Even bundled into one sentence, the purpose and the boundaries have to stay intact.
"In the tone of the Knowledge ONTLE brand guide, make a promotion page that uses this weekend's sale to draw existing customers back, as a single mobile HTML page. Only touch the hero and three benefit blocks, and leave the checkout flow as is. Keep the copy short, no emoji — I'll be sharing it over messenger."
First draft. The AI PM comes back with a draft, no back-and-forth asking required. Say the hero copy comes out like this:
This weekend, good to see you again A three-day-only deal you won't want to miss
The benefit blocks are laid out in the order [New-signup Coupon] → [Free Shipping on Everything] → [Loyalty Bonus Points]. The format (a single HTML page) and tone (the brand guide) were right from the start.
Revision (before and after). But look at the purpose again — this page is for "bringing existing customers back." The draft put [New-signup Coupon] at the top, which clashes with that purpose. No need to rebuild the whole thing. One small, easy-to-undo request will do.
"Just change the order of the benefit blocks. Since this is for existing customers, move [Loyalty Bonus Points] to the top and [New-signup Coupon] to the bottom."
After the revision, the order is [Loyalty Bonus Points] → [Free Shipping on Everything] → [New-signup Coupon]. The hero and the copy stay put; only the block order changed. The first draft effectively became a checkpoint, letting you steer back toward the purpose without much waste.
Publishing comes after. Only after you've visually confirmed that even the order is right do you make a separate "publish it as is" request. While things sit at the draft and revision stages there's nothing to undo, and hard-to-reverse work like publishing is held off until after the check.
Had the request been missing information, the flow would have gone differently. Leave out the format and there's no telling whether it comes out as a document or a page; drop the purpose and even when the top block of the draft is off, there's little basis to measure that it's off. A good request doesn't make the AI PM smarter — it gets the capability it already has pointed in the right direction from the start.
A follow-up question is a signal telling you what information the request was missing. Look at which of the four — purpose, scope, format, examples — the question falls under, and in your next request you can fill that spot first to cut down the round trips.
Purpose comes first. When the purpose is clear, scope naturally narrows to fit it. The other way around — setting only the scope with no purpose — and the work can still drift in an odd direction even within the set bounds.
Even a "prohibition" works. If you can't say what it should be, just spelling out what it must not be still gives the AI PM a minimal bar to measure against.
The minute you spend on a request saves you the waiting and the rework. The difference between a request that carries purpose, scope, format, and examples and one that doesn't lands fastest when you send one yourself in ONTLE.
https://ontle.kr
Written by: Jeong Yuna | Category: AI PM Stories