以下の問いに答えられるようにする。
- その機能を利用できるのはユーザー何％か？（ユーザーのプランによって利用可否がある場合など）、頻繁に利用されているか？
- それらのユーザーの生み出す収益は何％か？
- 利用率を向上させるためにどんな施策を行ったか？
- 機能を利用しなかったユーザーは、どんな理由によりそれを利用しなかったのか？
- もし時間を戻れるとしたら、自分たちはその機能を違う形に実装・デザインするだろうか、もしくは全く実装しないだろうか？
上記のすべてに答えることができ、かつもう一度チャンスを設けるべきだと説得できそうもなければ、その機能を削除する時だ。
あらゆる変更は既存の誰かのワークフローに影響を与えるものだが、削除しようとする機能に多くのユーザーが依存している場合は、ステップ2を検討しよう。
誰も使おうとしない機能がある場合、機能削除の第一歩として機能フラグ(Feature flag)を導入しよう。
機能フラグによって、新しいユーザーはその機能を目にすることがなくなる。あわせて、マーケティング用サイトからもその機能への言及を取り除くことができる。
ユーザーを、その機能にとっての本当のユーザーとちょっと試してみただけのユーザーに分けよう。
例えば削除する機能がカレンダーの場合、ちょっと試してみただけのユーザーとは「イベントを1〜5個しか作っておらず、数ヶ月の間イベントの追加や閲覧をしていない人」になる。本当のユーザーは多くのイベントを作り、週に一度はカレンダーを操作しているはずだ。
ちょっと試してみただけのユーザーは機能が削除されてもおそらく気に留めないが、本当のユーザーはワークフローが妨げられると不満を持つ。
まず、試してみただけのユーザーから機能を隠してしまおう。ここで機能が無くなったことをアナウンスすることもできるが、その手間に見合うだけの価値があることは稀だ。
どのような理由により何が起こるのかを適切に伝えるには、以下の要素が必要だ。
- ユーザーが何のためにその機能を利用していたのかということへの理解
- なぜ機能を削除するのかについての明快で一貫した理由
- 他の手段・方法の提案
- 一般的なフォーマットでユーザーがデータを回収するための方法の説明
他の製品などにユーザーが容易に乗り換えできるようにできればなお良いが、そのようなことは稀だ（誰も使わなかった機能には他の企業がそれを開発するほどの価値は無い）。
アナウンスから提供終了までの期間は1ヶ月〜1年程度が典型的だ。
ユーザーへのメッセージには以下のものが含まれるべき。
- 何が起きているのかということについてしっかりと明快にし、議論や推測の余地がないようにする
- 機能が利用できなくなる日付
- ユーザーに不便さを強いることへの共感（ユーザーはあなたが作ったものを使いにきてくれており、あなたはそれを削除するのだ）
- ユーザーがデータをいつどのように取得できるのかの手順説明（必要であれば）
- ユーザーが目的を達成するための代替手段の提案