/KEY TAKEAWAYS
The short version
- 01The launch is the easy part. It has a date, a scope and everyone's attention. Version 2 has none of those, which is precisely why it fails.
- 02Most agencies are structured to leave. The contract ends at launch, which is the exact moment your product starts generating the only data worth having.
- 03You cannot prioritise from opinions once you have users. Instrument before launch, because retrofitting analytics onto a live product is its own project with its own invoice.
- 04The feature the founder fights hardest for in the roadmap meeting is usually the one the data shows nobody opens.
- 05Continuous does not mean a bigger team. It means a smaller one that never stops, and a pipeline that makes shipping boring enough to do on a Tuesday.
Everyone plans the launch. Nobody plans the Tuesday after it.
That is not a remark about discipline. It is a structural fact about how software gets scoped and paid for. A launch has a date, a budget, a scope and the undivided attention of every person involved. Version 2 has a vague collective sense that things should probably keep getting better, a team whose contract has ended, and a founder who has just worked out that shipping was the starting line.
Then the momentum goes. Quietly, over roughly six weeks.
Why does Version 2 fail more startups than the launch did?
Because the launch was a project and Version 2 is a habit. Almost nothing about the way you built the first one prepares you for the second.
A project has an end. You can hire an agency, define a scope, argue about it for three weeks, sign it, and receive software. That model works. It genuinely does, right up until the day the software exists.
The day after, every incentive inverts. You have users doing things nobody predicted. Support tickets that are really design feedback wearing a disguise. A dozen small changes that would each cost a competent engineer an afternoon, and no engineer to do them, because the contract ended at launch.
So the changes queue up. The queue becomes a quarterly release. The quarterly release becomes a rebuild, because by then the queue is long enough to look like a new product. That is Version 2. It fails for the same reason the original succeeded: somebody scoped it as a project.
FIG/02How do you utilize real user data to prioritize software feature roadmaps?
Start by admitting that everything currently on the roadmap is a guess. Good guesses, expensively arrived at, defended by intelligent people. Guesses regardless.
Real prioritisation runs on evidence you have to collect on purpose. Which features get opened, by whom, how often. Where people stop. What someone did in the hour before they churned, and what the ones who stayed did differently in their first week.
None of that is a dashboard you buy. It is events emitted from your own code into your own database, chosen before launch by somebody who sat down and thought about which question they would want answered in month three.
Retrofitting it onto a live product is its own project, with its own scope and its own invoice. Which is exactly why it gets skipped. And why so many roadmaps are still assembled from whoever argued most persuasively in the room.
The uncomfortable finding arrives every time. The feature the founder fought hardest for is sitting in the long tail, untouched. Someone is going to have to say that out loud.
-- The only roadmap input that is not somebody's opinion.
-- Which features did retained users touch that churned users never did?
WITH cohort AS (
SELECT
u.id,
u.created_at,
-- "Retained" = still doing something in week four.
MAX(e.occurred_at) > u.created_at + INTERVAL '28 days' AS retained
FROM users u
JOIN events e ON e.user_id = u.id
GROUP BY u.id, u.created_at
),
first_week AS (
SELECT
e.user_id,
e.name AS feature
FROM events e
JOIN users u ON u.id = e.user_id
WHERE e.occurred_at < u.created_at + INTERVAL '7 days'
GROUP BY e.user_id, e.name
)
SELECT
f.feature,
COUNT(*) FILTER (WHERE c.retained) AS retained_users,
COUNT(*) FILTER (WHERE NOT c.retained) AS churned_users,
ROUND(100.0 * COUNT(*) FILTER (WHERE c.retained) / COUNT(*), 1)
AS pct_retained
FROM first_week f
JOIN cohort c ON c.id = f.user_id
GROUP BY f.feature
HAVING COUNT(*) > 30 -- ignore the noise
ORDER BY pct_retained DESC;
-- Read the top of this list. That is your roadmap.
-- Read the bottom. That is what you stop building, and stop maintaining.
-- Neither list will match the one from the offsite.This query needs an events table that already existed before launch. That is the whole trick, and it is the step almost everybody skips.
How do you transition from an MVP build team to a continuous iteration model?
Deliberately, and before you need to. This transition is a decision you make, not something that happens to you.
The mechanics are less dramatic than founders expect. You almost certainly do not need a bigger team. Most post-launch products are well served by fewer people than built them, on the condition that those people never stop.
What has to change is the unit of work. A project team ships a scope. A continuous team ships a change, on a Tuesday, without a meeting about it. That only works when the pipeline is boring: tests on every pull request, a deploy that is one command, a rollback that is the same command with a flag. If shipping is an event, you will do it quarterly, and quarterly shipping is how you arrive at a Version 2 rebuild.
Then set the cadence and defend it. A weekly release, whether or not it feels ready, because a train that leaves on time forces changes small enough to be safe. Small changes are the ones that do not take down your Saturday.
And somebody has to own the queue. Not a committee. One person who reads the support tickets, reads the events table, and decides what happens next week.
FIG/03/TRADE-OFFS
Project agency vs continuous engineering
The left column is not incompetent. It is a different product, sold to a different buyer, and it stops at exactly the point your problem starts.
| Criterion | Project agency | Continuous engineering |
|---|---|---|
| Unit of work | A scope, agreed in advance and defended against change. | A change, shipped on a Tuesday, with no meeting about it. |
| What happens at launch | The engagement ends. Everyone celebrates. The invoice is final. | Week one begins. The interesting data starts arriving. |
| Release cadence | Quarterly, once the queue has grown long enough to justify a project. | Weekly, whether or not it feels ready. |
| Roadmap input | The offsite. Whoever argued best. The loudest customer. | The events table, the support queue, and a cohort query. |
| Cost of a small change | A change request, a quote, and three weeks of calendar. | An afternoon. It goes out with Thursday's release. |
| Team size after launch | Zero, then six again for the rebuild. | Two, continuously, who still remember why the code is shaped this way. |
| Where Version 2 comes from | A queue of deferred changes that grew long enough to look like a new product. | It does not. You shipped it forty times without naming it. |
| When it is the right call | A genuinely finite build: a campaign site, a one-off tool, a fixed deliverable. | Anything with users whose behaviour you cannot predict in advance. |
What does the handover actually need to contain?
If you are working with an agency and the engagement is ending, this is the list worth arguing about while you still have leverage. Which is now, not in week thirteen.
- The repository, with its full commit history. Not a zip of the final state. The history is where the reasoning lives.
- Running infrastructure in accounts you own, billed to your card, with your name on the root credentials.
- The migrations, in the repo, in order, runnable from an empty database by someone who has never met you.
- An events table that already exists and is already collecting, because on the day you want this data you will want it retroactively.
- A README that lets a new engineer deploy on their first morning without messaging anybody.
That last one is the real test, and it is worth running before you sign anything. If a competent stranger cannot get your product running from the repository alone, you did not buy software. You bought a dependency.
/FAQ
Questions founders actually ask after launch
- Why do so many startups stall after launching their MVP?
Because the launch was resourced as a project and a product is not one. A project has a date, a scope and a team. The day after launch you have users generating evidence, a queue of small changes, and frequently no engineer, because the contract ended at the precise moment the real work started. The queue becomes a quarterly release, and the quarterly release becomes a rebuild.
- How do we prioritize a roadmap once we have real users?
Instrument first, argue second. Emit events from your own code into your own database, then ask which features retained users touched in week one that churned users never did. That query is your roadmap. It will disagree with your offsite, and the feature the founder championed hardest will usually be near the bottom of it.
- Do we need a bigger team after launch?
Usually a smaller one that never stops. Continuous iteration is a question of cadence, not headcount. Two engineers shipping every week will outrun six engineers shipping every quarter, because small changes are cheaper to reason about, cheaper to review, and dramatically cheaper to undo when they turn out to be wrong.
- How do we tell whether our agency will abandon us at launch?
Ask what happens in week thirteen and listen for whether there is an answer at all. Then check the concrete things: is the repository in your organisation, is the infrastructure billed to your card, can a new engineer deploy from the README alone. An agency structured to leave is not being dishonest. It is being the thing you hired. The only question is whether you meant to hire it.
- What should our release cadence be after launch?
Weekly, and boring. A release train that leaves on schedule forces changes small enough to be safe, and small changes are the ones that do not eat your Saturday. If a release requires a meeting, you have already lost the cadence and you are on the road to a quarterly Version 2 that nobody will enjoy.
- Is a rewrite ever the right answer for Version 2?
Rarely, and almost never for the reason offered. Version 2 rebuilds are usually a queue of deferred small changes that grew long enough to resemble a new product. You can nearly always ship that queue incrementally against the product you already have, in a fraction of the time, without freezing your roadmap for a quarter. Rewrite when the data model is genuinely wrong. Not when the backlog is merely long.