Every few months a team somewhere ships something substantial in a handful of weeks, writes up how they did it, and a thousand founders read the write-up looking for the trick. There is no trick, which is the disappointing part, and there is a method, which is the useful part. Teams that ship fast are not staffed by faster people. They have made a small number of decisions before the first line of code that slow teams make late, or make badly, or never make at all, and every one of those decisions is about what the team is willing to leave out. Speed is not a property of the builders. It is a property of the constraints.
The difference between moving fast and thrashing is visible from the first week, and it comes down to whether scope was decided or discovered. A team that starts building with a clear statement of what the first version does, and just as importantly what it does not do, spends its weeks building. A team that starts building in order to find out what the product should be spends its weeks arguing, rebuilding and reconciling, and the calendar records both as seven weeks of work while only one of them ends with something shipped. Deciding scope is not planning overhead that fast teams skip. It is the thing that makes them fast.
One owner
The second decision is about who decides, and the answer that works is a single person. Not a committee, not a working group, not a shared document where everyone leaves comments and nobody resolves them. One owner who can say yes and no without a meeting, who holds the whole shape of the thing in their head, and who is accountable for the outcome in a way that makes the daily trade-offs personal. Committees are excellent at making decisions safe and terrible at making them quickly, and a seven-week project has no slack for safety of that kind. Every day spent waiting for alignment is a day not spent building, and alignment across five people costs more than most founders admit.
This does not mean the owner works alone or ignores the team. It means that when two reasonable options exist, one person picks, and everyone else moves. The teams that have built serious products in a month or so tend to describe exactly this structure: a small group, one person whose call it was, and a shared understanding that arguing past a decision was slower than living with it. The owner may be wrong sometimes. Being wrong quickly and correcting is still faster than being right slowly.
Cutting is the work
Founders often treat the features that get cut as evidence of a planning failure, as though a better plan would have fitted everything in. The opposite is true. Cutting features is not what happens when planning fails; it is what planning is. A first version that ships in seven weeks is one where somebody looked at every proposed feature and asked whether the product would be worth using without it, and left out everything that survived the question. That is a hard and slightly painful exercise, because every feature has an advocate, and it is the single most reliable predictor of whether the date holds.
Cutting features is not what happens when planning fails. It is what planning is.
A useful way to run the exercise is to describe the product in one paragraph as a customer would experience it on the first day, and then to defend every feature against that paragraph. Anything the paragraph does not need is a candidate for the cut list, however elegant it is and however much work has already gone into it. Sunk effort is the most common reason a feature survives a scope review it should have failed, and the owner has to be willing to let it go anyway. The paragraph is the product. Everything else is next quarter.
The features that get cut are rarely bad ideas. They are good ideas whose time is later, and the discipline is to write them down somewhere the team can see them and then stop talking about them. A cut that lingers as an argument is worse than no cut at all, because it consumes the attention that was supposed to go into what remained. The owner’s job here is partly editorial and partly emotional: to make the cuts, to make them visibly, and to make it clear that the cut list is a queue rather than a graveyard.
Ignoring the market’s schedule
The pressure that most often breaks a seven-week plan does not come from inside the team. It comes from watching a competitor announce something, or reading that the market is moving faster than expected, and deciding that the scope has to grow to keep up. This is almost always a mistake, and it is a mistake that feels like prudence. A competitor’s announcement tells you what they chose to build. It does not tell you what your customers need, and it certainly does not tell you that your first version needs to match their fifth. The founders who ship on time are the ones who can read the news and not change the plan.
The pressure also arrives from inside, dressed as ambition: someone on the team sees a way to make the first version better and the addition is genuinely good. The answer is the same. Write it down, put it in the queue, ship what was decided. Good ideas that arrive after scope is set are the raw material of the second version, not amendments to the first.
That takes a particular kind of nerve, because the market’s pace is real and the anxiety it produces is real. The way through is to remember that the fastest response to a competitive market is to ship what you already decided to ship, learn from real users, and iterate, rather than to expand the scope of a thing that has not yet reached anyone. A late, larger product loses to an on-time smaller one far more often than the anxiety suggests, because the smaller one has been learning for the weeks the larger one spent growing.
Making the next one faster
The last piece is what happens after shipping, and it is the piece most teams skip because shipping feels like the end. It is not. A short review, held within a week of release, that asks three plain questions will make the next build faster than any tooling change: what did we cut that we should have cut earlier, what did we keep that we should have cut, and where did a decision wait for more than a day. The answers are usually uncomfortable and almost always the same across projects, which is exactly why they are worth writing down.
The review turns speed from an event into a practice. The first seven-week project is an achievement. The fifth is a habit, built from four reviews that each shaved something off the next attempt. Teams that ship fast once got lucky with the constraints. Teams that ship fast repeatedly chose them, on purpose, in advance, and then checked afterwards whether they chose well. That is the whole method. It is not a trick, and it is available to anyone willing to decide what to leave out.