The Burning Library

The Bonfire of Books

Early in the novel, Don Quixote’s friends—the priest and the barber—decide that his library of chivalric romances is the source of his madness. So they do something drastic: they burn most of the books.

Not all of them. They carefully sort through the collection. A few are worth keeping—genuinely good stories. But the rest? Fuel for the fire.

The library had grown unchecked for years. Every new book added to the fantasy, the confusion, the complexity. The cure wasn’t to add better books. It was to remove the bad ones.

When Sancho later learned the books were gone, his only reaction was practical: less weight to carry on the next ride.

The PM Version

Products accumulate features like Quixote accumulated books:

Walk through your product with fresh eyes. Pretend you’ve never seen it before.

Start in the corners nobody visits—those features built three years ago that 2% of users touch. Nobody remembers why they exist. Nobody dares to remove them. “Someone might be using it.” Dust everywhere. Move on.

Open the settings page. Count the options. Forty-seven toggles, because every edge case got a configuration switch instead of a decision. A new user lands here, feels the weight of all those choices, and quietly closes the app. This room was supposed to give people control. It gave them paralysis.

Check the integrations. “We integrate with everything!” says the marketing page. Seventeen connections, each maintained by nobody, half of them broken, all of them adding surface area for bugs. A showcase that became a storage closet.

Now pull up the dashboard. It started as three metrics—the ones that actually mattered. Today it’s forty-two, spread across six tabs. Nobody knows which ones to check. Everyone checks a different one. The room that was supposed to bring clarity has become the noisiest one in the house.

Each addition made sense at the time. Together, they create madness.

And it’s not just the old features that pile up—new ones sneak in the same way. A business stakeholder once pitched me a feature as a “quick win”—clear impact, easy to build, no reason to say no. I added it to the backlog without much refinement because it seemed so straightforward. But straightforward meant nobody asked the hard questions upfront, and the feature went back and forth multiple times as hidden details kept surfacing. What was sold as a quick win consumed far more effort than anyone expected—and once it shipped, it became one more book on the shelf that nobody would dare remove.

The Sancho Approach

Sancho traveled light. His approach to products would be the same:

1. Carry Only What You Need

Sancho packed cheese, bread, and a wineskin. Not a ten-course meal. Just enough to get to the next town. Apply the same filter to your product: if you were rebuilding from scratch today, would you include this feature? If the answer is no, it’s a book for the bonfire.

2. Subtract with Courage, Not Panic

Anyone can add a feature. It takes courage to remove one—to tell a stakeholder “we’re cutting this” or to accept that something you built isn’t earning its place. Every feature has an ongoing cost: maintenance, cognitive load, surface area for bugs, documentation, onboarding complexity. The question isn’t “does anyone use it?” It’s “is it worth what it costs?” But don’t slash blindly. The priest and barber evaluated each book—some were worth keeping. Audit methodically. Measure usage. Talk to the users who depend on it. Then decide with data.

3. Create Space for What Matters

The library was cleared to make room for reality. When you remove the noise, what’s left has room to be great. Ask yourself: what could your team build if they weren’t maintaining features nobody uses?

Signs Your Product Needs a Bonfire

If any of these sound familiar, your product may be overdue for a bonfire:

• New users are overwhelmed—too many options, too many paths, too much to learn
• Support tickets about finding things—the product is so complex users can’t navigate it
• Team spends most time maintaining, not building—legacy features consume engineering time
• Nobody can explain the product in one sentence—you need three paragraphs and a diagram

Each is a library overflowing with books nobody reads.

The Feature Audit

Pick one area of your product this week. Pull up the usage data. For every feature in that area, fill in one line:

Feature name — Last meaningful update: ___. Monthly active users: ___. Maintenance hours/month: ___. If we removed it tomorrow, who would notice: ___.

Any feature where the last column is “almost nobody” is a book ready for the bonfire.

After the Bonfire

After the bonfire, Quixote’s room was cleaner, lighter, simpler. The madness didn’t end (he was Quixote, after all), but the noise was reduced.

Your product can have that same clarity. Not by adding the next great feature. By having the courage to remove the ones that aren’t earning their place.

Simple is hard. Simple is worth it.

Ready to start cutting?

The Priority Scorecard helps you decide what stays, what goes, and what gets built next.

Get the Template →