improve-business について
事業を続けながら成長が停滞した組織を、対話形式で診断・改善する再開可能なスキルです。戦略から実行、指標、利益率、価格設定まで8段階で進め、決定事項を `docs/` に記録します。
主な機能
- 01順序に沿った8つの事業フェーズ
- 02施策より先に診断
- 03対話型の決定とフェーズ計画
- 04`docs/` に再開可能な進捗を記録
- 05戦略・運営・指標の文書を作成
活用シーン
- 01売上停滞や解約の制約を特定
- 02戦略を週次の実行リズムに落とし込む
- 03チーム構造と管理方法を見直す
- 04利益率と価値に基づく価格設定を評価
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ wondelai/ skills --skill improve-businessインストール後、Claude Code で/improve-businessを入力して読み込まれたか確認します。
同梱ファイルreferences/artifact-templates.md
詳細
事業を改善する
すでに事業を運営しているものの、成長が止まってしまった事業者のための、対話形式で中断・再開可能な取り組みです。実際の売上があり、実際の顧客がいるのに、成長が横ばいになっています。8つのフェーズを通じて、各レイヤー(戦略、実行、マネジメント、構造、動機付け、指標、利益率、価格設定)に順番に取り組み、一度に1つの施策だけを追いかけるのではなく、対処の前に診断します。エージェントは意思決定の前に必ず質問し、選択内容をdocs/に記録するため、立て直しの取り組みはセッションをまたいで継続できます。
中核となる原則
停滞は診断の失敗です。対処の前に診断し、戦略、実行、マネジメント、構造、動機付け、指標、利益率、価格設定の順に取り組みます。 制約は複合的に作用するため、一度に1つの施策だけに手を入れても、停滞は解消できません。このスキルはフェーズを順序立て、意思決定の質問を行い、決定内容を記録します。個々のスキルが具体的な手法を担うため、独自のフレームワークを即興で作るのではなく、それらを呼び出してください。
取り組みの全体像
| フェーズ | スキル | 答える質問 | 成果物 |
|---|---|---|---|
| 1 | good-strategy-bad-strategy | 事業の成長に上限を設けている、唯一の課題は何ですか? | docs/STRATEGY.mdを作成 — GATE |
| 2 | traction-eos | 戦略を毎週どのように実行しますか? | docs/OPERATIONS.mdを作成 |
| 3 | high-output-management | 経営者はボトルネックになるのではなく、どのようにチームの力を高めますか? | docs/OPERATIONS.mdを拡張 |
| 4 | team-topologies | 組織構造そのものが制約になっていますか? | docs/OPERATIONS.mdを拡張 |
| 5 | drive-motivation | チームの意欲が気付かないうちに失われたのはなぜですか? | docs/OPERATIONS.mdを拡張 |
| 6 | lean-analytics | 真実を示す指標はどれですか? | docs/METRICS.mdを作成 |
| 7 | negotiation | 利益率が損なわれているのはどこですか?顧客が本当に価値を感じているのは何ですか? | docs/CUSTOMER.mdを拡張 |
| 8 | monetizing-innovation | 提供する価値に見合う料金を請求できていますか? | docs/OFFER.mdを拡張 |
運用ルール
- まず再開します。 何よりも先に、
docs/IMPROVE-BUSINESS-PLAN.mdと Journey Map 内のすべての成果物を読みます。トラッカーが存在する場合は、ジャーニーの状況を3~5行で要約し、どのフェーズに入るかを尋ねます。ユーザーが開始地点を確認した時点で完了です。トラッカーがあるジャーニーは再開し、決して最初からやり直しません。 - 初回実行時のみインテークを行います。 トラッカーがない場合は、以下のインテークを実施し、その後、すべてのフェーズのステータスを
pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reasonのいずれかにしたdocs/IMPROVE-BUSINESS-PLAN.mdを作成します。トラッカーが存在し、ユーザーがフェーズ計画を確認した時点で完了です。 - フェーズへの移行。 フェーズの目的、判断が必要な事項、作成される成果物、おおよその作業量を伝えます。続行/スキップ/延期の選択肢を提示します。GATE と記されたフェーズは延期できますが、スキップはできません。続行する場合は、フェーズを
in-progressにします。ユーザーが選択した時点で完了です。 - スキルの呼び出しと代替手段。 フェーズのスキルを読み込み、使用します。各フェーズの Invoke 行にはスキルのスラッグが記載されています。そのスキルを使ってフェーズを実行します。利用できない場合は、
npx skills add wondelai/skills/<slug> --globalを提案します。ユーザーが断った場合は、Brief に従ってフェーズを実行します。どちらの方法で進めるかを明示してください。 - フェーズ内の判断。 「ユーザーと決定する」の下にあるすべての質問を、具体的な選択肢と推奨案を添えて尋ねます。選択内容をトラッカーの「Key Decisions」に記録します。判断を黙って済ませるのは不備です。
- フェーズの終了。 書き込む前に、成果物のドラフト内容を提示し、承認を得ます。承認後、
docs/ファイルを作成または拡張し、トラッカー(ステータス、「Key Decisions」、「Next Actions」)を更新します。ファイルが書き込まれ、フェーズの行がdoneになった時点で完了です。 - 成果物の取り扱い。 書き込む前に読みます。ファイルがない場合にのみ作成し、すでにある場合は拡張します。自分のセクションを追加または更新し、他の人の内容は保持します。
docs/内のファイル名は大文字で記述します。すべての推奨事項は、担当者と優先度を記載したチェックボックスまたは表の行として残します。docs/ファイルを初めて作成する場合は、references/artifact-templates.md を参照してください。すべてのセクション見出しを含む完全なひな形からファイルを作成し、その後、フェーズで指定されたセクションを埋めます。 - 対策の前に診断を行います。 ユーザーが確認済みの「診断」が
docs/STRATEGY.mdに記載されるまでは、新しい取り組み、組織再編、価格変更を開始しません。フェーズ4、7、または8へ直接進むよう求められた場合は、まずフェーズ1を完了するか、すでに完了して記録されていることを確認します。対策フェーズの成果物を作成する前に、確認済みの「診断」が存在する時点で完了です。
インテーク
トラッカーを作成する前に、以下を確認します。
- どのような停滞が起きていますか? 収益が横ばい、解約率の上昇、チームが懸命に働いているのに何も進まない、といった状況でしょうか?(フェーズ1の診断とフェーズ6のOMTMを定めるために使います。)
- 現在、戦略と呼べるものは何ですか? 資料、OKR、目標のリスト、または何も文書化されていない状態でしょうか?(フェーズ1に役立ちます。何もなければ、診断作業が増えます。)
- チームの規模と構成を教えてください。(フェーズ2〜3のRocksと1:1の仕組みの規模を決め、フェーズ4に進むかどうかを判断します。)
- テクノロジーチームを運営していますか? それとも、サービス業や実店舗を中心とするビジネスですか?(
team-topologiesはエンジニアリングに特化しているため、テクノロジー企業以外ではフェーズ4をスキップします。) - 価格を最後に設定したのはいつで、何を基準にしましたか? コスト加算方式、競合他社、または価値でしょうか?(フェーズ8に進むかどうかを判断します。コストや競合他社を基準にした価格設定は、利益を取りこぼしている可能性を示します。)
- 営業の成約率はどのくらいで、価格への異議を耳にしますか?(異議がなく成約率がほぼ100%なら、価格が低すぎる兆候です。フェーズ8で扱います。)
- 業務が滞るのはどこですか? チーム内ですか、それともチーム間ですか?(チーム間の滞りはフェーズ4、チーム内の滞りはフェーズ3と5に着目すべきことを示します。)
フェーズをスキップする際の目安:テクノロジーチームを運営していない場合、またはチームがすでに円滑に成果を出している場合はフェーズ4をスキップします。士気が高く、制約要因になっていない場合はフェーズ5をスキップします。大規模な更新やベンダー契約がない場合はフェーズ7をスキップします。支払い意思を検証したうえで最近価格を改定した場合に限り、フェーズ8をスキップします。
テンプレートからdocs/IMPROVE-BUSINESS-PLAN.mdを作成し、フェーズ計画を確認します。docs/IMPROVE-BUSINESS-PLAN.mdにすべてのフェーズのステータスが記載され、ユーザーが計画を確認したら完了です。
フェーズ
フェーズ1 — 真の課題を診断する(good-strategy-bad-strategy)— GATE
目的: ビジネスを制約している唯一の重要課題を特定し、その後の各レイヤーが正しい制約に取り組めるようにします。この診断が確定するまで、フェーズ2〜8を開始してはいけません。
概要(代替手段): 優れた戦略には中核があります。それは、重要課題の誠実な診断、指針となる方針、一貫性のある行動です。悪い戦略とは、中身のない言葉や、戦略を装った目標、何にも集中できない40個の「優先事項」です。ファネルをチェーンリンクのシステムとして捉え、制約となっているリンクを1つ見つけます。弱いリンクを修正するまでは、強いリンクへの投資は無駄になります。チームが達成方法を見通せるほど身近な目標を設定し、やらないことのリストを必ず作成します。
呼び出し: 現在の年間計画、OKR、または資料を貼り付けて、good-strategy-bad-strategyスキルを使用します。次の内容を依頼します:(a)計画を戦略として監査し、0〜10で採点する、(b)適切な中核を作成する、(c)制約となっているチェーンリンクと、四半期の近接目標を1つ特定する。
ユーザーと一緒に決定する: 診断では、症状ではなく真の障害が特定されていますか? 制約となっているリンク(リード獲得/アクティベーション/リテンション/拡大)はどれですか? 近接目標は何ですか? やらないことのリストには何を含めますか? 意図的に何をやめますか?
成果物: docs/STRATEGY.mdを作成し、## Diagnosis(重要課題と制約となっているリンク)、## Guiding Policy(近接目標を含む)、## Coherent Actions(アクション|担当者|期限|ステータス)、## No-Listを記載します。トラッカーを更新します。
完了条件: STRATEGY.mdに、確定したDiagnosis、Guiding Policy、担当者を明記した3〜5件のCoherent Actions、No-Listが記載されていること。その後に限り、フェーズ2〜8に進めます。
フェーズ 2 — 実行のリズムを定着させる(traction-eos)
目的: 戦略を、月曜日以降も続く週次の運営リズムに変えます。
概要(代替案): トラクションのないビジョンは幻想です。四半期ごとに3〜7個の Rocks を設定します。それぞれに担当者を1人置き、SMARTかつ二者択一(完了か未完了かで判定し、部分点はなし)とし、直近の目標に照準を合わせます。Level 10 Meeting を導入します。同じ曜日・時刻に90分間実施し、固定アジェンダは60分の IDS(特定、議論、解決)で締めくくり、根本原因まで掘り下げます。決してキャンセルしません。
実行: traction-eos スキルを、STRATEGY.md の指針となる方針と直近の目標に沿って使用します。(a)担当者と二者択一の達成基準を設定した四半期 Rocks を5〜7個提案し、通常業務にすぎない項目には印を付けること、(b)時間配分を設定した Level 10 のアジェンダを作成すること、(c)最も頻出する課題に対して IDS を実施することを依頼します。
ユーザーと決めること: 今四半期に取り組む Rocks はどの5〜7個ですか(上限は7個)?それぞれの担当者は誰ですか?Level 10 の週次開催頻度と進行役はどうしますか?
成果物: docs/OPERATIONS.md を作成し、## Vision/Traction Summary、## Rocks (this quarter)(Rock | Owner | Binary done-condition | Status)、## Meeting Cadence(Meeting | Rhythm | Agenda)を含めます。トラッカーを更新します。
完了条件: OPERATIONS.md に、直近の目標に結び付いた、担当者が割り当てられた二者択一の Rocks が5〜7個記載され、ユーザーが実施を確約した Level 10 の開催スケジュールが設定されていること。
フェーズ 3 — 活動ではなく成果を管理する(high-output-management)
目的: オペレーターをボトルネックから外し、チームの成果を最大化します。
概要(代替案): マネージャーの成果とは、その組織および影響を与える隣接チームの成果の合計です。干渉、優柔不断、承認のボトルネックになるといった、レバレッジを損なう習慣は、悪影響を増幅させます。レバレッジの高いツールは、タスク関連成熟度(TRM)に応じて頻度を決める、部下が主導する1:1ミーティングと、モニタリングを伴う委任です。最もよく知っている業務を委任し、タスク単位でモニタリングします。TRMが低い場合は詳しくサンプリングし、上がるにつれて確認を軽くします。
実行: オペレーターの直近2週間のカレンダーと、何度も自分の手元に戻しているタスクを使って、high-output-management スキルを使用します。レバレッジ監査、予測される重要なイベントを軸に再設計した1週間の予定、直属の部下向けの1:1および委任の仕組みを依頼します。
ユーザーと決めること: どのような、レバレッジを損なう習慣をやめますか?部下ごとの1:1の頻度はどうしますか(役職ではなくTRMに基づいて設定します)?どのタスクをモニタリング付きで委任し、オペレーターをボトルネックから外しますか?
成果物: docs/OPERATIONS.md を拡張し、## Management Leverage(部下ごとの1:1の頻度、委任の判断、モニタリングの深さ)を追加します。トラッカーを更新します。
完了条件: OPERATIONS.md に、直属の部下全員の1:1の頻度と、オペレーターがボトルネックにならないようにする委任の判断が少なくとも1つ記録されていること。
フェーズ 4 — 価値の流れを軸にチームを再編する(team-topologies)
目的: チーム内ではなくチーム間で作業が滞り続ける場合に、構造的な摩擦を取り除きます。
概要(代替案): コンウェイの法則 — 提供するものには、コミュニケーション構造が反映されます。すべてのチームを次の4種類のいずれかに分類します。ストリームアラインド(デフォルト)、イネーブリング、複雑なサブシステム、プラットフォーム。認知負荷を抑え、各チームが担当する複雑なドメインは最大1つにします。単一のドメインを2つのチームに分割することは避けます。人員を増やす前に、ドメインを手放すか、余分な負荷を取り除きます。各インタラクションモードを定義します。コラボレーション、X-as-a-service、またはファシリテーションです。
呼び出し: 現在の各チームと日々の業務について、team-topologies スキルを使用します。チームの分類、アンチパターン(共有サービスのチケットキュー、価値の流れではなく機能ごとに分割されたチーム)の指摘、認知負荷の診断、明確なインタラクションモードを伴う価値の流れに沿った境界の提案を依頼します。
ユーザーと決定すること: まず、停滞の原因は構造的なものでしょうか(リードタイムの大半が引き継ぎに費やされる、調整会議が繰り返される、誰もが責任を持つ一方で誰も責任を持たない状態)?そうでなければ、このフェーズはスキップします。そうであれば、どのドメインを手放し、どの余分な負荷をプラットフォーム化するかを決めます。
成果物: docs/OPERATIONS.md を拡張し、## Team Structure(チームのトポロジー、チームごとの種類、認知負荷に関する注記、インタラクションモード)を追加します。トラッカーを更新します。
完了条件: このフェーズを理由を記録してスキップするか、OPERATIONS.md に4種類の分類と、インタラクションモードを伴う価値の流れに沿った構造案が記載されていること。
フェーズ 5 — 意欲を失った人々のモチベーションを再び高める(drive-motivation)
目的: 意欲低下に金銭を投入するのではなく、内発的動機を再構築します。
概要(代替案): 認知的な労力を要するタスクでは、条件付き報酬はパフォーマンスを低下させます。内発的動機を損ない、視野を狭め、短期的な思考を促すためです。モチベーションを持続させるのは、自律性(タスク、時間、手法、チーム)、熟達(退屈と不安の中間にある難易度への取り組みで、進歩が目に見えること)、目的(四半期を超えた、より大きな何かに貢献すること)です。金銭を意識しなくてよい水準まで報酬を支給したら、それを動機づけの手段として使うのをやめます。条件付きボーナスを、達成後の承認に置き換えます。
呼び出し: インセンティブ、評価、目標が現在どのように運用されているかを基に、drive-motivation スキルを使用します。AMP 監査を0〜10で採点すること、条件付き報酬を左右する仕組みがモチベーションを損なっている箇所を特定すること、さらに、達成後の承認への移行を含む自律性/熟達/目的に関する具体的な改善策を依頼します。
ユーザーと決定すること: どの条件付き報酬を廃止しますか?自律性を高めるどの手段(4つのT)を認めますか?承認を条件付きから達成後へどのように切り替えますか?
成果物: docs/OPERATIONS.md を拡張し、## Motivation (Autonomy / Mastery / Purpose)(手段 | 調査結果 | 改善策)を追加します。トラッカーを更新します。
完了条件: OPERATIONS.md に、各柱につき少なくとも1つの具体的な改善策を含む AMP 監査が記載され、条件付き報酬と達成後の報酬のどちらを採用するかの決定が記録されていること。
フェーズ 6 — 真実を伝える唯一の数値を測定する(lean-analytics)
目的: 見栄えだけの指標を並べたダッシュボードを、最もリスクの高い仮説に結びついた、誠実な一つの数値に置き換えます。
概要(代替案): 優れた指標は、比較可能で、理解しやすく、比率や割合(増え続ける合計値ではなく)、行動を変えるものです。次の行動が変わらない数値なら、追跡するのをやめましょう。右肩上がりの累積グラフは、見栄えだけの指標であることを示す代表例です。現時点でビジネスの最もリスクが高い部分について、OMTMを一つ選び、操作されないようにカウンター指標で保護し、目標、日付、未達時に取ると事前に決めた対応を明確に定めましょう。結果が出る前に決めておくことが重要です。
実行: 現在のダッシュボード、ビジネスモデル、事業ステージを使って lean-analytics スキルを実行します。見栄えだけの指標を実行可能な比率に整理し、OMTMとカウンター指標を定め、コホート別の継続率テーブルを作成して定着の基準を検証するよう依頼します。
ユーザーと決めること: どのビジネスモデルで、どのステージにいますか? OMTMとカウンター指標はそれぞれ何にしますか? 明確に定める目標、日付、未達時に取ると事前に決めた対応は何ですか?
成果物: docs/METRICS.md を作成し、## Stage & One Metric That Matters、## KPI Definitions(Metric | Definition | Actionable ratio? | Owner)、## Baselines & Targets(明確に定める目標を含む)、## Funnel、## Cohort Notes を記載します。トラッカーを更新します。
完了条件: METRICS.md にカウンター指標と明確に定めた目標を伴うOMTMが一つ記載され、見栄えだけの指標が実行可能な比率に書き換えられていること。
フェーズ 7 — 交渉で利益率を損なわない(negotiation)
目的: 契約更新やベンダー契約で価格を守り、顧客が本当に価値を感じているものを把握します。
概要(代替案): 良い取引への道は、相手に理解されていると感じてもらうことから始まります。悪い取引をするくらいなら、取引しないほうがましです。使える手法:非難監査(相手の異議を先回りして口にする)、調整型の質問(「どうすればよいというのでしょうか?」)、ラベリング(「…のようですね」)、アッカーマン・プラン(譲歩額を段階的に減らし、端数のある具体的な金額で締め、金銭以外の特典を添える)。競合の提示価格の裏にあるブラック・スワン、つまり秘密の制約、隠れた動機、知られていない背景を探りましょう。それが本当の事情であることはめったにありません。
実行: 対象の契約更新またはベンダー契約(数値、相手の圧力、あなたの直感)を使って negotiation スキルを実行します。非難監査、ブラック・スワンを明らかにするための調整型の質問を5つ、金銭以外の譲歩を含むアッカーマン・プランを依頼します。何かを得ずに譲歩してはいけません。
ユーザーと決めること: 重要な交渉ごとに、目標と交渉を打ち切る条件、交換する譲歩(無償では譲らない)、価格を理由に圧力をかける背景にある真の動機(ブラック・スワン)を決めます。
成果物: docs/CUSTOMER.md を拡張し、## Competing Alternatives に顧客が挙げる競合の提示条件とその実際の弱点を、## Interview Evidence に契約更新で明らかになった具体的な事実とブラック・スワン(顧客が実際に価値を感じているもの)を追加します。トラッカーを更新します。
完了条件: 非難監査、調整型の質問、アッカーマン・プランを用意して交渉に臨み、明らかになった真の動機がCUSTOMER.mdに記録されていること。
フェーズ 8 — 提供価値を基準に再価格設定する(monetizing-innovation)
目的: コストや競合他社ではなく、検証済みの支払意思額に基づいて価格を再設定し、利益率を回復します。
概要(代替案): 価格は価値を測る指標です。収益化の失敗パターンを特定します。feature shock、minivation(適切な製品なのに価格設定が控えめすぎる状態。兆候:勝率がほぼ 100%で、価格への異議がない)、hidden gem、または undead です。人口統計ではなく、支払意思額でセグメント化します。すべての機能をリーダー/フィラー/キラーに分類します。最安のプランでリーダーを提供したり、購入者がパッケージを拒否する原因となるキラーをバンドルしたりしてはいけません。変更をリリースする前に、許容可能/高額/法外という質問で必ず検証します。
実行: 現在の価格設定、プラン、勝率、商談データに加え、フェーズ 7 の支払意思額のシグナルを用いて、monetizing-innovation スキルを使用します。収益化の失敗パターンを診断し、各プランでリーダー/フィラー/キラーの分類を行い、価格変更をリリースする前に実施する支払意思額のヒアリングを設計するよう依頼します。
ユーザーと決定する事項: 証拠に最も合致する収益化の失敗パターンはどれですか?どのようなプラン再編を行いますか(実際に販売したいプラン、プレミアム価格の基準となるプラン)?再価格設定の前に支払意思額のヒアリングを実施しますか?
成果物: docs/OFFER.md を拡張し、## Offer Stack、## Willingness-to-Pay Evidence(Segment | Acceptable | Expensive | Prohibitive | Source)、## Leader / Filler / Killer Features、## Tiers (Good / Better / Best)、## Price Metric を追加します。トラッカーを更新します。
完了条件: OFFER.md に収益化の失敗パターン、リーダー/フィラー/キラーの分類、そして支払意思額の証拠に裏付けられた再価格設定後のプラン構成(または予定済みの支払意思額のヒアリング)が記載されていること。
オプションのフェーズ
| スキル | 追加するタイミング | 成果物 |
|---|---|---|
| blue-ocean-strategy | 市場がコモディティ化し、価格で競争している場合 | docs/STRATEGY.md を拡張(## Strategy Canvas & ERRC Grid) |
| hundred-million-offers | 価格設定だけでなく、オファー自体が弱い場合 | docs/OFFER.md を拡張(## Offer Stack) |
| jobs-to-be-done | 顧客が解約しており、製品がどのジョブを失ったのか誰も把握していない場合 | docs/CUSTOMER.md を拡張(## Job Statement、## Job Dimensions) |
| obviously-awesome | 市場がそのビジネスを誤解している場合 | docs/POSITIONING.md を拡張 |
| 37signals-way | 組織が計画に時間をかけすぎて、成果物のリリースが少ない場合 | docs/OPERATIONS.md を拡張 |
オプションのフェーズにも同じ運用ルールが適用されます。記載された各スキルを、コアフェーズと同じように正確に読み込んで使用し、「追加するタイミング」の条件が初めて成立した時点で挿入してください。
よくある間違い
| 間違い | 修正方法 |
|---|---|
| 診断の前に戦術へ飛びつく | まずフェーズ 1 を完了します。チェーンリンクの制約が、取り組むべき単一のリンクを示します。強いリンクに注力しても無駄です。 |
| 戦略オフサイトをゴールと見なす | Level 10 の定例運用(フェーズ 2)を導入し、決して中止しないでください。行動を変えるのは週次のリズムです。 |
| 忙しさと成果の創出を混同する | Grove の方程式(フェーズ 3)を適用します。自分が最もよく知っていることを委任し、TRM でモニタリングし、クリティカルパスから外れます。 |
| 問題が組織構造にないのに再編する | 引き継ぎがリードタイムの大半を占める場合に限り、フェーズ 4 を実施します。チームがすでに円滑に成果を出しているなら、省略します。 |
| エンゲージメントの低下に金銭を投じる | 適正な報酬を支払ったうえで、自律性、熟達、目的を再構築します(フェーズ 5)。if-then 型のボーナスを now-that 型の称賛に置き換えます。 |
| 価値ではなく、コストや競合他社を基準に再価格設定する | 価格への異議がないのに勝率が高い場合は、安く設定しすぎている兆候です。検証済みの支払意思額に基づいて価格を再設定し、それに応じてセグメント化します(フェーズ 8)。 |
ジャーニーの完了
終了チェックリスト:
- docs/STRATEGY.md に、確認済みの診断、指針となる方針、一貫性のあるアクション、やらないことのリストが記載されている
- docs/OPERATIONS.md に、担当者が明確な Rocks、Level 10 の定例、マネジメントのレバレッジ、(構造的な課題がある場合は)チーム構成とモチベーションの改善策が記載されている
- docs/METRICS.md に、1 つの OMTM、カウンターメトリック、撤退ラインが記載されている
- docs/OFFER.md が検証済みの WTP に基づいて価格を改定され、docs/CUSTOMER.md に更新時に明らかになった実際の決定要因が記録されている
トラッカーを締めくくります。すべてのフェーズを done または skipped: reason にし、未対応の Next Action はそれぞれ担当者を付けて、該当する成果物にチェックボックスまたは表の行として引き継ぎます。その後、次へ進みます。
- 基礎が再び機能し、目標が事業拡大に移ったら、
grow-businessスキルを続けてください。 - 事業を低迷させているのが製品そのものである場合は、
improve-appスキルを続けてください。