Nobody owes you their attention. The opening line is the only part of a post that everyone reads, so it has to do real work: name the problem, name the reader, and promise something specific.

Cut the warm-up. The paragraph you wrote to get yourself going is almost never the paragraph a reader needs. Delete it and start at the second one.

Write short sentences when the idea is hard and longer ones when it is easy. Rhythm is comprehension. If a sentence takes two passes to parse, it is not clever, it is broken.

Finally, end on something the reader can do tomorrow. A post that changes nothing was a diary entry.

Writing that actually gets read

Features are easy to count and impossible to un-ship. Each one adds a setting, a support question, an edge case in the code, and a line in the onboarding no one reads.

The best products are not the ones that did the most. They are the ones that decided early what they were not going to do, and held that line while competitors added everything.

Ask of every request: does this make the core thing better, or does it make the product bigger? Bigger is not better. Bigger is just harder to explain.

Say no kindly, say it early, and write down why. The list of things you declined is a product document in its own right.

The case for fewer features

Small teams win on latency, not effort. When the person with the idea can build it the same afternoon, you learn faster than anyone waiting on a planning cycle.

Protect that. Every process you add puts distance between deciding and shipping. Some of that distance is worth it. Most of it is habit.

Keep the group small enough that everyone holds the whole picture in their head. Once you need a diagram to explain who owns what, you have already lost the advantage you were trying to scale.

Ship something every week, even if it is small. Momentum is a real asset and it depreciates quickly.

Quiet Margin

Latest posts

Writing that actually gets read

The case for fewer features

How small teams move fast