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."

There's a simple way to catch yourself doing this: look at the task and ask which part of it will reach the user before everything else. If there's no answer — it means everything is tied into a single bundle and shipping something earlier is impossible without rethinking the structure of the task. That's exactly when to cut.

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 catalog" 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 catalog 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 catalog 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.

Example: the client account

Let's take a task that seems indivisible from the start and show how the slice is found through the outcome, not through "what would be nice."

A team decides to launch a client account for a B2B service. The initial list looks reasonable: order history, current status, documents (invoices and certificates), company profile, user management, email notifications, filters and export. Eight blocks — each logical, each "needed."

This will take three months minimum. All that time real clients keep calling account managers with "where's my order?" — that was the pain named at the start. The task scope and the user's pain have drifted apart: building a lot, but the pain won't be relieved until the very end.

Step one — state the outcome precisely: a client answers the question "where's my order?" on their own, without contacting the manager. For this outcome, only two things are needed: a list of orders and the status of each. Company profile, user management, documents, filters, export — none of that moves the outcome. Six of the eight items went onto the "not building now" list. Not postponed — specifically not building, until data shows otherwise.

Step two — find the riskiest assumption. It sounds like this: clients will actually log in to the account, rather than habitually call the manager. If this isn't tested first, three months of work could be a bet on behavior that doesn't exist.

The smallest slice: a page showing the order list and status, accessible via a link in the confirmation email. No separate login, no account management, no document history. Built in two weeks. After launch they watched one number: the share of incoming inquiries asking "where's my order?" over the following month. It dropped by 40%. The hypothesis was confirmed — clients do go to the account. The next slice added documents: those were what people asked for most often based on first contact with reality.

The key point in this story is not the size of the slice, but the sequence of decisions. First the outcome, then the main risk, then the minimal path that tests both. Six of the eight blocks weren't "postponed" — they were removed explicitly and for a reason. That's what made it possible to launch in two weeks what would otherwise have waited three months.

Note: everything removed didn't disappear forever. Documents came back in the next slice — because data showed they were needed. User management did not come back, because data didn't show that. The decision "not to build" holds until a reason to reconsider it appears.

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.

In practice, the "not building" list is convenient to keep right alongside the "building" list — in the same document, as one section of the task. When someone proposes adding a feature, "this is on our not-building list, here's why" is more concrete and honest than "we'll postpone it."

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.

When prioritization is hard, it's useful to ask yourself one question: "What happens if we were wrong about the main assumption?" If the answer is "we'd have to redo a large chunk," that assumption needs to be tested first, and the smallest slice is built around it.

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.

What this means in practice

The ability to cut is a skill that resists two things at once: intuition ("if we're doing it, let's do it right") and external pressure ("oh, add this too"). Here's where it breaks down most often:

Common mistakes:

  • Cutting horizontally. "First all the API, then all the frontend" — and for months nothing is verifiable. A useful slice is always end-to-end: from the user all the way to the database, even for the narrowest case.
  • Deferring the riskiest check. It's more comfortable to start with the clear and reliable — and leave "we don't know whether people will use it" for later. But the later the main guess is tested, the more expensive its refutation.
  • Writing "we'll finish it later" as a plan. The "later" list never gets cleared. If a feature didn't make it into the slice, it's more honest to mark it "not building" right away rather than "building later" — this changes expectations and removes the accumulating sense of debt.
  • Cutting the slice without naming the outcome. Without an answer to "what metric will this slice move," it's unclear what to keep and what to drop. Slicing without an outcome is guessing, not prioritizing.
  • Calling a large plan "minimal." "Minimal" doesn't mean "less than we'd like" — it means "the least that delivers value and tests the hypothesis." If a slice can't be released in one or two weeks, it's probably not minimal yet.

What's next

The narrowest slice is meaningless if it isn't delivered to the user and the result isn't measured. The next step is ship and measure. What exactly to measure is decided by the outcome metric, and not building what the user didn't ask for is taught by the problem statement — the beginning of the whole chain.