オンラインでのパフォーマンスなしに、公共の構築者になる方法

オープンな開発はフィードバックシステム

オープンな開発者は、製品の作成プロセスを共有します：意思決定、実験、進捗状況、間違い、および証拠。目的は、常に注目を集めることではありません。それは、開発者、潜在的なユーザー、および製品を改善できる他の人々との距離を短縮することです。

うまく行えば、オープンな開発は3つの資産を生成します。より明確な製品のストーリーを開発し、一貫性のある証拠を通じて信頼を獲得し、ローンチ前に問題を理解しているオーディエンスを構築します。これらの資産は、個々の投稿がほとんど注目されない場合でも役立ちます。

適切なレベルの透明度を選択

すべての収益数や個人的な詳細を公開する必要はありません。事前に共有するのに安全で役立つものを決定します。製品の意思決定、顧客からの教訓、デモ、ロードマップの変更、および匿名化されたトレンドは、多くの場合、分析ダッシュボードからのスクリーンショットのストリームよりも価値があります。

プライベートな情報をプライベートに保つ: 顧客データ、セキュリティの詳細、機密契約、およびチームメンバーが公開することを同意していないもの。持続可能な透明性には境界線があります。明確な境界線は、心配することなく共有し続けることを容易にします。

反復可能な更新形式を使用

最も簡単な役立つ更新は、何が変わったのか、なぜ変わったのか、次に何が起こったのか、そして何をテストするかを説明します。この構造は、発表を小さなケーススタディに変えます。読者は何かを学び、結果を単に賞賛するのではなく、その理由に答えることができます。

一貫性が頻度よりも重要です。考え抜かれた週ごとの更新は、多くの場合、中断する日常的な断片よりも強力です。構築中にメモを取り、維持できるスケジュールで簡潔な概要を公開します。

• 文脈: 最初に想定したユーザーの問題または仮定。
• 行動: 構築、削除、測定、または変更したこと。
• 証拠：定性的なフィードバックと重要な指標。
• 次のステップ：その後の意思決定または実験。

証拠とエージェンシーと失敗を共有

正直さは、公の自己批判を必要としない。効果的な失敗の投稿は、期待、観察された結果、および修正を記述する。十分な詳細を提供することで、信頼性を保ちつつ、チームが学習し、行動できることを示す。

エンゲージメントのための脆弱性の製造を避ける。もし、教訓が明確に説明するのにまだ早い場合は、待つ。最高の公開の振り返りは、顧客や類似の意思決定に直面している開発者にとって、間違いを再利用可能な知識に変える。

注意を実際の製品ループに結びつける

聴衆は、人々が関連する次のステップを実行できる場合にのみ役立つ。読者に、安定した製品ページ、デモ、事前登録、変更ログ、またはフィードバックチャネルを提供する。ユーザーが経験に基づいて回答できる、具体的な質問を投げかける。その後、彼らの入力がどのように変化したかを示すことで、ループを閉じる。

インプレッションを超えた結果を追跡する：質の高い会話、アクティブなユーザー、維持されたユーザー、紹介、および製品の改善。繰り返し支援し、購入する少人数のグループは、大規模なパッシブなフォロワーよりも価値がある。

維持できる評判を構築する

公開での構築は、記録が検索可能で一貫性がある場合に効果的。重要なアップデートを、耐久性のあるページに保持し、関連する意思決定をリンクし、時間経過とともにマイルストーンを文書化する。ソーシャル投稿はストーリーを拡散するが、製品ページとサイトはそれを保持する必要がある。

今週、1つの有益なアップデートから始める。1つの意思決定を説明し、実際の証拠を含み、特定の応答を求め、結果を示す。公開での構築は、ローンチの戦術ではない。それは、進捗を可視化するための実践である。