Illegible + open gives you capped downside while retaining exposure to upside.

Many times you don't know if a given feature that's being built is viable or not.

One way to do that is to build it carefully in a cave until it's of very high quality and then release it.

But this takes tons of time… and you still might be wrong.

High quality on a useless thing is useless.

Another approach is to iterate in public.

The metric to optimize is "Minimize the number of people who use it and have such a bad experience they never want to use it again, while secondarily maximizing usage."

One way to clear this bar is to have a perfect feature.

Another way to clear this bar is to have a resilient / forgiving audience.

You can get a resilient audience by having them self-select through a "gauntlet" that only the most motivated users make it through.

Openness means that people can self-select into your system and you don't need to find them.

You might be surprised where your best users come from.

Illegibility creates a kind of gauntlet.

Low-motivation people who happen across the feature will think "... what is this?" and bounce.

Only motivated users will stick with it to figure out what the thing is.

Motivated users are inherently more resilient.

If the feature isn't valuable, they think to themselves "well they did warn me…"

A few ways to create illegibility:

Don't have much polish (leave typos, etc).

Don't have clear explainers or READMEs.

Have documentation in a Google Doc, not a website.

Assume background context the reader might not have.

Connect nine of the ten dots.

Hide signal in a swarm of interesting but distracting details.