Once the problem is named and the outcome is chosen, there is a temptation to build everything at once: since we're at it, let's do it properly, with all the branches and edge cases. This temptation is the quietest way to ship nothing on time. Scope creeps up unnoticed, the deadline slips, and all the while the user keeps living with their pain.
Prioritization is two decisions, and the second matters more than the first. The first: what to do sooner. The second, usually avoided: what not to do at all. A product engineer knows how to cut — to trim a task down to the smallest slice that actually relieves the pain and checks that we weren't wrong.
Everything at once means nothing on time
Scope has a property of growing on its own. Every edge case seems mandatory, every neighbouring feature a logical addition, every "what if" a reason to add a branch. Individually each is reasonable; together they add up to a plan that doesn't reach the user for months. And until then there is no feedback, and all that scope is built on unverified guesses.
The cost here isn't only time. The more you build before the first contact with reality, the more expensive the turnaround when it turns out the guess was wrong. A large scope isn't "we did a lot", it's "we bet a lot on something we never tested".
The smallest valuable slice
You have to cut the right way. A common mistake is to cut horizontally, by layers: first the whole database, then the whole logic layer, then the whole interface. That way you don't reach a working result until the very end, and there's nothing to verify until everything is assembled.
A product engineer cuts vertically. The smallest valuable slice is the narrowest end-to-end path that runs through all the layers and actually solves the task for at least one case. In the marketplace case, the problem "a seller can't quickly put up a catalogue" doesn't have to be closed right away with import of any format, with validation, images and variants. The smallest slice is to load a catalogue from a table of one simple kind, without variants, with a clear error message. That already relieves the pain for some sellers and tests the main hypothesis: will they even load a catalogue this way at all. The rest comes after the slice has shown that the path is right.
A good slice answers two questions at once: does it deliver value to at least someone right now, and does it test the riskiest assumption. If it only tests but doesn't help, it's an experiment, not a product. If it only helps but tests nothing, you're lucky you guessed right.
What not to build
The decision "not to build" is harder than "postpone", because it sounds like defeat. But "we'll postpone it" is in most cases a polite form of "we'll never do it", and it's more honest to admit that upfront. The "we'll finish it later" list almost never gets cleared: new problems appear with higher priority, and the old "later" quietly goes stale.
That's why it's useful to explicitly keep not only the list of what we're doing, but also the list of what we deliberately are not doing — and why. This second list guards against two troubles at once: against bloating the current task and against the guilt over the "unfinished". What was left undone by decision isn't debt, it's a choice. An edge case that occurs in one user out of a thousand, a "just in case" feature, a nice branch nobody asked for — all of these are candidates for the "not building" list, until the outcome metric or contact with the user proves otherwise.
Priority by outcome and risk
What to cut and what to keep is decided not by taste but by two axes: contribution to the outcome and hypothesis risk. Contribution to the outcome answers how much a piece moves the metric everything is being done for; anything that doesn't move it automatically drops down. Hypothesis risk answers what would cost the most if we were wrong; the riskiest assumption is worth testing sooner, while the cost of the turnaround is small.
From these two axes comes a simple ordering rule: what both delivers value and removes the main risk gets done sooner. Cheap and unimportant can wait; expensive and unimportant goes to the "not building" list; important but testable later comes after the first slice.
For a product engineer this is especially valuable, because they carry the whole path alone and their time is the product's scarcest resource. Every piece they decide not to build is time given to what actually moves the outcome. The ability to cut isn't about doing less; it's about squeezing the most usefulness out of one person's limited time. A narrow slice delivered to the user beats any broad plan stuck halfway — and carrying it all the way, without throwing it over the wall, is the next topic.