Two key points of product development that Markdown has taught us
language
eng
date
Jan 29, 2026
slug
markdown-product-lessons
author
status
Public
tags
markdown
summary
What initially felt like a barrier to entry, Markdown has become the basic syntax for communicating with LLMs through notes, development, and blogs. We learn again from the history of Markdown the core of product development: precisely defining simple inconveniences and solving them in an even simpler way.
type
Post
thumbnail
category
😎 Daily
updatedAt
Feb 10, 2026 09:45 PM
About five or six years ago, when I was bouncing between different note-taking tools, the first real barrier I ran into was Markdown syntax. Most of the newer note apps were adopting Markdown, and the idea that you had to know Markdown to use a note tool was harder to accept than I expected. With Evernote, which I had been using, you could just click buttons to turn text into headings or apply formatting. With Markdown, you had to remember symbols and type them at the right moment—and that felt unfamiliar.
But if you take a quick look at the syntax and keep using it, you soon realize it’s such a simple structure that calling it a “language” almost feels like an exaggeration. And once you get used to it, it becomes genuinely convenient: you can change the structure of a document directly from the keyboard. Since then, I’ve used Markdown not only in note tools, but also in GitHub, software development, blogging, and even in Notion—the very tool I’m writing this in now.
After the “ChatGPT moment,” Markdown expanded beyond note apps and code into the world of LLMs and AI. In particular, it has become one of the most basic “grammars” for communicating with LLMs, solidifying its position and role.
One surprising fact I didn’t know for a long time is that Markdown—this lightweight syntax used across so many contexts—was created by an individual named John Gruber, who simply found it annoying to write blog posts in raw HTML.
Two key lessons to take away
- In product development, it’s crucial to define the “pain” clearly—even if it seems obvious.
- Markdown: “Writing blog posts in HTML is too tedious.” (Problem definition)
- In product development, it’s equally crucial to solve that defined pain in the simplest and easiest way possible.
- Markdown: “Use just a few symbols to express structure, separating ‘writing’ from ‘presentation.’ And open it up so anyone can use it.” (Solution)
Markdown was able to dominate because it was open—widely adopted and eventually treated as a standard. In a capitalist system, the idea and culture of open source projects and contribution can feel uniquely strange: something that isn’t purely about generating profit, but can still help society and other projects. Why did this way of working flourish more in software than in other fields?
One reason open source is especially powerful in software is that the cost of copying is close to zero (once it exists, anyone can use the exact same thing), and developers around the world tend to face the same problems. As improvements accumulate, everyone benefits. On top of that, software lives and dies by standards and compatibility—once a “common way” emerges, it becomes valuable in and of itself. Markdown hit that exact point. It was simple enough that anyone could implement it, readable anywhere, and not locked into any specific company or product. That reassured people, and eventually the shared agreement—“this is simply the easiest way to do it”—solidified into a standard.
And now we’re in the era of LLMs. Maybe the value of open source isn’t only in “free software,” but also in how small contributions from a community create shared data and conventions that raise future productivity. Markdown proved that in the quietest and most practical way. Before big ideals, it chose something simpler: define the pain precisely, solve it as simply as possible, and leave it open for anyone to use. That choice invited more people to participate—and helped build a wider standard. The core principles of product development I rediscovered through Markdown ultimately arrive at the same place.
Related posts
The Future of Vibe Coding, as I See It
May 6, 2026
Vibe coding makes it seem as if anyone can build software now, but beneath that promise lie new constraints: token costs, platform moderation, market concentration, and relentless quality competition. This essay looks at the future of vibe coding from both optimistic and skeptical angles, and argues that what we really need is not a fantasy of easy money but the ability to adapt to the AI era.
talkie: The Language Model Frozen in 1930
May 1, 2026
An experiment in conversing with talkie, a language model trained only on texts written before 1930. From lunar travel and Korean independence to predictions about 2026, it is a fascinating record where the biases and insights of a century-old worldview collide.
Labor song recommendation channel - An era where anyone can create, yet some are still chosen.
Feb 27, 2026
With AI-composed concentration music overflowing in YouTube work playlists, a sense of 'familiar yet unappealing' fatigue has emerged. As this happens, channels that create song selections and videos manually become even rarer. Even in an era where anyone can create, there is a clear reason why certain content gets chosen.