プロダクトを公開しながら作るべき理由 [翻訳記事]

1. なぜ公開しながら作るのは इतनाにも怖いのか？

• Build in Public は、まだ完成していないプロダクトや考えをそのままさらけ出す必要があるため、「未完成・ミス・無知」がそのまま露出するように感じられる。
• 人は特に次のことを恐れる:
  • 他人に「ひどい」と思われるのではないかという評価や嘲笑
  • 間違った判断や誤った方向性が記録として残ること
  • 「あの人、レベルが低いのにどうしてあんなふうに共有するの？」といった評判リスク

2. それでもやるべき核心的な理由

• Build in Public は「すでに完成された立派な成果物」ではなく「過程」を見せるものなので、フィードバックの速度と学習の速度が圧倒的に速くなる。
• 頭の中の仮説に閉じこもるのではなく、実際のユーザーや仲間がリアルタイムで反応を返してくれるため、方向修正をはるかに早く行える。
• 同時に、似た道を進む人たちと自然につながり、「一緒に進む仲間の集団（community）」が形作られる。

3. 多くの人が誤解しているポイント

• 「公開しながら作る = 毎日派手な成果を出さなければならない」という思い込みがあるが、実際には「小さな進展、さらには行き詰まった点まで正直に共有すること」のほうが重要だ。
• また、「すでにうまくできる人、専門家だけができること」と考えがちだが、記事ではむしろ「学ぶ過程そのものを共有する人」のほうが、より大きな共感を得ると説明している。
• 完璧なストーリーテリングやブランディングを準備しなければと先延ばしにしがちだが、公開しながら作ることの本質は「不完全さを抱えたままでも出続けること（showing up）」だと強調している。

4. 具体的に何をどう公開するのか？

• 記事で提案されている公開項目の例は、おおよそ次のとおり（原文表現を参考にした要約）:[3][2]
  1. どんな問題を解こうとしているのか（Problem statement）
  2. 現在の仮説と実験計画（Hypotheses, Experiments）
  3. 週次/月次の進捗、指標、学び（Progress, Metrics, Learnings）
  4. 誤った意思決定、失敗、ピボット時点での振り返り（Failures, Pivots）
• 形式はさまざまだが、推奨されるパターンは、X・LinkedIn・ブログなどで「短く、頻繁に共有し、反応を見ながら少しずつフォーマットを磨いていく方法」だ。

5. 恐怖を減らすマインドセットと実行のコツ

• 視点を「自分がどう見られるか？」から「これを見る人にとって何が役立つか？」へ切り替えると、露出への恐怖が和らぎ、実用的な共有に集中できる。
• 記事のメッセージを整理すると:
  • 完璧になるまで待たないこと（Don’t wait to be ready）。
  • 少人数でも実際に助けられる人を思い浮かべながら書くこと。
  • 嘲笑や無関心はただのフィルターにすぎず、残る人たちは結局「同じ言語を話す仲間」だと覚えておくこと。