The reading room · Digna Legi
Lost confidence
/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. Evidence is long and substantive, though some embedded figures or diagrams are not visible in the text extract.
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
Confidence scores can distort startup product priorities by treating uncertainty like probability and penalizing ambitious work.
AI brief · Checked against source text
The main idea
The author argues that confidence scores distort prioritization because they penalize ambitious work while pretending uncertain outcomes can be measured like probabilities. In startup product work, the useful question is not how sure a team feels, but which choices remain wise under uncertainty: universally valuable improvements, behavior-based validation, clearly defined impact, preserved options, portfolios for reliability, and asymmetric bets for possible outliers.
Some background helpful. Some familiarity with product prioritization and probability estimates.
Go a little deeper
Confidence is not a tiebreaker once multiplied into the score
The author’s central complaint is structural: frameworks that include confidence in the initial score do not merely break ties between otherwise equal projects. They make a certain small improvement mathematically comparable to a risky larger bet, which the author says systematically favors safe, incremental work. That matters because small projects are usually easier to feel confident about than larger, potentially more valuable ones.
Uncertainty calls for robust choices, not fake precision
The essay draws a hard line between probability and uncertainty. Probability works when the underlying distribution is known, like repeated fair coin flips. Product strategy and startup features, in the author’s account, lack that stable distribution, so the better move is to ask which actions make sense across many futures: speed, mandatory enterprise requirements, genuine observed interest, or architecture that preserves options.
Validation should try to invalidate before building
Customer interviews still have value, but the author downgrades them from proof to a way of finding disqualifying friction. Asking someone to describe their real workflow can reveal that a requested feature would require code rewrites or exports into another system. Dummy features go further by measuring action, not stated intention, and by creating a pool of users to interview before full investment.
Use different tools for reliability and outliers
Portfolios reduce variability when the goal is a set of predictable, typical outcomes; they are ill-suited when the goal is a market-differentiating outlier. For outliers, the author prefers asymmetric bets: define a survivable downside in time and money, and require an upside large enough that one success can pay for many failures. The discipline is shaping the bet before momentum makes stopping hard.
A case from the article
The dummy feature test
The source’s clearest practical case is a button for an unbuilt feature that tells clickers the feature does not exist yet and asks how they would use it. The mechanism is useful because clicking is a small revealed behavior, not a hypothetical survey answer. It gives the team both a count of interested users and specific people to interview before committing to the build.
How the case is made
The case is made through product-management observation, probability-versus-uncertainty distinctions, practical validation tactics, and a mathematical sidebar on portfolios.
Where the idea has limits
The author explicitly distinguishes contexts: designs that keep future choices open may suit mature companies, while early-stage companies may need speed; portfolios suit reliable incremental results, not outlier-seeking differentiation.
A question to take away · from Digna Legi
Where are you using a confidence number to avoid arguing directly about downside, upside, and observable demand?
What the original adds
The source adds a concrete critique of project-prioritization scoring, validation tactics such as dummy features, numeric impact thresholds, and a portfolio-versus-asymmetry distinction with mathematical support.
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.