Insights

Breaking Work Down Is Not the Same as Making It Actionable

Why a properly sized task can sit untouched for days, and what must happen before it moves

Summary: Splitting a large objective into smaller pieces is real progress, but decomposition changes a task's size, not its clarity. A smaller task can inherit unresolved questions and stall just as completely. This article distinguishes a large objective, a smaller but still vague task, a clear decision, and an executable next action, then shows where a stuck task becomes startable.

By Stanislav Trifan · Published July 18, 2026 · Last updated July 26, 2026

Breaking work into smaller pieces is not the same as making it actionable. Decomposition changes a task’s size. It does not name the unmade decision, inputs, output, or finish line that turn a vague item into a startable next action. Until those are clear, a properly sized task can sit untouched for the same reason as the original ambition.

You took a large, vague ambition and broke it into pieces, as every productivity system recommends. “Fix the checkout flow” became “Redesign the payment step.” It was smaller and more manageable on paper, then it sat there. It was not a task avoided out of laziness. It was a task that seemed possible to start but still would not move.

The checklist looks right, so when the task still does not move, the explanation can become personal: maybe I am not motivated today, maybe I am procrastinating, maybe something is wrong with me. More often, the task still contains a decision nobody has made. Resizing the work cannot make that decision for you.

Smaller is not the same as clearer

Take “Redesign the payment step.” It’s a real task, and it’s genuinely smaller than “Fix the checkout flow.” But it still bundles a half-dozen unmade choices: which part of the flow is actually losing people, whether the problem is trust, friction, or price shock, which version of “better” you’re aiming for, what “done” even looks like. None of that shrank when the task did. It just got repackaged into a smaller container, wearing a more encouraging size. You can decompose an objective all afternoon and still end up with a list of items that are each, individually, exactly as paralyzing as the whole.

From firsthand engineering and product-leadership experience, not a study result: I have watched a careful decomposition turn a messy epic into a neat sprint backlog of smaller tickets that still would not start. The tickets were properly sized. The decision that determined what each ticket was actually for had never been named, so the backlog looked tidy while every item still carried the same unresolved choice. Smaller work items are real progress only when the open decision shrinks with them, or is explicitly parked so a next step can run without it.

Four objects, not two

Most decomposition advice quietly treats “big task” and “small task” as the only two categories that matter, split the big one until the small ones are small enough. That framing hides a more useful distinction. There are at least four different things on the table, and collapsing them into one is where the trouble starts:

A large objective: the ambition, unstartable by nature.
A smaller but still vague task: decomposed, and still not actionable.
A clear decision: the open choice that, once named, makes the next step obvious (when the stall is decision-shaped).
An executable next action: inputs, output, and finish line named; startable in minutes.

Four-object progression

The bullets name the four objects once. The progression below is the diagnostic ladder on the checkout thread, each rung keeps its label, example, and typical gap. It is scannable, not a mandatory sequence:

Large objective: the ambition; usually not startable as written. “Fix the checkout flow.” Typical gap: which problem, which inputs, what done looks like, all still open.
Smaller but still vague task: smaller label, same uncertainty. “Redesign the payment step.” Typical gap: several open questions packed into a more encouraging size.
Clear decision (pattern): a named open choice when the stall is decision-shaped; skip this rung when it is not. “Decide which single friction point in the payment step is actually costing conversions.” Close or park the choice, then write the step that follows.
Executable next action: startable when inputs, output, and finish line are named. “Pull the last five checkout drop-off session recordings and write one sentence naming where each one gave up.” Nothing material left to resolve before starting.

For decision-shaped stalls, a common pattern after a responsible decomposition, the useful jump is often from the second object to the third: naming the open choice so a concrete fourth step can appear. The first two rungs mostly shrink the container. That four-object ladder is an editorial distinction this article uses, not a lab taxonomy, and not every stuck item needs a separately named “clear decision” before it can start (missing information, a blocker, or wrong scope can be the real wall). It does sit next to something well established in how the mind represents action: Robin Vallacher and Daniel Wegner’s work on action identification theory found that the same activity can be mentally represented at a low, concrete “how” level, the specific steps and means, or a high, abstract “why” level, the goal or its meaning. On this view, a vague task like “redesign the payment step” is still being held at an abstract level, no matter how small it gets; it becomes easier to start when it is re-represented more concretely, which recordings, which sentence, which friction point, by when. Decomposition changes size; the re-representation is what changes whether beginning feels possible. That last step is our application of the theory to everyday task lists, not a finding the 1989 paper itself tested on product backlogs.

Why the vagueness survives the split

It’s worth being precise about the cost an unresolved decision can impose, because it helps explain why a “properly sized” task can still feel heavy to look at. Working memory, the mental space available for holding information while you reason about it, has a narrow, well-evidenced limit under the conditions where pure capacity can be measured. Nelson Cowan’s reconsideration of storage capacity converges on roughly three to five chunks (often near four) for the focus of attention when chunking, rehearsal, and long-term knowledge are controlled, not the looser “seven plus or minus two” figure many people still assume. Those estimates shift with task, material, and how items are grouped; the paper is careful about those boundary conditions, and the figure is not a universal ceiling for every kind of mental work. We apply this as a lens on stuck tasks: an unresolved decision may not need to be complicated to load several live unknowns at once, which option, which input, what counts as finished, so a smaller task carrying an unmade decision can feel nearly as hard to approach as the large objective it came from. That loading story is an application, not a Cowan experiment on product backlogs.

Specificity, separately, has its own well-documented effect on performance. Edwin Locke and Gary Latham’s decades-spanning research program on goal setting, summarized in their own retrospective on the field, consistently found that specific, clear goals outperform vague or “do your best” goals, because specificity removes ambiguity about what adequate performance looks like. That is evidence about goal clarity and outcomes, not about a particular “hidden decision” construct. On this view, the checkout example lines up with the specificity finding without claiming the papers studied it: “Redesign the payment step” is a goal, and it is not a specific one. Making it smaller did not make it specific. Naming the open decision is the practical move this article uses to raise specificity until a next action can be written, an editorial bridge from goal-setting evidence to task lists, not a result Locke and Latham reported.

The decision hiding inside the task

So what actually happens at the moment a task turns from stuck to startable? It’s not that the task got small enough. It’s that a decision got made, or, more precisely, that the decision was named clearly enough to be made in a single sitting. That’s a different event than decomposition, and it deserves to be treated as one.

There’s strong evidence for how much pre-deciding the initiation of an action matters. A meta-analysis by Peter Gollwitzer and Paschal Sheeran, covering ninety-four independent tests of implementation intentions, if-then plans that specify in advance when, where, and how an action will happen, found a medium-to-large effect on goal attainment, including a medium-to-large effect on getting started with goal-directed behavior, not only on finishing it later. Pre-deciding the when/where/how does not just make execution smoother; it helps trigger the first move.

That finding is about implementation intentions, not about naming an open decision. Those are related but different moves. Naming the decision, “which single friction point in the payment step is actually costing conversions?”, clarifies what must be resolved before a concrete action exists. Forming an implementation intention is what you do once you know the action: for example, “When I open my laptop at 9:00 tomorrow, I will pull the last five checkout drop-off recordings and write one sentence per abandon point.” The research supports that second step for initiation; the first step is this article’s practical prerequisite so there is something specific enough to pre-commit to. Neither result proves a product workflow, they inform why starting stays hard when both the content decision and the if-then plan are still missing.

What this looks like end to end

The four-object map above already names each rung. What matters end to end is where the nature of the work changes, not a second ladder and not invented metrics.

On the checkout thread, a complete pass looks like this:

Before (still stuck): large objective “Fix the checkout flow” becomes the smaller-but-still-vague task “Redesign the payment step.” The container shrank; nothing is startable.
Named decision (pattern): “Which single friction point in the payment step is actually costing conversions?”, a blocking question, not another ticket title. Naming it changes what the next step is for; you may still need evidence before you close it.
After (executable next action): “Pull the last five checkout drop-off session recordings and write one sentence naming where each one gave up.” Inputs (five recordings), output (five sentences), finish line (five written). For this investigation step the friction choice does not need to be closed yet, the recordings are how you close it. There is nothing left to resolve before starting. There is only starting.

What makes a next action startable

An actionable next step is an executable next action: a concrete step whose inputs, output, and finish line are named, and whose blocking decision is closed or not needed for this step.

Decomposition answers how big a piece is. Startability is a diagnostic test, not a full project playbook: the definition is the inputs / output / finish-line triad; owner and decision are light guards that often explain why a properly sized item still will not move. If a check fails, fix that box, do not shrink the title and hope size alone produces clarity.

Inputs known: if missing, name one concrete obtainable artifact (or make the action getting that artifact), not an open domain.
Output visible: if missing, replace open-ended redesign with a single artifact (a sentence, a short list, a one-page note).
Finish line recognizable: if missing, state a binary or countable done condition instead of “better.”
Owner clear: if missing, name who will do this step (you count). “Someone” or “the team” is not an owner.
Decision named or not needed: if the freeze is an unmade choice wearing a task label, name that choice and close or park it. Not every stuck item needs a separately labeled decision object; missing information, a blocker, or wrong scope can be the wall instead.

For fields, routing, and multi-domain procedure, use the project → next-action playbook.

Startability checklist

Before you re-split a “properly sized” item, run this pass:

Inputs are named and obtainable (or the action is getting one missing input)
Output is a single visible artifact
Finish line is binary or countable, no subjective “quality” debate
Owner is clear (you, or a named person), “someone” / “the team” is not enough
Blocking decision is named and closed, or not needed for this step
You could start in the next ten minutes without another planning session

How Pergunta.me applies this

Instead of asking only “how small can this get,” the workflow keeps asking what is still unclear about the next move. Surfacing the unmade decision, not just producing smaller items, is what makes progress. A task like “Redesign the payment step” is not treated as ready just because it fits on one line; clarification continues until the next step is small because it is certain, not certain because it is small.

Try it in the next ten minutes

Pick one task from your own list that has been sitting there despite being, on paper, reasonably sized. Don’t shrink it further. Run the startability checklist on it. If the decision box fails, write the open decision as its own line and answer it provisionally in the next ten minutes. If inputs, output, finish line, or owner fail, name those before you open a document. What’s left afterward is usually the executable action you were actually looking for.

The task was never the obstacle

When decomposition is already done and the item still will not move, the remaining lever is naming, not another resize, and not a willpower lecture. See the decision wearing a task label; decide or park it; write the step that follows.

Why familiar advice is hard to apply in the first place is the obstacle before this one: never picking the advice up, because familiarity makes it feel already handled. This is the case where you picked it up, followed it correctly, and found that decomposition alone was never going to touch the real obstacle, only naming the decision was.

The naming doesn’t stop once the task ships, either. A finished task can still leave the decision underneath it open: a task can be decomposed correctly, executed, and checked off, while the decision underneath it stays exactly as open as it was before anyone touched it.

Later work climbs one level further: a plan becomes dangerous when reality has already changed, a whole plan can be followed correctly and still be quietly wrong, because the evidence that should have changed it arrived after the plan was already written.

Once the decision is named, run the playbook to produce one startable action, fields and a startability test, not another round of decomposition.

Key takeaways

Size and startability are independent: shrinking a task without resolving its open questions leaves it unstartable.
For decision-shaped stalls, naming the open choice is often the unlock, and not every stall needs that intermediate object.
Before re-splitting a title, run the startability checklist (inputs, output, finish line, owner, decision-or-not-needed, ten-minute start).
Under pure capacity conditions, working memory holds only a few chunks at once; we apply that as a lens on why a “properly sized” item carrying several live unknowns can still feel heavy to approach.
Specific goals outperform vague ones because specificity removes ambiguity about what counts as done, not because the goal got shorter, naming the open decision is how this article raises that specificity in practice.
Implementation intentions (if-then plans for when/where/how) help with starting an action once it is known; naming the hidden content decision is a different prerequisite so there is something concrete enough to pre-commit to.