What to change before relaunching a product: a scorecard that can say no

Most relaunches fail for one of two reasons. The founder changed the marketing and not the product, or changed the product and not the story. Both look like a relaunch from the inside. From the outside, both look like the same thing you already scrolled past.

This is the audit I run before calling anything a relaunch. It has a pass line, and it is willing to tell you no. If the answer is no, there is a six-week plan further down that turns a not-yet into a relaunch with a real story behind it.

Why do most relaunches fail? New copy, same product

Because the thing that changed is invisible to the people you are asking to look again. A founder spends a month on a new landing page, a new name and a new logo, then relaunches to the same audience with the same features underneath. Anyone who tried v1 clicks, recognizes it, and leaves. The launch did not fail because of timing. It failed because there was nothing new to see.

The mirror-image mistake is quieter and just as common. A founder spends three months rebuilding the core of the product, ships something genuinely better, and then announces it with the old tagline and the old screenshots. The work is real. The story never tells anyone about it.

Launch platforms are built to filter out the first mistake. Hacker News says in its FAQ on reposts that a small number of reposts is fine only if a story has not had significant attention in the last year or so, and that otherwise it buries them as duplicates. Product Hunt draws its line around a significant update, and I covered its exact rules in how to relaunch on Product Hunt. Different rules, same message: a relaunch has to be a different thing, not the same thing again.

What should you change before relaunching? The five categories

Everything worth changing before a relaunch falls into one of five categories. Product and audience are the load-bearing two: one of them has to move for a relaunch to be honest. Positioning, pricing and proof are how you make that move visible.

Product is the most obvious and the most abused. Speed improvements, bug fixes and a nicer interface are good work, and your current users should hear about them in a changelog. They are not a relaunch. A relaunch-grade product change is a new capability: something a v1 user would name without being prompted.

Positioningis what you are the better alternative to. If v1 was pitched as "a simpler spreadsheet" and v2 is pitched as "the replacement for the weekly status meeting", that is a real change, even if half the code is the same. A new tagline that still describes the same thing to the same person is not.

Pricing counts when the buying decision looks different, not when the number shrinks. A free tier that did not exist, a team plan for a buyer you never sold to, or a switch from subscription to one-time are material. A discount is not. If you are unsure how to restructure, the early SaaS pricing guide walks through the models and when each one fits.

Audience is the category founders forget they can change. The same product aimed at a different user, reached in different rooms, is a genuine relaunch to everyone in those rooms, because they have never seen it.

Proofis what v1 could not have had: named users, reviews, a real usage number, a before-and-after from an actual customer. It rarely justifies a relaunch alone, but it is the difference between "trust me, it is better" and "here is who it is better for".

The materiality test: could a v1 visitor tell in ten seconds?

A change is material if someone who saw your first launch could spot it within ten seconds of landing on the new page, without reading the description. Ten seconds is roughly how long a returning visitor gives you before deciding they have seen this before.

Run it for real, not in your head:

1. Put the v1 and v2 pages side by side. Use an old screenshot or the Wayback Machine if you have already replaced it. Look only at what shows above the fold: headline, first image, the primary button.
2. Show them to someone who used v1.Ask one question: "What is different?" Start a timer.
3. Write down their answer, word for word.If it names a capability or a user ("it works on my phone now", "it is for agencies now"), you have a material change. If it names an adjective ("it looks cleaner"), you do not.
4. If they cannot answer at all, check the page before the product. Sometimes the change is real and the page hides it. That is a story problem, and it is the cheaper one to fix.

The same test works as a sentence if you cannot find a tester. Finish this line: "If you tried the first version, you could not...". A capability at the end of the sentence passes. An adjective fails. I use the same line when deciding what counts as shipping, because it is the same question: did something change for a real person?

Is your product ready to relaunch? The readiness scorecard

Score each category 0, 1 or 2. A 2 means a v1 visitor would notice it in ten seconds. A 1 means it changed, but you would have to explain it. A 0 means it did not change, or only the wording did. Be harsh. Nobody else is going to grade on a curve.

Three shapes come up again and again. A 2 on product plus 2 on proof plus 1 on positioning is a strong relaunch: new capability, evidence it works, a clearer pitch. A 2 on audience plus 2 on positioning with modest product change is a legitimate relaunch to a new market, and your first-launch audience is the wrong crowd to lean on. And a score of 4 or 5 with the points spread thin is the most dangerous result, because it feels close. It is not. It is a changelog post dressed up for a launch day.

Not ready to relaunch? What to do for six weeks instead

If you scored under the line, do not relaunch and hope. A second launch that looks like the first one spends the goodwill you will need for the real one. Spend six weeks turning the score around instead. This is the branch a relaunch checklist should have and almost never does.

1. Weeks 1 and 2

   Find out why v1 stalled

   Talk to five people who signed up and left, and five who never signed up after seeing the launch. Ask what they used instead. That answer is your next positioning, and often your next feature.

2. Weeks 3 and 4

   Ship the one change they asked for

   One capability, not a batch. Pick the thing that turns a zero into a two on the product row, and put it in front of the people who asked for it before anyone else.

3. Weeks 5 and 6

   Collect proof while nobody is watching

   Get the early users of the new capability to leave a review or a quote. Write down the real before and after. Then re-score. If you pass, you have a relaunch with a story; if not, repeat the loop.

Notice what is missing from those six weeks: a new logo, a new name, a new landing page. Those come last, once there is something worth describing. If the interviews in weeks one and two point at a pricing problem rather than a product one, swap weeks three and four for the pricing change and keep the rest.

One more thing to do while you wait: keep shipping in public. A quiet six weeks of visible progress is the best warm-up a relaunch can have, because by the time you announce it, people have watched the change happen.

What should you keep when you relaunch?

Keep everything that already earned trust or ranking: your domain, your existing URLs, your reviews, your backlinks, your old launch posts and your email list. A relaunch changes what the product is. It should not throw away the proof that people found it the first time.

• Your domain and URLs.Every link pointing at your site, and every page Google has ranked, is tied to an address. If an address has to change, Google's guidance on permanent redirects is to use a server-side 301 or 308, which it treats as a signal that the new page should be canonical. Its site move checklist covers the full process if the domain itself changes.
• Your listings. Directory and marketplace listings are where many first-time visitors will meet the new version, so update them before relaunch day, not after. That includes your Favors.dev app listing: new screenshots, a new description that leads with what changed, and the reviews you already earned, still attached.
• Your old launch posts. Leave them up. They are the before picture, and a returning visitor comparing old and new is exactly the person you want to impress.
• Your list and your early users. They are the first people who should hear what changed, ideally a week before the public does, so the first comments on relaunch day come from people who have already tried it.

In what order should you make the changes?

Change the product or audience first, then proof, then positioning, then pricing, and the page last. That order is not arbitrary. Each step produces the raw material for the next one, and doing it backwards is how founders end up with a beautiful page describing a product that does not exist yet.

1. Product or audience. The material change. Ship it, or commit to the new user, before anything else.
2. Proof. Get the change into the hands of a few real people and capture what they say. This is where your relaunch headline usually comes from.
3. Positioning. With proof in hand, you can say what the product replaces for whom, in their words instead of yours.
4. Pricing. Now you know who is buying and what they value, so you can price for them rather than for the v1 buyer.
5. The page and the launch. The landing page, gallery and first comment are written last, from everything above. If you need help with that part, the landing page copy teardown is the companion to this post.

Follow that order and the relaunch story writes itself: "We launched, we heard this, we built that, here is who it is for, and here is someone it already works for." That sentence is the first comment, the email and the tagline, all at once. For the channel-by-channel decision on where and when to relaunch, read the complete guide to relaunching a product. Then put the date on the Favors.dev launch calendar, where founders who have never seen your product earn points for trying the new version and commenting honestly. Favors.dev is a founder marketing co-op with a points economy, so that first-day attention is paid for in favors, not dollars.

Frequently asked questions