How to cut an MVP without cutting the risk
Most scope reduction removes work. Good scope reduction removes uncertainty.
The usual way to cut scope is to sort features by effort and remove from the expensive end. This reliably produces a smaller release that tests nothing, because effort and uncertainty are unrelated.
Sort by what you would learn
For each item, ask what you would know after shipping it that you do not know now. Items with a real answer are the release. Items whose answer is 'that it works' are execution, not learning, and can wait.
The riskiest assumption is rarely a feature
It is usually a belief about behaviour — that people will connect their data, invite a colleague, or come back on day three. Those can often be tested with far less than the feature that assumes them.
Write down what you cut and why
A cut list with reasoning is the most reusable artefact of the whole exercise. Without it, every deferred item returns in three months as a new idea, and the argument runs again from the beginning.
If removing it does not change what you will learn, it was never in the MVP. It was in the plan.
Stop writing PRDs without understanding the product.
Anchor reads your interviews, tickets and docs first — then writes, citing every line.
