The reading room · Digna Legi
Babe Ruth and Feature Lists
/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 complete enough, but it is a single product anecdote rather than a broad framework.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 2 min with detail
Original article ↗ · about 5 min (publisher estimate)
Why read this
Ranked feature lists can hide whether users mean a nice-to-have improvement, a severe defect, or an urgent reliability failure.
AI brief · Checked against source text
The main idea
The author argues that feature prioritization fails when teams and users attach different meanings to the same ranked item. Google Docs treated “formatting” as a broad improvement theme, while educators meant severe editing bugs that made school papers unreliable. A list captured relative priority but erased magnitude, urgency, and whether the work was a feature or a defect.
Go a little deeper
Same rank, different object
The failure was not that formatting was missing from the list. It was ranked first. The problem was semantic: the team meant future capabilities such as styles, templates, and fonts, while customers meant broken basics. Agreement at the label level created false confidence because nobody had aligned on the actual object being prioritized.
Magnitude needs a different instrument
A ranked list can say one item beats another, but not whether it beats everything else combined. The play-money exercise forced tradeoff intensity into the open: educators put almost all value on fixing formatting. That revealed a discontinuity the spreadsheet had flattened into a normal first-place item.
Separate defects from ambitions
Mixing bugs and feature ideas made the list look like a balanced roadmap when users were describing a minimum quality failure. The author’s advice is practical: use blank-sheet conversations, ask forced tradeoff questions, keep lists short, separate bugs from features, and define when an item is removed.
A case from the article
Formatting as a blocker
Educators reacted badly when the author presented formatting improvements such as styles and fonts, because their daily pain was basic document reliability. Browser-based rich text editing caused bolding, bullets, and alignment to behave unpredictably. For students printing papers to strict requirements, this was not polish; it was a reason the product could fail at its core job.
How the case is made
The case is made through the author’s product-management experience at Google Docs, especially a 2008 customer meeting with educators.
Where the idea has limits
The argument targets prioritization conversations where labels compress different problems; it does not reject lists outright, and explicitly says managing development against themes was still right.
A question to take away · from Digna Legi
Where are your users and your team using the same word for problems of different severity?
What the original adds
The source adds the concrete Google Docs backstory, the customer budgeting exercise, and the later editing-engine rewrite that followed from reframing formatting as foundational reliability work.
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.