Product & planning
Product work goes wrong quietly. A spec that sounds complete but never says what happens on failure, a roadmap that lists everything and commits to nothing, an MVP that is just the full thing with the timeline halved. The prompts below are built to surface those gaps early. They make the model separate what is known from what is assumed, name the riskiest belief rather than the longest list, and give a recommendation with a reason attached. Use them on a request you were handed this morning, a backlog you have been avoiding, or a launch you are three weeks from.
36 prompts in 4 groups
Product & planning21 categories
Specs and stories
Turning a vague request into something a team can build: specs, PRDs, stories and acceptance criteria.
- Turn a vague request into a real specLongSomeone asked for "a dashboard" and nobody has defined what that means.
- Write user stories that are not disguised tasksLongBreaking a feature into stories a team can actually pick up independently.
- Write acceptance criteria that can be testedLongA story is ready to start and "it should work well" is currently the only criterion.
- Draft a PRD from my notesLongThe work is agreed in conversation and now needs a document people can disagree with.
- Story or task in disguise?ShortA backlog item that reads like an implementation note.
- Who is this for?ShortA feature defined by what it does, not who wants it.
- Make this request buildableMediumA one-line request from someone who wants it next week.
- Acceptance criteria for thisMediumA feature heading into development this week.
Prioritising and scope
Deciding what makes the cut and what the plan actually is: backlogs, MVPs, estimates, roadmaps.
- Cut this to fit the deadlineLongThe date is fixed, the scope is not, and someone has to decide today.
- Prioritise this actual backlogLongA real list of competing items and an argument about which comes first.
- Turn a roadmap into a narrativeLongPresenting a plan that currently reads as a list of boxes on a timeline.
- Estimate effort as ranges, not single numbersLongSomeone wants a date and you only honestly have a spread.
- Define an MVP honestlyLongWhen the "minimum" version has quietly grown into the full product.
- Cut this to one weekShortScope that has quietly grown past the time available.
- Simplest version worth shippingShortA feature spec that has grown a second and third phase.
- Is this worth building?ShortAn idea everyone likes but nobody has actually judged.
- What are we not doing?ShortSetting expectations before a release goes out.
- Order my backlogMediumA list of work with no agreed sequence.
- Kill it or keep itMediumA feature that is neither clearly working nor clearly dead.
Discovery and evidence
Checking the idea before you commit: research, feedback, competitors, risky assumptions, success metrics.
- Define success metrics for this featureLongBefore you build, so you're not inventing a metric afterwards to look good.
- Find the riskiest assumptionLongBefore committing a quarter to a plan that rests on something untested.
- Design user interview questionsLongYou have five research calls booked and one chance to not lead the witness.
- Synthesise raw feedback into themesLongA pile of interview notes, survey answers or reviews and no pattern yet.
- Tear down a competitor's productLongUnderstanding a rival properly, beyond "they have more features than us".
- Turn support tickets into product insightLongSupport volume is telling you something and nobody has read it as a whole.
- Riskiest assumption hereShortA plan that depends on something nobody has checked.
- Why would nobody come back?ShortBefore building something you assume people will love.
- What does success look like?ShortAny feature about to be built without a target.
Launch and comms
Getting a release out and told: launch plans, go / no-go, release notes, deprecations, post-launch retros.
- Build a launch planLongTwo weeks before a release, to find what nobody has picked up yet.
- Run a go / no-go checklistLongThe day before launch, when everyone assumes someone else checked.
- Announce that a feature is going awayLongRemoving something people use, and the announcement has to do the hard part.
- Write release notes people will actually readLongShipping a version and the changelog currently says "various improvements".
- Run a post-launch retrospectiveLongA week after shipping, while the details are still recoverable.
- One-line release noteShortA change that needs describing to users, not engineers.
- Release notes from a changelogMediumA pile of merged changes that needs to become an announcement.
- Ten things before launchMediumA launch date that is closer than the checklist is complete.
Got one that isn't here?
Send a prompt you keep coming back to. A person reads every one.
Suggest a prompt