The pattern
A team lists everything the product should do, estimates it, discovers it is twice the budget, and then trims 40% by making each feature slightly worse.
The result is a product that does everything badly rather than one thing well — and it usually ships late anyway, because "slightly worse" turns out to cost nearly the same to build.
Cut whole features, not quality
The first release should do fewer things at full quality. That means saying "not in v1" to entire capabilities, which is politically harder than shaving each one, and considerably more effective.
The test we use: for each feature, ask what happens if it is absent. If the answer is "a person does it manually and it is annoying", it can wait. If the answer is "the product does not work", it cannot. Most features are in the first group and everyone knows it.
Name the riskiest assumption and build that first
Every product rests on an assumption that would be fatal if wrong: that users will upload their data, that the third-party API returns what the docs claim, that the workflow makes sense to a person who does not work here.
Build whatever tests that assumption in week one, even if it is ugly and even if it is not the natural place to start. Sequencing by risk rather than by architecture is the single highest-return scoping decision available.
Manual is a legitimate v1
If ten customers a week need onboarding, a person can do it. Automating it before you know whether the product works is building infrastructure for a business that may not exist.
We have shipped several successful v1s where an operations person was doing by hand what later became a service. Both times, the manual period taught us things the automated version would have hidden.
Write down what you cut and why
Not to revisit it — to stop re-litigating it. A short "not in v1" list, agreed and visible, ends the same conversation recurring every sprint with slightly different wording.