Product Hunt launch checklist: before, during, and after

Know the official launch basics

Product Hunt supports self-hunting, requires a personal account, and is free to use. Direct requests for upvotes are prohibited. A significant new iteration can be eligible for a relaunch, so launching is not necessarily a once-ever event. Check the official launch guide for current instructions.

The checklists below are editorial preparation advice. They do not guarantee placement, votes, visitors, or customers. Decide what a useful launch would teach you before preparing the announcement.

Before launch: prepare the product and materials

• Write one audience sentence: identify who the product helps and the task it handles.
• Test the first visit: open the product while signed out and complete the main action. Remove broken links and explain any account requirements.
• Prepare a concise description: show a concrete input and outcome, then mention a current limitation.
• Prepare visuals: capture the actual interface and the result people should expect. Use sample data you can safely publish.
• Review product access: make your own free and paid terms understandable at the point where visitors decide to try it.
• Choose a feedback question: ask about one decision you can change, such as the clarity of onboarding.
• Reserve response time: arrange who will answer questions and inspect reported failures.

Editorial example: for a meeting-notes tool, show fictional notes becoming an editable action list. “Turns meeting notes into actions you can review” is easier to assess than “revolutionizes team productivity.” Make the screenshot demonstrate that transformation instead of only displaying a login screen.

Keep a shared launch brief containing the current product URL, description, visuals, access terms, and known limitations. It reduces contradictions between an announcement and what a visitor actually sees.

During launch: explain and listen

Inspect the public listing and follow the product link as a new visitor. Check visual cropping, description accuracy, and whether your onboarding still works. A polished announcement cannot compensate for a blocked first task.

• Introduce why you built the product and what is usable today.
• Share the launch with a factual invitation to explore or give feedback.
• Answer questions with concrete examples.
• Record recurring confusion and reproducible errors.
• Correct inaccurate claims or broken links promptly.

A useful invitation could read: “We released a tool that turns meeting notes into editable actions. There is a fictional sample to try. I would appreciate feedback on whether the review step is clear.” Adapt it to your real product and respect the rules of any community where you share it.

When a feature request arrives, explain whether it fits your current scope. Avoid promising a delivery date merely to keep a launch conversation upbeat. For an error report, request a minimal example that excludes personal or customer information.

After launch: turn attention into decisions

Separate visits, account creation, and completed product tasks. For the meeting-notes example, measure whether someone reviews and saves an action list, not just whether they open the landing page. Compare acquisition sources only when you have actual data.

1. Group feedback into onboarding confusion, failures, and requested capabilities.
2. Choose the most consequential obstacle to the core task.
3. Fix it and retest the same first-visit flow.
4. Update your public materials when behavior or access terms change.
5. Document what you learned before choosing another distribution step.

If you later consider a relaunch, identify the substantial new experience a reader can evaluate and recheck the official guidance. For additional discovery options, use the submission comparison; for a wider plan, use the first-week promotion guide.