Marc Louの『バイラルプロダクト32原則』を日本語チェックリストにして、Claude Codeのユーザーレベルスキルに固定した
インディーメーカーの Marc Lou(@marclou) が「32 Principles of a Viral Product」という原則集をXに投稿していた。無料プランを持つな、色は3色まで、見出しは小学5年生に通じる言葉で、競合より高くしろ。買い切り型のプロダクトを量産してきた本人の経験則だけあって、一つひとつが Yes/No で答えられる形になっている。
このブログは無料で運営しているので出番はない。ただ、eurekapu の有料化のように課金を設計するプロジェクトはこれから複数あり、そのたびに原文を探して読み直すのは現実的でない。そこで全文を日本語に訳し、プロジェクトをまたいで使えるユーザーレベルのスキル(~/.claude/skills/viral-product-checklist/)として固定した。
チェックリストとしてスキル化する意味はあるか
結論から書くと、意味はある。ただし「憲法」としてではなく「レビュー観点集」として。理由は3つ。
1つ目は、ほぼ全項目が Yes/No で判定できる問いに変換できること。「LPの色は3色以内か」「CTAは1つか」「見出しに数字が入っているか」——採点者が人間でもAIでも同じ答えになる粒度で書かれている。曖昧な精神論の羅列なら翻訳して終わりだったが、この粒度ならレビューの道具になる。
2つ目は、発動場面がはっきりしていること。32項目は、LP執筆・価格設計・公開前レビューという作業の区切りにきれいに紐づく。「いつ読むか」をスキルの発動条件に書けるので、32項目を暗記する必要がない。
3つ目は、逸脱の管理に向くこと。全項目に従う必要はないが、「気づいたら無料プランを作っていた」のような無自覚の逸脱だけは防ぎたい。チェックリスト形式なら、No の項目に「意図的な逸脱(理由付き)」を残せる。従うか逸れるかより、逸れたことに気づいているかどうかが大事になる。
一方で、そのまま鵜呑みにできない部分もある。#13(波に乗る)や #19(見たことのないものを作る)は Yes/No で判定しにくい問いなので、スキルでは「企画メモに答えを一行書ければ Yes」と扱う運用にした。また出典は買い切り・B2C・LP一枚で売る前提の経験則なので、#1(無料プラン廃止)や #27(サブスク廃止)は B2B や変動費のあるサービスでは事業判断になる。スキルには「前提と読み替え」の節を設けて、この偏りを明記した。
32項目を訳しながら分類してみると、原則の重心がどこにあるかが見えてきた。
32項目のうち18項目が「何をどう書くか」の話で、技術の項目はひとつもない。個人開発者は実装で差を付けたくなるが、この原則集は逆で、売り場の言葉に紙面のほとんどを割いている。
32原則の日本語版
スキルに収めた全32項目を、5カテゴリに分けてそのまま載せる。
A. 価格・課金(7項目)
- 無料プランを持たない — 無料ユーザーはサポートとサーバー費用を増やし、有料顧客が求めない機能を要求する。無料からの転換は3%未満。無料プランは消す
- (#8) ハードペイウォール — 登録数は請求書を払わない。クレジットカードを出す人がいなければ検証になっていない。データを求める前に支払いを求める
- (#12) ポップコーン・プライシング — 訪問者は商品を買いに来たのであって、料金表の研究に来たのではない。プランを増やすたびに離脱の理由が増える。Good・Better・Best の3択まで
- (#16) 価格を見逃せない場所に置く — 訪問者は料金セクションを最初に見る場所のひとつにしていて、価格だけでなくプロダクトそのものを理解するのに使う。ヘッダーに「料金」を置く
- (#25) 買う前に触らせる — 最高の機能をペイウォールの裏に隠さない。ランディングページの上に置いて、払う前に遊ばせる
- (#27) サブスクにしない — 人はもう十分な数のサブスクを払っている。月額なしで出せるなら足さない。買い切りは10倍売りやすい
- (#32) 競合より高くする — 2番目に安い選択肢の話は誰もしない。高く付ける
B. コピー(11項目)
- (#3) 形容詞ではなく数字を使う — 「速い」は忘れられる。「毎週4時間の節約」は残る
- (#7) 小学5年生でもわかる見出し — 複雑さは好奇心を殺す。母親が読んでわかる言葉で書く
- (#9) 自分にしか書けないコピー — 競合のLPに貼っても成立する文章は、誰のものでもない。経験から書く
- (#14) 最高のコピーは顧客から借りる — 顧客はあなたよりうまくプロダクトを説明している。顧客が話すように書く
- (#17) 翌日も覚えている見出し — 見出しを5本書いて友人に見せ、24時間後にどれを覚えているか聞く。残った1本を使う
- (#18) 感情を動かす見出し — 人は機能ではなく感情を覚える。笑わせるか、驚かせるか、「なんだこれは」と思わせる
- (#21) 売り込みの前に共感を示す — 解決策を信じてもらう前に、問題を理解していると信じてもらう。相手より上手に問題を描写する
- (#24) 機能ではなく人間の欲望を売る — 人が買うのは、より多くのお金・時間・健康・地位と、より少ない苦痛。機能はそこへ運ぶ乗り物にすぎない
- (#26) 弱い言葉を使わない — 「ほとんど」「多くの」「めったに」は誰にも意味がわからず、主張を弱める。推定ではなく断言する
- (#28) 次に何が起こるかを言うCTA — 「はじめる」は何も伝えない。「自分のサイトを分析する」は、今から何が起こるかを正確に伝える
- (#30) 10語以内で説明できる — 自分が一文で説明できないプロダクトは、ユーザーも説明できない
C. LP構造・デザイン(7項目)
- (#2) 色は3色まで — 色はどれも注意を奪い合う。黒テキスト、白背景、購入ボタンに1色
- (#4) シェアしたくなるフッター — 訪問者の97%は買わないが、シェアはしてくれるかもしれない。人は最後に見たものを覚えている。強く締める
- (#5) OG画像はYouTubeサムネイルのつもりで作る — クリックされなければ見てもらえない。OG画像は本体サイトより多く見られることがある
- (#6) 1画面1アイデア — 一度に全部言わない。Instagramのフィードと同じで、1画面に主張は1つ
- (#10) 説明の前にプロダクトを見せる — デモは何段落分の文章より多くを伝える
- (#20) ヒーローセクションだけで売り切る — 訪問者の80%はヒーローから下にスクロールしない。数秒で理解と欲求を作れなければ、そこで終わり
- (#22) CTAはひとつ — ボタンが増えるたびに迷いが生まれる。道が複数あると、多くの人はどれも選ばない
D. 戦略(5項目)
- (#11) ひとつのことだけやる — 十徳ナイフは記憶に残らない。自分の問題を解決した道具が記憶に残る
- (#13) 波に乗る — 人々がすでに話しているトレンド・技術・問題の上に作る。波がマーケティングの半分をやってくれる
- (#19) 見たことのないものを作る — クローンは誰もシェアしない。驚かせる
- (#23) 覚えられる名前 — 誰もが知っている言葉を使う。言葉遊び・造語・説明が要る名前は避ける
- (#31) 競合と自分から比べる — 人はプロダクトが何をするかではなく、なぜ乗り換えるべきかを気にする。比較表で決断を明白にする
E. 信頼・証拠(2項目)
- (#15) 顔と声が見える創業者 — 人は人から買う。創業者の画面録画は、企業風のプロモ動画や機能の羅列に勝る
- (#29) 推薦の声なしで公開しない — 証言のないLPは、見知らぬ人に盲信を求めている。先に数人に使ってもらい、声を集めてから公開する
スキルの設計 — 場面で絞って当てる
スキル化にあたって決めたのは、32項目を一度に見せない構造にすることだった。チェックリストは長くなるほど形骸化する。そこで、作業の場面ごとに当てるカテゴリを固定した。
レビュー結果はチェックボックス形式で出させ、No の項目には「修正する」か「意図的な逸脱(理由)」のどちらかを必ず添えさせる。従わないこと自体は許すが、黙って逸れることだけを禁じる設計にした。
もうひとつ、矛盾して見えるペアの裁き方もスキルに書いた。たとえば #8(ハードペイウォール)と #25(買う前に触らせる)は一見ぶつかるが、「製品の中身は課金の裏に、体験できるデモはLPの上に置く」と読めば同時に成立する。無料プランを作らずに触らせる、というのがこの2項目の答えになる。#32(競合より高く)と #12(3プラン)も、「3プランの真ん中を競合の上に置き、最安プランで #32 を破らない」と裁いた。こういう解釈を書いておかないと、レビューのたびにAIが矛盾の解消から議論を始めてしまう。
置き場所と発動条件
スキルはプロジェクト配下ではなく、ユーザーレベルの ~/.claude/skills/viral-product-checklist/ に置いた。このブログ(mdx-playground)は無料サイトなので適用対象外で、スキル自身の適用条件にもそう明記してある。発動するのは、有料のWebアプリを作るプロジェクトで「LPをレビューして」「価格設計を見て」「ローンチ前チェック」のような指示を出したときか、LP・料金ページを新規に作るときになる。
原則集を眺めて感心するだけなら5分で終わる。訳して、分類して、矛盾の裁き方と読み替えの前提まで書いてスキルに固定しておけば、次に課金を設計する日には検品装置として動き出す。32項目の暗記ではなく、発動条件の設計に時間を使った理由がそれだった。