The launch is over. You have shipped a product, answered some questions, and watched the initial attention settle. The next task is finding repeatable ways to reach people who have the problem your product solves.

Start with two channels: one close to your existing users and one that helps new people discover you. Give each channel a specific job. The plan below is an editorial starting point, not a promise of traffic, signups, or revenue.

Start with users who have a reason to care

If a customer asked for the feature you just shipped, that is a useful conversation to resume. Tell them what changed, explain how to try it, and ask whether it addresses the original problem. Use the communication permissions they have given you.

For a wider product announcement, segment by relevance. An account administrator may need a permission update; a developer may need an API change. Sending the same generic announcement to everyone can obscure the information that matters.

Choose one destination for the full explanation: your documentation, a release page, or a public product update. That makes follow-up questions easier to answer and gives the announcement a life beyond a single message.

Make ongoing progress discoverable on ShipFeed

ShipFeed gives software products a public page and a timeline of approved updates. Use it when you have a concrete change, launch, or milestone to explain. A product profile provides context; subsequent updates show how the product evolves.

Describe the actual advancement, who benefits, and any availability limits. Do not treat every week as a reason to repeat the same sales pitch. The useful story might be a new integration, a redesigned workflow, or a milestone with a clear explanation of what it means.

For a structure you can reuse, see our product-update template and examples. ShipFeed reviews submissions; publication and attention are not guaranteed.

Use communities to answer relevant questions

Look for places where your intended users already discuss the problem. Read the rules and recent conversations before posting. A practical answer, demonstration, or explanation of a tradeoff can be more useful than a product link with no context.

Be clear that you built or work on the product. Explain how it helps with the question being discussed, and acknowledge when it does not fit. If a community does not allow promotion, respect that rule. This applies whether the community is on Reddit, a forum, a developer platform, or an independent Slack group.

Keep a small record of questions people ask repeatedly. Those questions are candidates for documentation and blog posts. They can also reveal a product problem that better promotion will not fix.

Treat Hacker News and Product Hunt as distinct channels

Show HN's guidelines are specific: people should be able to try something you made. Routine feature updates and blog posts generally do not qualify as Show HN submissions. A substantial new product or overhaul may fit; a useful article belongs in a normal submission if it fits the site's broader rules. Read the current guidance before posting, and be available for discussion.

Product Hunt's launch guide describes launches around significant product iterations and community participation. Use a meaningful new version as a reason to consider another launch, rather than reposting unchanged work. The guide also says not to ask people directly for upvotes. Invite relevant discussion and feedback instead.

Neither platform replaces an ongoing relationship with users. Treat a launch as one distribution event with preparation and follow-through.

Publish useful content that stands on its own

Write about a problem your audience needs to solve: a workflow, an evaluation checklist, a migration, or a decision between approaches. Include examples you can demonstrate. Link to your product when the connection helps the reader, and disclose your involvement.

One useful reference is Marko Saric's July 2020 account of Plausible's early marketing. He described narrowing the team's channels and creating material around its audience's concerns. Those are historical observations from one company, not expected results for yours.

Start with one article you can maintain. A focused explanation with screenshots or an original example is a better use of limited writing time than a long list of thin pages.

Give technical changes a technical destination

If your audience is developers, publish accurate release notes alongside the software. GitHub releases can package a version, notes, and downloadable files. Documentation should explain breaking changes and required action.

A customer-facing post can explain the benefit, while the release notes explain the technical details. Link the two when both are relevant. Avoid turning a version bump into a business benefit it does not actually deliver.

A manageable four-week experiment

  • Week 1: Write one clear update and share it with the users it affects.
  • Week 2: Answer a relevant community question, following that community's rules.
  • Week 3: Publish one guide drawn from questions you have actually encountered.
  • Week 4: Review useful actions and decide which channel deserves another cycle.

For each channel, record the message, destination, audience, and result. Useful actions might include a completed signup, a product submission, or someone trying the feature. Raw pageviews provide context but do not prove the visitors were a good fit.

Choose the next action based on what you learn. Keep a channel that brings relevant conversations or product use. Adjust one that generates attention without useful follow-through. Your goal is a repeatable way to reach the right people as the product keeps improving.