フレームワーク活用ガイドひとことで言うと#
**「顧客の声を聞く → 要望通りに機能を追加 → それでも成長しない → もっと顧客の声を聞く」**という悪循環（デスサイクル）を理解し、そこから脱出するためのフレームワーク。顧客の「要望」を聞くのではなく、「課題」を理解することが鍵。
押さえておきたい用語#
- デスサイクル（Death Cycle）
- 要望→実装→成長しない→また要望を聞く…と繰り返すプロダクト衰退の悪循環パターンのこと。自覚できないまま陥りやすい。
- フィーチャークリープ（Feature Creep）
- 機能がじわじわ増え続け、プロダクトが複雑になりすぎて本来の価値が埋もれる現象のこと。デスサイクルの典型的な結果。
- 要望と課題（Request vs Problem）
- 顧客が言う「〜が欲しい」は要望、その裏にある「〜に困っている」が課題のこと。PMは課題に焦点を当てるべき。
- アサンプションテスト（Assumption Test）
- 新機能の前提となる仮定を小さな実験で事前検証する手法のこと。デスサイクルから脱出した後の健全な開発に不可欠。
プロダクトデスサイクルの全体像#
こんな悩みに効く#
- 機能をどんどん追加しているのに、ユーザー数が増えない
- 顧客の要望に応え続けているのに、満足度が上がらない
- プロダクトが複雑になりすぎて、新規ユーザーが使いこなせない
基本の使い方#
以下の兆候がないか確認する。
- 機能リリースのペースは速いが、主要指標（MAU、売上、NPS）が横ばいまたは低下
- バックログが「顧客の要望リスト」になっている
- 新機能を出しても利用率が低い（10%未満）
- プロダクトが複雑になり、新規ユーザーの離脱が増えている
- 「次の機能を出せば変わる」と何度も言っている
ポイント: 3つ以上当てはまったらデスサイクルの可能性が高い。正直に現状を認めることが第一歩。
なぜデスサイクルに陥っているのかを分析する。
- 顧客の「要望」と「課題」を混同していないか？ — 「ダッシュボード機能が欲しい」は要望。その裏にある「進捗を一目で把握したい」が課題
- 既存顧客の声だけを聞いていないか？ — 既存顧客は自分のワークフローに合った機能を求める。新規顧客の獲得にはつながらない
- ビジョンなき機能追加になっていないか？ — どこに向かっているかが不明確だと、要望に振り回される
ポイント: 顧客の声を「聞くな」ではない。「要望の裏にある課題を聞け」。
悪循環を断ち切る具体的なアクションを取る。
- ビジョンを再定義する: プロダクトが解決すべき核心的な課題を1つに絞る
- 機能を引き算する: 使われていない機能を削除またはアーカイブする
- 要望の裏を掘る: 顧客の要望に対して「なぜそれが必要ですか？」を5回聞く
- 新規顧客にフォーカス: 既存顧客の要望ではなく、まだ顧客になっていない人が抱える課題に目を向ける
ポイント: 機能を削るのは怖いが、複雑なプロダクトで新規顧客を獲得する方がもっと難しい。
デスサイクルに戻らない仕組みを作る。
- 新機能の追加前にアサンプションテストを必須にする
- 機能リリース後の利用率を必ず計測し、低利用機能はリタイアさせる
- バックログの優先順位を「顧客の声の数」ではなく「課題の深刻度×影響人数」で決める
- 定期的に「この機能はビジョンに合っているか？」をレビューする
ポイント: 「作る理由」と「作らない理由」の両方を言語化できる状態が健全。
具体例#
デスサイクルの状況:
- 2年間で80の新機能をリリース
- MAUは横ばい（5,000人前後）
- 新規登録→7日後の継続率が15%（低い）
- 既存ユーザーの声: 「ガントチャートが欲しい」「Slack連携が欲しい」「タイムトラッキングが欲しい」
- これらを順番に実装してきたが、成長は止まったまま
診断結果:
- 80機能中、利用率10%以上はわずか12機能
- 新規ユーザーが初回ログインで「機能が多すぎて何から使えばいいか分からない」
- 核心課題: 「タスク管理をシンプルにしたい」というコアバリューが機能の山に埋もれている
脱出アクション:
| アクション | 内容 |
|---|---|
| ビジョン再定義 | 「5人以下のチームが、最もシンプルにタスクを管理できるツール」に回帰 |
| 機能の引き算 | 利用率5%未満の30機能を「アドバンスド設定」に格納（デフォルト非表示） |
| オンボーディング改善 | 初回ログイン時に3つのコア機能だけを案内するウィザード |
| 新規フォーカス | 既存顧客の要望リストを凍結。新規ユーザーの離脱原因分析にリソースを集中 |
結果: 6ヶ月後、新規登録→7日継続率が15%→35%に改善。MAUが5,000→8,500に。既存ユーザーからの不満は予想より少なかった（使っていない機能だったため）。
デスサイクルの状況:
- 導入企業120社、大口顧客10社の要望を優先的に実装
- 過去1年で追加した28機能のうち、全体利用率10%以上はわずか4機能
- 大口顧客の解約は防げているが、新規契約数が月8社→月3社に減少
- 理由: プロダクトが複雑すぎてトライアル中に離脱
根本原因:
- 大口顧客10社のカスタム要望がバックログの72%を占めていた
- 要望の例: 「独自の承認フローを組みたい」「自社ERPとの連携」「監査ログの出力形式変更」
- これらは10社にとっては重要だが、残り110社と新規見込み客には関係ない
脱出アクション:
- 要望の裏にある課題を再分析: 「独自の承認フロー」→ 課題は「承認の遅延で支払いが滞る」→ 汎用的な自動リマインダーで解決可能
- 大口顧客の要望はAPI/Webhookで外出し: カスタマイズはプラットフォーム側で吸収
- 新規向けの「10分で初回請求」体験を再設計: 機能一覧ではなくコアバリューに集中
結果（8ヶ月後）:
- 新規契約: 月3社 → 月12社
- トライアル→有料転換率: 8% → 22%
- 大口顧客の解約: 0社（APIで要望をカバーできたため）
- 開発チームの「カスタム対応工数」が月120時間 → 月30時間に削減
大口顧客の声に応え続けることと、プロダクトを成長させることは別問題。課題の本質を掘れば、少数のカスタム要望を汎用的なソリューションに変換できる。
デスサイクルの状況:
- 生徒数180名の地方学習塾
- 保護者の要望に応え続けた結果、コースが3年間で8→22に増加
- 「プログラミング教室」「英検対策」「速読コース」「作文教室」「理科実験」等
- 生徒数は180名で横ばい、講師の稼働は限界
診断:
- 22コース中、受講者10名以上はわずか5コース
- 12コースは受講者3名以下（赤字）
- 保護者アンケート: 「いろいろあって迷う」「結局何が強みかわからない」
- 新規問い合わせの48%が「コースが多くて選べない」で離脱
脱出アクション:
- ビジョン再定義: 「中学受験に強い塾」に絞る（地域ニーズに合致）
- コースの引き算: 22→6コースに縮小（中学受験に関連しないコースは全廃）
- 廃止コースの生徒: 近隣の専門教室を紹介（信頼関係維持）
- 講師リソースの集中: 空いた時間を中学受験の指導品質向上に投入
結果（1年後）:
- 生徒数: 180名 → 240名（「中学受験に強い」と明確になり新規増）
- 合格実績: 地域トップ校合格率42% → 68%
- 保護者満足度（NPS）: +12 → +48
- 講師の残業時間: 月平均35時間 → 月平均15時間
「選択肢が多い＝顧客に優しい」は幻想。ビジョンに集中し、不要なコースを引き算したことで、品質も集客力も大幅に向上した。
やりがちな失敗パターン#
- 「顧客の声を聞くのは正義」と思い込む — 顧客は自分が本当に欲しいものを正確に言語化できない。行動データとインタビューを組み合わせて課題を理解する
- 機能を削る決断ができない — 「一部のユーザーは使っている」と言い訳して機能を残し続ける。プロダクトの複雑さはユーザー体験の敵
- デスサイクルの自覚がない — 「次の大型機能を出せば変わる」と信じ続ける。データを冷静に見て、同じパターンが繰り返されていないか確認する
- 既存顧客の声だけでロードマップを作る — 既存顧客の満足度は上がっても、新規獲得に繋がらない。「まだ顧客になっていない人」の課題を理解する時間を確保する
まとめ#
プロダクトデスサイクルは「顧客の声に忠実に機能を追加し続けることが、実はプロダクトを殺す」という逆説を教えてくれるフレームワーク。脱出の鍵は、要望ではなく課題を聞くこと、機能を足すだけでなく引くこと、そしてビジョンに立ち返ること。「次の機能を出せば変わる」ではなく、「何を作らないか」を決める勇気が必要。