Update It Instead of Starting Over

Starting a second product from scratch feels like progress because it carries no evidence yet. The first one has a record. The new one is still a fantasy, and fantasies are more comfortable to work on than files with results attached.

The choice between them has real inputs, and you already hold some of them.

The signals that say improve, and the signals that say abandon

Improve when someone has used the thing. A buyer who emailed a specific complaint — a missing format, a step that failed on their machine, a section that stopped short — has handed you a work order. A refund with a reason attached is the same gift in worse packaging. So is the question you keep getting: does it also do this other thing?

Improve when the failure sits downstream of the product. If the file is sound and nobody has seen it, editing it changes nothing, and you should work out why a digital product is getting no sales before opening it at all.

Abandon when nobody engaged after you genuinely put it in front of people. Not "it did not sell" — nobody would look at it when it cost nothing. That is a demand signal, and no version two answers it.

Abandon when you dread the support. If the subject bores you now, every buyer message for the next year is a chore you volunteered for, and the product will rot because you avoid its inbox.

Versioning: what changes, what buyers are told, what stays

A version number exists so that you and a buyer can talk about the same file. Without one, every support conversation opens with working out which copy they have.

Keep the scheme dull. Small fixes get a small bump, a real addition gets a whole number. Put the version in the file name so it survives being downloaded into a folder with forty other things, and put it inside the file too, on the first page or the first tab, next to the date.

What stays fixed is the listing address, the product name and the promise at the top of the listing. Changing the name breaks every link anyone has shared and every mention you have made, so treat naming and packaging a digital product as a decision you make once and then live with.

What the buyer gets told is short: version, date, one line on what changed. Not a release essay.

Updating existing buyers for free, and what that buys you

To send an update you need a way to reach the people who bought. Check what your selling platform actually gives you — some pass on the buyer's email, some let you message inside the platform, some do neither. Find out before you promise anything on a listing.

Then decide the scope of the promise and write it in words you can live with. Free updates with no boundary means forever. You set the window, and you state on the listing what it covers, before anyone buys.

What it buys you is not gratitude. It is a legitimate reason to appear in the inbox of people who have already paid you once, which is the shortest route to a second sale that exists. That is also the argument for building an email list around a digital product instead of depending on a platform to forward your messages.

Adding rather than rebuilding, and where the line sits

Adding means another file in the same download, under the same promise. A worksheet version of the checklist. A second size. A plain copy for people whose software will not open the fancy one. The buyer who bought version one opens the folder and finds more of what they already wanted.

Rebuilding is when the promise changes. If the listing has to be rewritten to describe it, you have made a different product and given it the wrong name.

The test is the old buyer's face. If someone who paid for version one would feel cheated by version two — because it is aimed at a different person, or because what they paid for is now the small part of something bigger — you are holding a second product. Sometimes the honest move is to keep both and sell them together, which is where bundling digital products without doubling the work starts.

Keeping a change log you can point at

Put a plain text file in the download called changes, and add a dated line every time you touch the product. What changed, and what deliberately did not.

It takes a minute and it pays three times over. It answers "is this the one with the fillable version?" without you opening anything. It settles a refund conversation where the buyer is describing a fault you fixed two versions back. And it stops you re-solving something you already solved and forgot about.

Write it for a stranger rather than as a note to yourself. "Fixed thing" means nothing in six months. "Added a one-page printable summary; page numbering unchanged" means something to a buyer deciding whether to download again.

Rewriting the parts you enjoy

There is a version of this work that is procrastination in a work costume, and it has tells.

You are rewriting the parts you enjoy rather than the parts people complained about. Nobody new has seen the product since the last update, so no new information has arrived to act on. The changes are features nobody asked for, defended by an imagined buyer you invented. Or the update is scheduled for a moment that keeps sliding, and while it slides you never have to show anyone anything.

If nobody has seen version one, version two is also unseen. The file is not the constraint. The number of people who know it exists is the constraint, and no amount of editing moves that number by itself.

Before you open the file to work on it, write down the specific complaint the change answers and the name of the person who made it. If you cannot name a person, close the file and go find one.