The reading room · Digna Legi
The Best Prioritization Is No Prioritization
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. The argument is experience-driven and provocative; the evidence does not provide empirical backing for the broadest claims.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Many startup priority debates may matter less than faster feedback, narrower decisions, and slower changes to team resourcing.
AI brief · Checked against source text
The main idea
The author argues that startups often overrate prioritization because its inputs are vague, its correctness is nearly impossible to prove, and the process consumes attention. Instead, teams should reduce the need for priority calls by shipping faster and keeping teams attached to stable domains, so decisions become narrower, feedback arrives sooner, and cross-business tradeoffs move into slower resourcing choices.
Go a little deeper
Prioritization hides weak measurements
The critique is not just that frameworks are annoying. The author says common scoring inputs collapse under startup uncertainty: market size may be changing quickly, customer counts may be tiny, and engineering effort may shift as tooling changes. That makes priority scoring look rigorous while depending on unstable guesses, then leaves teams arguing over a counterfactual they can never verify.
Velocity lowers the precision required
Speed changes the decision problem. If a team can ship only one thing, choosing correctly matters enormously; if it can ship many things, a rough sense of promising work plus fast post-launch judgment may be enough. The author’s mechanism is feedback density: faster building both reduces the cost of a wrong bet and teaches prioritization through reality rather than debate.
Stable ownership converts priority fights into capacity choices
The second alternative is organizational rather than motivational: keep teams focused on one durable area so they compare similar work within that domain. That avoids recurring arguments about whether a new product, support burden, reliability issue, or revenue opportunity is “more important.” Leaders still make tradeoffs, but through staffing, shrinking, splitting, or growing teams instead of weekly cross-business reshuffling.
Slower resourcing can reduce thrash
A counterintuitive claim is that resourcing decisions are better partly because they are slower. Hiring, reducing, or reorganizing teams takes time, which limits reactive shifts. In the author’s view, that delay creates more focus and higher velocity than repeated reprioritization, even when a dramatic short-term pull of people onto one project might appear faster.
A case from the article
Two engineers testing a new area
For a high-upside new product area, the author contrasts monthly resourcing adjustments with assigning one or two engineers for three months to test whether the area can move from nothing to an initial working product or business signal. The point is that a small, stable team better resembles an early startup, reduces coordination overhead, and creates a clear next decision: add resources if it works, stop if it does not.
How the case is made
The case is made through startup advisory observation, practical examples, and critique of planning frameworks.
Where the idea has limits
The argument is strongest for startups and small teams; its own examples assume environments where speed, team stability, and flexible resourcing are realistic options.
A question to take away · from Digna Legi
Which priority debate would disappear if the team’s domain stayed fixed for a quarter?
What the original adds
The source adds sharper rhetoric against prioritization frameworks, more concrete startup scenarios, and a fuller account of how stable teams simplify stakeholder promises.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.