First 100 days: a practical reference for 2027

After launch the job changes. You stop asking people what they would do and start watching what they do. The new trap is reading a signal before it has had time to form, then acting on it, and destroying the conditions that would have produced the real answer.

The answers arrive in a fixed order. You can only read the ones that have arrived.

What to take away

The common shape: some people use it constantly, some tried it once, most did nothing much.
The most valuable conversation available to you is with someone who tried it and stopped.
Every message is a defect report, whatever it is phrased as.
You will get an alarming piece of feedback in week two and want to change something immediately.

The order the answers come in

Each question needs the one above it to be true before it means anything.

Do people arrive? A distribution question. Nothing about the product is being tested yet, and whether the channel can produce them repeatedly is a launch planning question rather than a product one.
Do they start? They arrived and began. This tests the promise and the first screen.
Do they finish once? They got a result. This is the first thing that tests the product.
Do they come back? The problem recurred and they chose you again. This is the first real signal about value.
Do they pay again? Value that survives an invoice.
Do they tell someone? They will attach their own name to it.

Most early panic comes from grading yourself on question four while only question two has enough data to read. If people are not arriving, retention numbers are decoration. Fix the top of the list and let the rest fill in.

Note also that the gaps get longer as you go down. Arrival is visible in a day. Whether the problem recurs and they return might take a full cycle of whatever their work looks like: a week, a month, a quarter. Do not shorten the wait by concluding early.

Your first group is not representative

This is worth being unsentimental about, because early cohorts flatter and mislead in a specific direction.

They came through a channel you probably cannot repeat: your own announcement, a personal introduction, a community you already belonged to. They were warm before they arrived. They know it is early and they forgive things a stranger will not. Some of them are there partly because of you rather than the product.

So their behavior is readable for some things and not others.

Question	Can the first group answer it?
Does the thing work end to end	Yes
Where does it break	Yes, and this is their most valuable contribution
Is the outcome worth having	Mostly
Will strangers understand it unaided	No, they had context
Will this channel produce more customers	No, it was a one-off
Is the price right	Only weakly, they are not neutral buyers

Use them for defect-finding and outcome-checking. Do not use them to forecast. Keeping warm and cold arrivals in separate columns from the first day is what makes any later reading possible, and it is the same separation market validation insists on.

When the result is ambiguous

The common shape: some people use it constantly, some tried it once, most did nothing much. There is no verdict in that as a total.

Stop looking at what they did and split them by who they are. Same role, same size of organization, same trigger for signing up, same channel, same level of prior pain. Then ask whether one of those slices behaves noticeably differently from the rest.

If a slice does, you have learned more than a clean average would have told you. It tells you where the product genuinely works, and it usually describes an audience narrower than the one you were aiming at. Narrowing at this point feels like retreat. It is normally the discovery you came for, and rewriting the offer around that slice is a return to offer testing with a better who.

If no slice separates and everyone behaves uniformly badly, that is a harder and cleaner answer.

Talk to the ones who stopped

The most valuable conversation available to you is with someone who tried it and stopped. It is also the one people avoid, because it is uncomfortable and because those people are hard to get on a call.

Ask badly and you get nothing. "Why did you stop using it?" invites a polite excuse: too busy, bad timing, will come back to it. How far the shape of a question decides the answer is documented at length in the guidance on writing survey questions, and it applies to one asked by email as much as to one on a form. Ask about the specific occasion instead. What were you doing the last time you opened it? What did you do the next time that came up? Did you go back to what you used before, or did you just stop dealing with it?

That last question separates two very different outcomes. Going back to the old way means you lost a comparison. Not dealing with it at all means the problem was not as pressing as everyone said, including them.

Keep it short, ask for five minutes, and do not pitch anything. You are collecting the account of an event, not a second chance.

None of this is available if leaving is hard. Where billing recurs, consent to the charges and cancellation without obstacles is the subject of the rule on negative option offers, and a customer who gives up and disputes a charge tells you nothing at all.

The support inbox is a research instrument

Every message is a defect report, whatever it is phrased as. Read them as a set rather than one at a time.

The same question three times is not a support load. It is a design fault, and answering it well for the fourth person is treating the symptom. Keep a running tally of question types. The one that repeats is the next thing to fix, and it will usually cost less to fix than to keep answering.

Pay particular attention to messages that begin with an apology. People apologize when they think they are being stupid, and they are almost never being stupid. They have found a place where the thing behaves in a way that no reasonable person would predict.

Fixing versus flinching

You will get an alarming piece of feedback in week two and want to change something immediately. Sometimes that is right. Often it is a flinch, and the cost is that you can no longer read your own data because the thing under test kept moving.

A workable discipline: change one thing at a time, and let it run a full cycle of whatever your customer's natural rhythm is before judging it. Write down what you expect the change to do first. If a change is urgent enough to skip that, it is a bug fix, not an experiment, and it should not be counted as learning.

Resist building anything substantial in this period that was not already forced by three separate customers hitting the same wall. Early feature requests are mostly people describing the tool they already know how to use.

The honest checkpoint

At the end of this stretch, sit down and pick one of three, with the evidence written next to it.

Continue as planned. People arrive, start, finish, and a meaningful number come back and pay again. You can name the channel that produced them and it still works.

Narrow it. One identifiable slice behaves clearly better than the rest. The next period is about serving that slice properly and finding more of them, which usually means rewriting the offer and re-testing the price for a different buyer.

Stop, or change the idea substantially. People arrive and do not start, or start and do not return, and the conversations with the ones who left keep naming the same thing you cannot fix.

The third option is a real result and deserves the same respect as the other two. It is also the one that requires you to have written down, earlier, what would count as evidence for it. If you did not, this is the point where you find out that you have been running a campaign rather than a test, and the only honest move is to define the condition now and go one more cycle.

Common questions

How soon can I read retention?

Not before a full cycle of whatever your customer's rhythm is has passed for the people who arrived first. Anything earlier is dominated by people who have not yet had the chance to leave.

What if almost nobody has signed up?

Then the work is upstream, in reach, and the retention questions are not yet askable. Do not turn three people into a percentage; write the fraction and go and find more.

Is it wrong to fix things in the first fortnight?

Fix what is broken immediately. Ask about what is merely disappointing. A path that fails is a defect; a path nobody completes is a question, and the two look identical on a chart.

How many cancellations make a pattern?

Fewer than you think for forming a hypothesis, more than you have for confirming one. Three people saying the same unexpected thing is worth chasing. It is not yet a finding.

Should I compare my numbers with published benchmarks?

No. A published figure came from a different offer at a different price to a different audience. Derive what you need from your own arithmetic and compare this month against last.