Write what you wish others had written.

It all started with an obstinate printer, and an early adopter desperate to leave Vista behind for the promised land of Windows 7. The printer, naturally enough, didn’t want to play along.

Google held no answers. HP didn’t support beta operating systems anyhow. I was left to tweak and try until I found something that worked. And when I did, I wrote down the answer in case others had the same issue.

It was the most niche article imaginable, something only people running a new OS with a printer only available in Asia-Pacific could need. Yet it was also the only article on the internet that answered those people’s questions—and so Google consistently sent the 80 to 100 people a day looking for a solution to my blog, until a few years later as Windows 8 then 10 (and the printer’s discontinuation) made the workaround unnecessary. In the meantime, though, it helped 84,129 people get their printers working, or at least get a little closer to finding the solution they needed.

The lesson stuck with me: Answering specific questions that no one else has answered is one of the best ways to get traffic from Google.

It continued to work. I couldn’t get the free WiFi to connect while getting my car’s battery changed—so I figured it out, wrote up the solution, and accidentally in an hour put together what became one of the most popular articles I wrote that year. Turns out WiFi and printers are universal annoyances.

Thus the concept of writing to learn—instead of waiting until you’re an expert to start sharing your thoughts. If you wait until you’re an expert, you’ll forget the tiny things that were frustrating along the way, the things you had to figure out by trial and error. You might even forget those simpler things and have to re-discover them over and again yourself. Instead, as you’re learning, write things down.

Share what you’re learning as you learn. Figure out the solutions no one else shared publicly yet. Publish them. Your future self might thank you when you hit the same issue and remember vaguely that there was a solution but can’t remember the exact steps to solve it. Others will reward you with traffic and page views, and perhaps they’ll become a fan of your work and a customer just because you helped solve their problem. And you never would have had the chance to do so if you hadn’t had the problem, solved it, and shared the hard-learned tip yourself.

ConvertKit founder Nathan Barry answered his questions about design and app development, then turned what he learned into the books and courses that launched his business. StackOverflow built community-answered questions into a $1.8 billion acquisition—and that was part of what inspired us to build Capiche into a q/a platform for all business software. Zapier’s wide-ranging content was built partly from finding solutions to the problems the team and customers found while connecting software—and our customer support almost felt like a centralized customer support for all business software, as you’d end up helping people solve their Gmail and Salesforce and other software issues while helping them build Zaps. Then that’d inspire new help docs and content, which would help new people which Googled those issues, and you had a viral loop that benefited everyone—Zapier and customers and random people on the internet alike.

Maybe that’s the better take on Move fast and break things. It’s move fast, break things, figure out how to fix them, then tell the world, as odds are some else will have accidentally broken those same things and need to fix them as well.