How to cut a two-week slice that still answers something

The seventeen-day feature that answered nothing

A founder brought me a burndown at a Karlín weekend last spring. Seventeen days on a team dashboard. It shipped. It worked. Nobody could tell me what they now knew that they had not known on day one. The dashboard was well built and completely inert as evidence.

That is the failure mode I see most often. Teams get good at cutting scope and stay bad at cutting scope around a question. They halve the feature list and end up with half a feature that proves half of nothing. The trick is not making the slice smaller. It is choosing the axis you cut along.

Write the question before the ticket

Before any two-week block starts, I make people write one sentence in this shape:

We believe this group will do this thing because this reason. We will know we were wrong if fewer than N of them do it in this window.

It has to be falsifiable in under four weeks. If your sentence is "we believe users want better reporting", you have not written a question, you have written a mood. If it is "we believe at least 8 of our 40 weekly-active admins will export a report twice in the fortnight after we ship export, because 11 of them asked for it in support tickets", you have something a fortnight can kill.

The number matters more than people expect. A threshold you pick in advance stops the post-hoc negotiation where three users is suddenly "early signal". Pick it before you know the answer, write it in the ticket description, and let it be embarrassing when you miss.

One more constraint. The question must be one whose no changes what you build next. If both answers lead to the same roadmap, you already decided, and you are building for comfort. Skip it and go do the thing you were going to do anyway.

Cut along the population, not the feature

Most teams shrink a feature by removing capability: no bulk actions, no filters, no permissions. That degrades the experience for everyone and produces mushy signal, because now you cannot tell whether people ignored it or found the crippled version useless.

The better cut is by population. Ship the whole thing, properly, to a small group.

A SaaS founder in the March cohort wanted to test whether a scheduling layer would raise retention. His plan was six weeks of half-built scheduler for all 900 accounts. We shipped the full scheduler to 40 accounts in nine days, gated on a flag, with a manual onboarding call for each. Twenty-two adopted it. Six were still using it forty days later. That is a real number about a real product. The 900-account version would have produced a smear.

When you cannot cut by population, cut by case. One document type, one currency, one integration. Whole depth, narrow width. The rule of thumb: your slice should be something a real user can complete end to end without you apologising once.

The four things that always get cut, and the one that must not

When the fortnight is tight, these go first and they go without argument:

• Settings. Hard-code the value. If two users disagree with it, you have learned something and the setting takes a day later.
• Edge-case coverage. Handle the top two paths, throw a clear error on the rest, log the error with enough context to reconstruct the input.
• Admin tooling. Do it in the database console with a script in a repo. Ugly and traceable beats pretty and absent.
• Generality. One hard-coded integration beats a plugin architecture with one plugin, every time, and it is not close.

What must survive: the measurement. If you ship the slice and cannot see who used it, how far they got, and where they stopped, you have bought a fortnight of opinions. Instrument the funnel before you build the feature. Four or five events, named in the past tense, with the user id and the timestamp and one property that tells you which variant they saw. That is an afternoon. Skipping it costs you the entire fortnight.

The Wednesday check

Two weeks is long enough to go wrong quietly. I run a hard check on the Wednesday of week one — day three, not day seven — with one question: is the demo path working end to end, even badly?

Not polished. Working. A user can start, and finish, and something is stored. If on day three there is no path, the slice is too big and you cut again, now, while cutting is cheap. On day nine cutting is not cutting, it is abandonment, and teams will not do it because of what they have already spent.

This inverts the usual order. Most teams build the model, then the logic, then the interface, and discover on day eleven that the interface implies a different model. Build the thin end-to-end line first, even if half of it is a stub returning fixed data. Then thicken it. Every day after day three you should be able to demo something slightly less embarrassing than yesterday.

What the fortnight owes you at the end

At the end you should be able to write four things in under ten minutes:

1. The question, restated exactly as it was written on day one.
2. The number you predicted and the number you got.
3. What you are doing next as a direct consequence.
4. What you deleted.

That last one is the tell. A team that never deletes anything from a slice was not running an experiment, it was running a delivery. Roughly a third of the slices I have watched over the last two years ended with the code removed and the answer kept. That is a good ratio. If yours is zero, your questions are too safe.

Be honest about the shape of the answer, too. A fortnight rarely tells you "yes, build this properly". It usually tells you "no", or "yes but the value was somewhere adjacent to where we looked". The adjacent finding is the valuable one and you will only catch it if you talked to the people who used it. Five calls, twenty minutes each, in the week after. Ask what they did instead before this existed. That question has earned me more product direction than any dashboard.

The failure modes worth naming

The slice that needs a migration. If your fortnight requires a schema change that is hard to reverse, it is not a slice, it is a commitment wearing a slice costume. Add a column, do not restructure. Reversibility is what makes the small bet small.

The slice that requires a launch. If the thing only produces signal when you email 4,000 people about it, you have coupled your experiment to your reputation, and you will soften the experiment to protect the reputation. Test on people you can call.

The slice with two questions. You will get a confounded answer and argue about it for a month. One question. Write it down. Put the second one in the next fortnight, which is only fourteen days away.

The slice with no owner after Friday. Whoever built it must be the one reading the numbers ten days later. Otherwise it decays into an unowned feature that nobody will delete because nobody knows what it was for. That is how maintenance debt starts.

Do this on Monday

Take whatever is at the top of your roadmap right now and write the belief sentence for it, with a real threshold and a real deadline. If you cannot write it — if the sentence keeps coming out as a description of the feature rather than a claim about people — that item is not ready and you have just saved yourself a fortnight.

Then cut it by population until day three is achievable, name the four events you will log, and put the Wednesday check in the calendar as a meeting with a name. Not "standup". Call it cut or continue. The name does most of the work.