Favors.dev
The short answer
To announce a pivot, tell the people who lose the most first, privately, and the public last. Paying customers get a personal email, then active free users, then your waitlist and followers, then everyone else. Every message answers the same four questions: what is changing, why, what happens to you, and by when. Ship a working data export and a refund path before you send a word, because those two things decide how people talk about you afterward.
A pivot announcement is a trust event, not a marketing event. It is tempting to treat it like a launch, with a big post and a new logo. But the people reading most closely are not prospects. They are the users who backed the old version, and they are reading to find out what you are about to take away from them.
Most advice on pivoting is about whether to do it. The Lean Startup principles describe a pivot as a structural course correction to test a new fundamental hypothesis, and that is the right way to decide. This post starts after the decision is made. It is written for a founder with a couple of hundred users, a Slack or Discord, and no comms team, who has to tell people and wants to keep their trust.
Who should you tell first when you pivot?
Tell people in order of how much the pivot costs them. Paying customers first, then active free users, then your waitlist and followers, then the public. Each ring hears it before the next one can read about it, so nobody who depends on you finds out from a stranger's post.
01Paying customersPrivate email from you, then an offer to talk · First, before anything is public
They lose the most and trusted you with money. Hearing it from a stranger's post is the version they never forgive.
02Active free usersEmail plus an in-app banner · A day or two after paying customers
They have data and habits inside the product. They need the same facts, with less hand-holding.
03Waitlist, list and followersOne short email or update · Just before the public post
They signed up for a promise that just changed. Let them opt in to the new one instead of assuming.
04The publicPost, changelog, launch · Last, with the change live
Strangers need the story, not the logistics. By now, everyone affected already has the logistics.
The order matters more than the wording. Two founders can send almost identical emails; the one whose paying customers heard it first will get replies asking questions, and the one whose paying customers read it on X will get replies asking for refunds. The same facts land as consideration or as an afterthought depending on who heard them first.
One more ring sits outside the list: the handful of people who gave you detailed feedback or championed the old product in public. If someone wrote a review or a testimonial for the thing you are changing, send them a short personal note before the public post. They put their name next to your product. They deserve not to be surprised by it. If you collected that early feedback through a structured process like the one in getting product feedback before launch, you already have the list.
What should a pivot announcement say?
Every version of the announcement, from the private email to the public post, answers four questions in this order: what is changing, why, what happens to you, and by when. The order is the point. Readers want the change and the consequence first. The reasoning is only persuasive once they know where they stand.
- What is changing.The new direction, and the thing that stops, named plainly. "We are stopping work on the browser extension" is a sentence. "We are refocusing our roadmap" is not.
- Why. One honest reason, not five. People detect a list of reasons as a search for a respectable one.
- What happens to you. Export, migration, refund, or nothing, spelled out for this reader. This is the section people actually read.
- By when. Real dates. When the old thing stops getting updates, when it switches off, when the new thing is available.
Three pivot announcement templates, annotated line by line
Here are the three messages almost every pivot needs, with the reasoning for each line beside it. Copy the structure, not the wording. Your reason and your data situation are your own, and readers can tell a fill-in-the-blanks email from one a founder actually wrote.
Template 1: the paying-customer email
Sent from your own inbox, to paying customers only, before anything else goes out. Plain text. No logo header, no marketing template.
Subject: A change to [Product], and what it means for your account
Why The subject says there is a change and that it touches their account. No teaser, no "exciting news". People should know whether to open it now.
Hi [Name], I'm writing to you before anyone else hears about this, because you pay for [Product] and this affects you first.
Why Tells them why they are hearing it privately. The order you tell people in is itself part of the message.
Starting [date], [Product] will focus on [new direction]. [Old feature or use case] will stop being developed, and it will switch off on [date].
Why What is changing, with dates, in the first paragraph. If you bury this under the backstory, the reader skims for it and resents the scroll.
The honest reason: [one or two sentences, e.g. not enough people used it for us to keep it good].
Why One real reason, stated plainly. Not a vision statement. The reader does not need your strategy deck; they need to believe you.
Here is what happens to you: you can export everything from Settings → Export, today, in [format]. If [Product] no longer fits, reply and I'll refund [the unused months / your last payment], no questions.
Why The most important line in the email. Export first, refund second, both concrete. This is the paragraph that decides whether people speak well of you afterward.
If you'd rather talk it through, reply to this email. It comes straight to me.
Why A real reply path to a real person. Do not send this from a no-reply address, ever.
Template 2: the public post
For your blog, changelog, X or LinkedIn, published only once everyone affected already knows. Short. The logistics went out privately.
[Product] is changing direction. From today it's [one line on what it is now] for [who it's for now].
Why The new direction in the first line. A stranger should understand what the product is now without reading the rest.
We started out building [old thing]. After [a concrete signal, e.g. a year of watching how people used it], it was clear [the part that worked] mattered more than [the part that did not].
Why The why, in terms of what you learned, not what failed. Specific enough that someone could disagree with it.
Existing users have already heard from me directly, and everything they built can be exported.
Why One sentence that tells the public you handled the people affected first. It answers the question every reader is silently asking.
If [new direction] sounds like your problem, here's where to start: [link].
Why One ask, and it is for the new audience. Do not ask the old audience to celebrate a change that cost them something.
Template 3: the reply to "so you're abandoning us"
You will get this message, usually within a day, usually from someone who liked the old product a lot. Answer it personally and within hours.
You're right that this changes things for you, and I'm sorry it does.
Why Agree with the part that is true before anything else. Arguing with the feeling is how a reply turns into a screenshot.
I made the call because [the one real reason], and I'd rather tell you straight than keep something running badly.
Why Same reason as the email, word for word if you can. Consistency is what makes it believable.
Your data is yours: [export path]. If you want a refund for [period], say the word and it's done today.
Why Repeat the concrete help even if they had it in the email. Upset people do not read the second paragraph.
If it helps, [alternative tool] does [old use case] well. I'd rather you land somewhere good than stay somewhere that no longer fits.
Why Pointing someone at an alternative feels like losing a customer. They were already lost; this keeps the relationship.
Notice what the paying-customer email does not contain: a link to the new product. If the new direction might suit them, say so in a second message a few days later, once they have had time to export, ask questions or leave. Asking someone to buy into the new thing in the same breath as telling them the old thing is going away reads as a sales email with bad news attached.
What not to say: three framings that read as spin
Spin is any line that makes the change sound better for you than it is for the reader. Three framings show up in nearly every weak pivot announcement, and each has a plain replacement.
| Reads as spin | Say this instead | Why |
|---|---|---|
| “We have some exciting news to share!” | “We're changing direction, and here is what it means for you.” | Excitement is yours, not theirs. For the person losing a feature, it is not news they would describe as exciting. |
| “We're evolving to better serve you.” | “We're stopping work on [feature] and focusing on [new thing].” | "Evolving" and "doubling down" hide what stopped. Name the thing that is going away. |
| “Nothing changes for existing users.” | “Here is exactly what changes for you, and when.” | Almost never true, and the first person it is false for will say so in public. If nothing really changes, say what is guaranteed and for how long. |
The word "pivot" itself can be spin. It sounds strategic, which is why founders reach for it, but on its own it tells the reader nothing. "We pivoted" could mean a new market, a new pricing model or a rewrite from scratch. Use the word in the headline if you like, then immediately say what it means in concrete terms. Readers who get the detail stop wondering what you are not telling them.
What happens to the users the pivot leaves behind?
Every pivot leaves some users behind, and you have four options for them: keep the old product running frozen, sunset it with a data export, migrate them into the new product, or refund them and part ways. Most pivots use two of these at once. The mistake is choosing none of them and hoping the old users quietly drift off.
| Option | When it fits | What to tell them |
|---|---|---|
| Keep it running, frozen | The old product is cheap to host and a few users depend on it | Say it gets security fixes only, and for how long. "Frozen" without an end date reads as a promise to run it forever. |
| Sunset with export | Most pivots. The old use case stops, the data leaves with the user | A shutdown date, a working export, and a reminder email a week before the switch-off. |
| Migrate them | The new product covers most of what the old one did | Move their data for them and say what did not survive the move. Silent gaps are what people find on day two. |
| Refund and part ways | Annual plans, or anyone who paid for something that is going away | Offer it before they ask. A refund you had to be argued into costs the same money and none of the goodwill. |
The data export is the point most founders miss. It feels like a nice-to-have while you are busy building the new thing. It is actually the single line that turns "they shut it down on me" into "they shut it down, but they were decent about it". Build the export before you send the email, test it on a real account, and put the path to it in the first message, not in a help article.
In some places it is also not optional. GDPR Article 20, the right to data portability, gives people in the EU a right to receive the personal data they provided in a structured, commonly used and machine-readable format. The UK regulator's ICO guidance on data portability says requests should be answered without undue delay and within one month. A CSV or JSON download that works on the first click handles both the law and the goodwill.
Refunds follow the same logic. Offer them before anyone asks, particularly to annual subscribers who paid for a year of something that is ending in three months. The money is the same either way; only the offered version earns you anything.
The public post: how much of the reasoning should you share?
Share enough that a stranger understands what changed and could disagree with why, and no more. One concrete reason, one sentence on how you handled existing users, one line on who the new direction is for. The full internal story belongs in a longer write-up later, if at all.
The two failure modes sit at opposite ends. Too little, and the post reads like a rebrand with something hidden underneath. Too much, and it becomes a confession that makes readers wonder whether the new direction will last any longer than the old one. A useful test: if a sentence is there to make you look good rather than to help a reader decide whether the product is for them, cut it.
Your public profile carries the story after the post scrolls away. On Favors.dev, your founder profile lists every project you have shipped, and anyone who follows you there gets an alert when you post a new one. A pivot that becomes a new project reaches the people who already chose to keep up with you, without a single cold post. Update your app listing on the same day, so the description matches what the product is now rather than what it was.
Should you announce a pivot before the change, or with it?
Both, to different people. Anyone who depends on the old product hears about it before anything they use changes, with enough runway to export and find an alternative. The public hears about it with the change, when there is something new to look at. Announcing publicly before the new direction exists gives strangers nothing to try and gives existing users a reason to leave early.
In practice that means a sequence over a few weeks: private emails first, an in-app notice for everyone still using the old version, a reminder shortly before any switch-off, and the public post once the new version is live. If the pivot is really a relaunch of the same product for a new audience, the relaunch readiness scorecard will tell you whether it has changed enough to announce as one. And for the channel-by-channel plan for the public side, read the complete guide to relaunching a product.
The public post is also where the new direction gets its first real users. That is where Favors.dev helps: it is a founder marketing co-op with a points economy, so founders who have never seen your product earn points for trying the new version, leaving honest feedback and sharing it. The old users got the truth privately. The new ones get a fair first look.
Frequently asked questions
How do you announce a pivot to users?
Tell the people who lose the most first, privately, then widen the circle: paying customers by personal email, active free users by email and an in-app notice, your waitlist and followers next, and the public last. Every message answers four things: what is changing, why, what happens to the reader, and by when. Give a working data export and a refund path before anyone asks for them.
Should you tell customers before announcing a pivot publicly?
Yes. Paying customers should hear it from you, directly, before any public post exists. Finding out from a launch post or a tweet tells them they were an afterthought, and that is the part people remember long after the pivot itself stops mattering.
What should a pivot announcement email say?
Four things in this order: what is changing and on what date, the one honest reason, what happens to the reader's account and data (export path, refund or migration), and how to reach you directly. Send it from a real inbox as plain text, and skip the "exciting news" framing.
How much notice should you give users before a pivot?
Enough for them to leave comfortably if the new direction is not for them. Tell people before anything they depend on changes, and give a switch-off date far enough out to export and find an alternative, with a reminder before it. Anything shorter feels like an ambush, whatever your reasons were.
Do you have to let users export their data when you pivot?
You should, whatever the law says, because a working export is what makes a pivot feel fair. In the EU and UK it can also be a legal duty: GDPR Article 20 gives people a right to receive data they provided in a structured, machine-readable format, and the UK ICO says requests should be answered within one month.