Insights

Breaking Work Down Is Not the Same as Making It Actionable

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

Summary: Splitting a large objective into smaller pieces feels like the responsible move, and it is real progress — but decomposition changes the size of a task, not its clarity. A smaller task can inherit all of its parent's 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 — four different things decomposition methods often treat as one — and walks through the exact point where a stuck task turns into a startable one.

By Stanislav Trifan · Published July 18, 2026

You did the responsible thing. You took a large, vague ambition and broke it into pieces, the way every productivity system tells you to. “Fix the checkout flow” became “Redesign the payment step” — smaller, cleaner, reasonable-looking. And then it sat there. Not at the top of a list of things you’re avoiding out of laziness, but in that quieter, more disorienting place: a task you know you should be able to start, that still won’t move.

This is a stranger kind of stuck than the usual kind. You didn’t skip the step everyone recommends — you did it. You decomposed the work. The checklist looks right. So when the task still doesn’t budge, the easiest explanation is a personal one: maybe I’m just not motivated today, maybe I’m procrastinating, maybe something is wrong with me. That explanation is almost always wrong. What’s actually wrong is smaller and more fixable than a character flaw: the piece you’re holding still contains a decision nobody has made, and no amount of resizing was ever going to make that decision for you.

Smaller is not the same as clearer

Decomposition is necessary. It is also not sufficient, and the difference between those two words is the entire subject of this article. Breaking a large objective into parts changes how big each part is. It does not, on its own, change how much uncertainty each part carries — and uncertainty, not size, is what determines whether a task can be started.

Think about what “Redesign the payment step” actually asks of you. It’s a real task, and it’s genuinely smaller than “Fix the checkout flow.” But it still bundles together 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.

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. “Fix the checkout flow.”
A smaller but still vague task — decomposed, and still not actionable. “Redesign the payment step.”
A clear decision — the thing nobody has made yet, which once named makes everything downstream obvious. “Decide which single friction point in the payment step is actually costing conversions.”
An executable next action — bounded, with its inputs, output, and finish line named, startable in minutes. “Pull the last five checkout drop-off session recordings and write one sentence naming where each one gave up.”

Notice that only the jump from the second item to the third changes anything real. The first two steps just shrink the container. The third step names a decision — and the fourth step, the one you can actually start today, only becomes obvious once that decision exists. This maps onto something well established in how the mind represents action: work by Robin Vallacher and Daniel Wegner 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. A vague task like “redesign the payment step” is still being held at the abstract level, no matter how small it gets. It only becomes actionable when it’s re-represented concretely: which recordings, which sentence, which friction point, by when. Decomposition changes size; only that re-representation changes whether you can begin.

Product note

The four objects above aren’t just an explanatory device. The workflow tracks the unmade decision as its own item, separate from the task it lives inside — so decomposing a piece of work and naming what’s undecided about it stay two distinct, visible steps, instead of collapsing into “make it smaller” and calling that done.

Why the vagueness survives the split

It’s worth being precise about the cost an unresolved decision imposes, because it explains why a “properly sized” task can still feel so heavy to look at. Working memory — the mental space available for holding information while you reason about it — has a narrow, well-evidenced limit. Nelson Cowan’s reconsideration of storage capacity puts the practical ceiling at roughly three to five items, not the looser “seven plus or minus two” figure many people still assume. An unresolved decision doesn’t need to be complicated to eat most of that space — it just needs several live unknowns at once: which option, which input, what counts as finished. A smaller task carrying an unmade decision can occupy nearly as much of your limited attention as the large objective it came from, which is a big part of why it doesn’t feel any easier to approach.

How Pergunta.me applies this

Instead of asking “how small can this get,” the workflow asks “what hasn’t been decided yet.” Surfacing the specific unmade decision — not just producing smaller items — is treated as the actual unit of progress, because that decision, not the task’s size, is what stands between it and starting.

Specificity, separately, has its own well-documented effect on whether work gets done at all. 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 itself removes ambiguity about what adequate performance even looks like. That finding lines up with what the checkout example shows directly: “Redesign the payment step” is a goal, and it is not a specific one. Making it smaller didn’t make it specific. Only naming the decision did.

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 difference this makes. A meta-analysis by Peter Gollwitzer and Paschal Sheeran, covering ninety-four independent tests of implementation intentions — the practice of deciding in advance exactly when, where, and how an action will happen — found a medium-to-large effect on whether people actually followed through, and the effect was specifically concentrated on starting the goal-directed behavior, not just eventually finishing it. Pre-deciding the how and when doesn’t just make execution smoother later; it’s what triggers the first move. Applied here: “Decide which single friction point in the payment step is actually costing conversions” is the implementation-intention moment. Everything before it is still an ambition. Everything after it can be scheduled like an errand.

What this looks like end to end

Walk the full progression once, in order, and the shift is visible at exactly one point.

“Fix the checkout flow.” Nobody can open a document and start on that sentence. It has no inputs, no finish line, no owner of a single next move.

“Redesign the payment step.” Smaller, and still nobody can start on it today — not because it’s not real work, but because “redesign” still hides several open questions about what the step is even trying to fix.

“Decide which single friction point in the payment step is actually costing conversions.” This is the turn. It’s not smaller in the same sense as the previous step — it’s a different kind of object entirely, a decision rather than a task. Naming it this explicitly is most of the work; the decision itself might take ten minutes once it’s visible.

“Pull the last five checkout drop-off session recordings and write one sentence naming where each one gave up.” This is what the decision produces once you act on it: bounded inputs (five specific recordings), a clear output (one sentence), and a finish line you’d recognize the moment you hit it. There is nothing left to resolve before starting. There is only starting.

In practice with Pergunta.me

A task like “Redesign the payment step” isn’t marked ready in app.pergunta.me just because it fits on one line. The workflow keeps asking what’s still undecided until what’s left looks like the recordings-and-one-sentence step — small because it’s certain, not certain because it’s 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. Instead, ask one question of it: what has to be decided before this can move, and who would make that decision if it were being made right now? Write that decision down as its own line, separate from the task. If you can answer it in the next ten minutes — even provisionally — do that first. What’s left afterward is usually the executable action you were actually looking for.

The task was never the obstacle

It’s worth sitting with why this particular stuck feeling is so demoralizing compared to ordinary procrastination. When you haven’t started anything yet, there’s an obvious next fix to reach for: break it down. When you’ve already broken it down and it still won’t move, that fix is spent — there’s no obvious next lever left, so the stall gets read as something personal. It isn’t. The list still contains a decision nobody made, wearing the disguise of a task that’s merely waiting its turn.

Once you can see the decision sitting inside the task, the fix stops being about willpower and starts being about naming: what hasn’t been decided, and can it be decided now. That’s a smaller ask than it sounds, and it’s the one decomposition alone was never going to make for you.

Elsewhere in this series, the obstacle is never picking the advice up in the first place, 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. What’s next in this series picks up exactly there: 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 in this series climbs one level further: the same blind spot exists above the task, where 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.

Key takeaways

Decomposition changes the size of a task, not its clarity — a smaller task can inherit all of its parent’s unresolved questions and remain just as unstartable.
Four different objects get collapsed into one list by most decomposition habits: a large objective, a smaller-but-still-vague task, a clear decision, and an executable next action. Only naming the decision separates the second from the fourth.
An unresolved decision consumes working memory on its own, independent of how small the surrounding task looks — which is why a “properly sized” item 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.
Pre-deciding the how and when of an action is what triggers starting it — that decision, not further splitting, is the actual unlock.

More Insights

Insights

A Plan Becomes Dangerous When Reality Has Already Changed

Following a plan correctly and following the right plan are not the same thing — and nothing about good execution tells you which one you're doing