Why relaunches exist
Products change. The version you launched in spring might have been a rough first cut; by autumn it might have a new core feature, a redesign or a different audience. Making people pretend that's a new product, with a new name or a new domain, helps nobody: not you, not the people who backed it, and not the visitor trying to work out what the product is today. So a product can launch again, as itself, and its pages stay connected.
The rule is simple: 12 weeks after the week of its last launch, a product can be submitted again, with a short note on what's new.1 The gap keeps the board from filling up with the same products every month, and it's long enough for a real update to happen in between.2
When you submit, we recognise the product by its website.3 If it launched before, the submit panel tells you, shows when the earliest possible week is, and asks for the 'What's new' note before you can continue. If you try too early, it tells you which week you can come back in.
What a relaunch looks like
A relaunch is a normal launch in almost every way. It goes into a week, starts at zero votes and is ranked against that week's launches, not against its own past. Its earlier results don't carry over, good or bad. Three things are different.
- It carries a 'What's new' section, written by you, near the top of the launch page.
- Its page lists the product's earlier launches, with the week and the rank each one finished at.
- On the board it shows a small Relaunch label, so visitors know the product has history here.
Earlier launch pages don't disappear. They stay up with their own rank and comments, and a note at the top points to the newest launch. The newest launch becomes the page for the product, so search engines are pointed at it and the product's presence in search builds on one page instead of being split across several.
Who hears about it
People who upvoted an earlier launch of your product can get an email when you relaunch, if they've . The first time someone upvotes anything, we ask whether they'd like to hear when the launches they upvote come back. Those who say yes get one short email on the Monday your relaunch goes live: what's new, how the last launch went, and a link to the new page.
This is the main reason to relaunch rather than quietly update your page. The people who backed you the first time get to see what you've done since, and they're often the ones most likely to try it again. It's also why the 'What's new' note matters so much: it's the first thing they read, in the email and on the page.
Is your update worth a relaunch?
A useful test is to picture someone who tried your product last time and left. Would this change make them want to try it again? If the honest answer is yes, it's worth a relaunch. If the change is mostly invisible to the people using the product, it probably isn't, however much work went into it.
Usually worth it
- A major new capability that changes what people can do with the product.
- A rebuild or redesign that fixes the reasons people didn't stick around the first time.
- A new platform: a mobile app, a desktop app, an API or an integration people asked for.
- A change to how the product is sold that opens it to a different audience, such as a new free plan.
Usually not
- Bug fixes and performance work, however much effort they took.
- A new logo or landing page with the same product behind it.
- A handful of small features that only make sense read together in a changelog.
If you're not sure, wait. You can always relaunch later with a bigger change, and there's no penalty for letting more than the minimum gap pass. A relaunch with one clear reason to look again tends to land better than an early one with a vague list.
What can go wrong
The most common mistake is submitting the product under a different web address than before, such as a new subdomain or a landing page on another site. Because products are matched by their website, the relaunch won't connect to its history: no earlier launches on the page, no Relaunch label, and no email to past upvoters. If your product has moved, submit it with the address people actually use today, and check that the submit panel recognises it as a relaunch before you continue.
Writing the 'What's new' note
Keep it short and concrete. Lead with the change that matters most, say who it's for, and leave out version numbers and internal names. Two or three sentences is usually right. Compare these two:
Version 2.0 is here with lots of improvements, a refreshed UI and better performance across the board.
Loomly now turns a meeting recording into tasks, not just written notes, and assigns each one to whoever was speaking.
The second tells someone who voted last time exactly why to look again. That's the whole job of the note. Before you submit, read it as if you'd never heard of the product: if it still makes sense and still gives a reason to click, it's ready.
Everything else about preparing the page applies as it did the first time. If it's been a while, a launch page that works is a good checklist to run through, and the support page has the short version of the relaunch rules.