Build version two four to eight weeks after launch, once a few weeks of real usage have shown where users drop off and what retained users ask for. It should be small: two or three changes that address the largest drop-off or the most repeated request, plus fixes and a share of technical debt. The original feature list is an input, not the plan. What users did in version one decides what version two contains.
The second release is where a product either starts learning or starts drifting. Founders arrive at it with a long list written before launch and a shorter list written by users, and the two rarely agree. This post is about how to choose, how much to build, and when.
When: four to eight weeks after launch
Too soon and you are reacting to the first three users. Too late and early adopters conclude the product is abandoned. Four to eight weeks gives you several weekly cohorts of data, twenty conversations, and a feedback pile large enough to show patterns. Plan the release before launch so that budget and team are ready, then decide its contents from evidence in weeks three and four. Our post on why apps fail after launch puts this in the ninety-day plan.
What goes in: the three sources
| Source | What it tells you | Weight in version two |
|---|---|---|
| Where users drop off | The step in the core journey that loses the most people | Highest. Fixing the biggest leak improves every metric downstream. |
| What retained users ask for | The next thing people who already get value want | High, when the same request comes from many people. |
| What users who left say | Why the product did not deliver for them | Medium. Useful if they were your target user, a distraction if they were not. |
| The original feature list | What you believed before launch | Low. Promote items only when evidence agrees. |
| Bugs and technical debt | What is slowing users and the team down | A fixed share, every release. |
How to decide
- Find the biggest drop-off. In the analytics, where in the core journey do most users stop? That is the first item.
- Count the requests. Sort the feedback pile. Anything asked for by many retained users is a candidate. Anything asked for by one loud user is not, however loud.
- Interview the leavers. Ten people who signed up and stopped. If they match your target user, their reason is a candidate. If they do not, adjust the targeting instead of the product.
- Check the original list. Anything on it that the evidence now supports moves up. Everything else stays on the later list.
- Choose two or three. Not ten. A small release ships in weeks and can be measured. A large one ships late and you cannot tell which change did what.
- Add the fixes and the debt. Bugs users hit, and ten to twenty percent of the effort on the technical debt list. See what technical debt is.
How big should it be?
Two to four weeks of work. If the list needs more, split it into two releases. Frequent small releases teach you more than infrequent large ones, keep early users engaged, and let you measure each change. The instinct to make version two impressive is the same instinct that made version one too large. Resist it with the same tool: the MVP method applies to every release, not only the first.
What version two should not be
- The rest of the original plan. The plan was written without users. You have users now.
- A response to the loudest user. One person's request is an anecdote. Many people's request is a signal.
- A redesign. Unless activation data shows the design is the leak, a redesign is expensive and immeasurable.
- A second platform. Do not build the Android app because it seemed like the obvious next step. Build it when the data shows Android users on your waiting list or your web app.
- Everything at once. If you cannot tell which change moved the number, you learned nothing.
How to measure whether it worked
Before the release, write down which number each change is meant to move: activation for a drop-off fix, retention or frequency for a feature. After the release, compare the next cohorts to the previous ones. Changes that moved the number stay and get built on. Changes that did not are information too. Our post on which metrics to track covers the numbers.
The rhythm after version two
Version two sets the pattern: a release every two to four weeks, each decided from the previous one's evidence, each measured. Founders who establish that rhythm early find that the product improves steadily and that the roadmap writes itself. Founders who make version two a big event tend to make version three one as well, and the gaps between them are where users leave.
How 7L plans the second release
We plan version two with the founder before version one ships, so that budget and team are ready, and we fill it in from the evidence in weeks three and four. After that, most founders move to a retainer with a release every few weeks, decided at the weekly review. It is the most productive phase of most engagements, and the one that first-release budgets most often forget. Ask us how it works.
Frequently asked questions
What if users ask for something completely different from what I built?
Listen carefully, because it may be the real product. Check whether the people asking are your target user and whether they would pay. If yes, that is not a version two feature, it is a change of direction, and it deserves its own validation before building.
Should version two include the features I promised early users?
If you promised them, yes, or explain honestly why not. But check whether those users still want them now that they have used the product. Priorities often change once the thing exists.
How do I handle a long list of small requests?
Group them. Ten small requests about the same screen are one item about that screen. Fix the group, not the individual requests, and the list shrinks quickly.
Is it too early to add paid features in version two?
If retention shows users get lasting value and you have not charged yet, version two is a reasonable moment to introduce pricing. If retention is weak, fix that first. Charging for a product people do not return to tells you only what you already know.
What if I have no budget for version two?
Ship the fixes and the single biggest drop-off improvement, which are usually small, and use the evidence to raise or earn the budget for the rest. A product that visibly improves after launch is easier to fund than one that has stalled.