Also known as story notes · development notes
Feedback on a draft -- from a room, producer, manager, or peers -- meant to improve story, clarity, or market fit. Giving and receiving notes is a core development skill.
Good notes cite a problem on the page: a soft want, a muddled midpoint, a joke that explains itself. Vague vibes without a scene reference are hard to act on. When you give notes, separate taste from clarity -- "I was lost at the act break" is more useful than "make it cooler" with no pointer to where the engine slipped.
When you receive notes, translate them before you rewrite. Ask what problem the note is trying to solve, then choose a fix that protects the story's spine. Not every note is a task; some reveal a misread you can solve with one clearer plant. Create a baseline before a notes pass so you can compare what changed after the surgery.
Process matters as much as ego management. Cluster notes by scene after a table read; do not rewrite page forty while page twelve still confuses everyone. Polish addresses line quality once structure holds; a page-one rewrite answers notes that break the engine. Keep the conversation about wants and turns, not about defending every line you love.
Name the problem and where you felt it -- want, turn, clarity -- then offer options. Avoid line replacements unless you were asked for a dialogue pass.
No. Translate each note into the problem underneath, then fix that problem in a way that protects the story. Taste notes can be declined; confusion notes rarely can.
If the want, premise, or act design is wrong, stop polishing. If the spine holds and lines limp, polish. Match the tool to the diagnosis.
Cluster by scene and severity first. Fix early confusion before late cosmetics, and keep a clear baseline draft so you can see what the pass actually changed.