自分だけが決定を下す場合はセカンドオピニオンを得る

変更できる選択肢について尋ねる

具体的なビジネス上の質問を選択してください。オンボーディング ショートカットを構築するか、サービス パッケージを改訂するか、顧客の需要が確認されるまで機能を延期します。代替案、期限、何を約束するかを述べてください。実行可能であれば、現時点では何もしないことを現実的な選択肢として含めます。

モデルに質問する前に現在の希望を書きますが、必要がない場合は最初のブリーフから省きます。なぜそれを好むのかを個人的な日記に記録してください。後から、議論によって推論が変わったのか、それともすでに下した決定に対してより適切な言葉を提供しただけなのかを確認できます。

それぞれの視点に役割を与える

これらはリクエストされた推論視点であり、認定アドバイザーや統計的に独立した情報源ではありません。対応可能なエージェントを選択し、同じ事実についてAsk separatelyを使用してください。 Consensus を合成に招待する前に、元の出力を保持してください。 8 つのバリエーションが必要な場合は、指定された 8 つの視点を要求してください。ただし、その数を信頼性の尺度として扱わないでください。

奨励と反対の両方の裏にある証拠を求めてください。捏造されたリスクは、捏造された機会と同様に役に立ちません。モデル間の合意は、より大きなコミットメントに直接つながるのではなく、裏付けとなる事実に戻ることになるはずです。

• 顧客視点: 問題が解決する価値があることを示す証拠は何ですか?
• 実行の視点：どの依存関係が予定した結果を妨げる可能性があるか？
• 機会費用の視点: この選択によりどのような作業が置き換えられるでしょうか?
• 懐疑的な視点: 推奨事項が間違っていると判断する観察は何ですか?

例: 統合を構築しますか、それとも最初に需要をテストしますか?

架空のシナリオ: 個人創業者は 2 つの顧客から統合のリクエストを受けており、プロトタイプの作成に 1 週間かかると見積もっています。要望には、顧客が定期的に利用するかどうかは記載されていない。未解決のオンボーディングの問題もあります。これらは例示的な入力であり、お客様の事例研究や測定された開発見積もりではありません。

ディスカッションにより、次の小さなステップが明らかになる可能性があります。それは、実装をスケジュールする前に、要求している顧客に模擬ワークフローを示し、それをどのように使用するかを尋ねることです。もう 1 つの合理的な結論は、既存の証拠によって必要性がすでに確立されている場合に構築することです。値はそれらの選択肢を区別する条件であり、いずれかに確信を持って投票するものではありません。

有益なセカンドオピニオンを求めるプロンプト

回答を読んだ後、関連する抜粋と元の概要をConsensusに提出してください。最も強力な未解決の反対意見を保存し、今日下せる決定と、より多くの情報が必要な決定を区別するよう求めてください。あなたはアクションとジャーナルの所有者のままです。

決定: [選択と期限]。オプション: [オプション、可能な場合は延期を含む]。確立された事実: [事実と情報源]。仮定: [仮定]。制約: [時間、リソース、約束]。それぞれの選択肢について、最も強い主張、最も強い反対意見、および推奨事項を変更する証拠を述べてください。最小の実用的な次のチェックを提案します。顧客の需要や数値的な確率をでっち上げないでください。最後に、不明な点を常に見えるようにする意思決定ジャーナルのエントリを作成します。

観察してループを閉じる

チェック後にエントリを再確認する日付を設定します。何が起こったのか、どの前提が変わったのか、次のアクションが依然として正当であるかどうかを記録します。これにより、会話が説得力のあるアドバイスのコレクションではなく、学習の記録に変わります。

条件が欠落していると決定が変わる可能性がある場合は、追加の意見を使用します。単純な書き換えでは、モデルが 1 つだけ必要になる場合があります。 Colay はクレジットと制限を使用するため、追加の議論を、解決に役立つ具体的な不確実性と比較してください。専門的な専門知識や顧客の直接の証拠が必要な決定については、その証拠を直接求めてください。追加で生成された意見はそれを提供しません。

質問と回答