The initial product thesis
At the beginning, I thought Digging Music would be built around three core functions: wiki, reviews, and community.
The wiki was the most important part. I imagined a model somewhere between Namuwiki and Genius: a structured place where songs, lyrics, artists, albums, and the lyrics database in Digging Music could be collected.
The main target was not only fandoms. It was the general listener who searches for a lyric, a translation, or an explanation after hearing a song.
That meant Google Analytics was critical for Digging Music. The ideal situation was not simply that users would come directly to the Digging Music main page and search inside the service. Before that, Digging Music needed to appear in search results before scattered personal blog posts.
Trust as a search product
Lyrics and translation searches are heavily based on trust.
Personal blogs often use titles like "lyrics / translation / music video." That title is not elegant, but it gives users confidence that the page contains exactly what they searched for.
If a user searches for a song's lyrics and enters a site, only to scroll and find that the information is missing, the experience is bad. Search users do not want ambiguity. They want to know that the information will be there.
So the product needed to build a strong association:
If this song exists on Digging Music, then lyrics and interpretation exist there too.
This is similar to why people search for a celebrity and enter a wiki page with the celebrity's name, instead of clicking a personal blog title stuffed with keywords like blood type, height, hometown, and old photos. The wiki title wins because the site has accumulated trust.
For Digging Music, that meant one thing: a song should not be registered in a broken or incomplete state. If a song page exists, users should expect that the lyrics and interpretation are present, or at least that the page is clearly structured rather than empty.
Wiki, reviews, and community
The wiki was the anchor, but I did not think the wiki alone would be enough.
A wiki needs contributors. Namuwiki already has massive traffic, so editing it can feel like editing public infrastructure. Digging Music, at the beginning, had no such authority. There would be little motivation to edit unless the service had a surrounding ecosystem.
That is why reviews and community mattered.
The review feature was closer to Watchapedia. I wanted a relatively calm review culture where users could leave ratings and short thoughts about albums, songs, and artists.
Music reviews are different from film reviews. People often read film reviews before deciding whether to watch a movie, but music is easier to sample. In the time it takes to read a review, a user can simply play the song.
So I expected music reviews to function less as purchase guidance and more as self-expression. They would let users show taste, leave traces, and build identity around music.
The community feature was closer to existing music communities such as HiphopLE or Hiphopplaya. It would allow broader discussion about scenes, artists, news, releases, and cultural context.
Why combine the three functions?
The reason to combine wiki, reviews, and community was ecosystem design.
A point system only matters if there is a community where points can be recognized. Points on an empty island mean nothing. If users are going to edit a wiki, they need some kind of social context where contribution becomes visible.
At the same time, I was unsure whether self-expression would be enough as a motivation. It could also create bad incentives, such as low-quality edits made only to gain points.
Still, a contribution system seemed necessary because wiki editing needs some standard of trust and authority.
There was another problem I wanted to solve: music information is poorly organized.
If someone wants to see what people think about a specific hip-hop song, they often have to search the song title inside a community and manually filter through unrelated posts, passing mentions, and jokes. The information is not structured around the song itself.
A music wiki could change that. If each song had its own page, reviews, comments, lyrics, and interpretations could accumulate around a stable object.
In that sense, Digging Music was not just a wiki. It was also an attempt to build something like Watchapedia for music, combined with a scene-based community.
Genre, scene, and fandom structure
At first, I thought about dividing the service into broad categories such as rock, hip-hop, and pop.
EDM felt difficult because the Korean audience seemed relatively small. Ballads also felt structurally different because lyrics are often direct and the fandom structure is less concentrated around analysis. People may care more about singing style than interpretation.
The boundary between genres was also a problem. A single post could belong to hip-hop, pop, and K-pop at the same time. That made me consider multi-select categories rather than forcing every post into one board.
This later connected to the idea of using the word "scene" instead of "genre." A scene is more flexible.