Product planning
Make a release checklist around actual user tasks
List the tasks a person needs to finish with the feature, then check each one in a working build before anyone announces it. For every task, record what you tested, what you saw, what remains open and who decides whether the release goes ahead.
A text to start with
We plan to announce [feature name] on [target date]. People will use it to [list of user goals]. Here is what we know about the current build: [build notes and known issues]. Draft a release checklist with one row per user task. For each row, propose how to test it, what evidence to keep, what failure to look for and who should decide. Do not mark anything as passed.
Example request. Change the details to fit your situation.Release readiness worksheet
Feature: [ ] Planned announcement date: [ ] Build or version tested: [ ] User task: [ ] Tested by and date: [ ] Steps followed: [ ] Test evidence location: [ ] Result on success path: [ ] Result on failure: [ ] Result with empty input: [ ] Result when interrupted: [ ] Open issue: [ ] Issue owner: [ ] Blocks release: [yes / no] Release decision and decider: [ ] Date decided: [ ]
Failure paths that checklists skip
Include failure paths in your checks. For each task, write down what a person sees when the action fails, when a required field is empty and when use is interrupted halfway, such as a closed tab or a lost connection. Check whether anything entered earlier survives the interruption. Each row should cite evidence from a real run. Testing only with perfect sample input leaves failure paths unchecked. Mark tasks you could not try as untested instead of leaving them blank.
Ask another agent to check the result
Review this checklist. Name every task marked ready without evidence from a real run. For each row, quote what it says happens on failure, empty input and interrupted use, or note that it says nothing. List any task tested only on the success path and any open issue with no owner.
Hold a short release decision review
Give each open issue an owner and a date for its next update. Decide which issues block the announcement and which can ship with a stated limit. Walk the checklist with the people who own the tasks and record the outcome in your decision log. If a blocking issue remains, change the announcement plan before changing the checklist.