コーチングプラクティス： スタートアップの失敗を分析する

取り組んでいることをほぼ何でも入力すると、IX Coach が現実に最も合うプラクティスを見つけます。「スタートアップの失敗を分析する」については、現在のプラクティスライブラリからの最適な一致をご覧ください。

役立つかもしれないプラクティス

1. うまくいったことよりも「うまくいかなかったこと」に多くの時間を費やす
   失敗分析には、どんな正直なレビューにおいても最も実行可能な情報が含まれている。
   年次レビュー（ティム・フェリス・メソッド）
2. 分析においてシステムの原因と個人の原因を区別する
   ほとんどの失敗にはシステムの原因と個人の原因の両方がある。個人だけを修正しても、システムは同じ結果を再び生み出してしまう。
   アフター・アクション・レビュー：米陸軍の継続的学習ツール
3. 失敗した試みを行き止まりではなく制約の在り処として扱う
   失敗したアプローチはそれぞれ、動いている制約がどこにあるかを正確に教えてくれる ― 再挑戦する前にその情報を掘り起こす。
   制約緩和 ― 自分自身で築いた壁から抜け出す
4. 失敗の事後分析の個人ライブラリを構築する
   自分の領域における失敗のケーススタディを意図的に集め、読み、そこから学ぶ。
   生存者バイアス:見えないものから学ぶ
5. エラーをデータポイントとして扱う
   失敗の後すぐに、そのエラーが問題について明らかにした具体的な情報を抽出する。
   生産的な失敗: 先に苦闘することが指導をより効果的にする理由
6. この事例からの回復だけでなく、再発を防ぐよう修正を設計する
   根本原因の修正がこの発生だけでなく、原因そのものを永続的に排除することを確実にする。
   5つのなぜ
7. プレモータムを明確な成功のビジョンと組み合わせる
   失敗の分析を、成功に何が必要かについての同じくらい具体的な絵と均衡させる。
   プレモータム:すでに失敗したと想像する
8. アウトサイド・ビューの視点からプレモーテムを実行する
   プロジェクトが失敗したと想像し、それからどの基準率的な失敗タイプがそれを引き起こしたかを問う。
   アウトサイド・ビュー
9. 失敗後の正典的な対比
   自分の試みの後、専門家の解決策を、自分のアプローチが何を欠いていたかに特に注目して検討する。
   生産的な失敗: 先に苦闘することが指導をより効果的にする理由
10. エラーを隣接可能性の拡張イベントとして扱う
    何かがうまくいかなかったとき、その失敗が、成功であれば隠していたはずのどんな新しい領域を見えるようにしたかを問う。
    隣接可能性を実践する

自分の言葉で状況を説明する でプラクティスライブラリ全体を検索できます。