プロダクトの機能を減らすという意思決定

2019年にPMとして働き始めてから、よく「マイナーな機能を削除したら思いの外クレームが多かった」「一度出した機能を削除するのは大変」という話を目にする。そもそもニーズが無い機能をはじめから出さないことが鉄則であり、そのためのノウハウや知見も世の中に溜まってきてはいるが、そうはいっても失敗してしまうこともある。

この話の時に必ず入るのが「マイナー」「少数」といった単語である。ようは、当該機能によってユーザーにもたらされる恩恵の総量に対して、開発リソースの投資が見合っていないということだと理解している。ただ多くの場合、そもそもその見積もり自体が過小であることが多いと感じる。主な要因は以下の2つ。

1. 顧客がお金を払うということを過小に評価している

2. 問題を二者択一で捉えるのが早すぎる

顧客がお金を払うということを過小に評価している

BtoB SaaSを例に取る。多くの企業では業務で使うシステムやサービスの導入に際して相見積もりを取ったり、稟議を通す必要がある。たとえ稟議書を営業が作ったとしても、それを社内で説明するのは顧客の社員である。こうした社員は他にも複数の通常業務等を抱えており、その片手間で月に1回か2回程度ある決裁の場への説明資料を拵え、時には残業をし、やっとの思いで承認を得る。

さて、そんな苦労して導入したSaaSを使っているある部署から「昨日までできたことが今日できなくなった」と担当者へ一報が入る状況を想像しよう。怒る現場をなだめながら「具体的にどの業務ですか？」「それは本当に昨日からですか？」など詳細をヒアリングし、その内容を問い合わせ先へ送る。すると「先日のアップデートでその機能は停止しました」と返ってくる。担当者のメンツはもはや丸潰れである。

ビジネスというのは時に冷徹な判断をしなければならないというのはその通り。たとえこのようなことが起きると分かっていても、断腸の思いで決断しなければならないかもしれない状況も時にはあるとは思う。しかし、まずはこういった判断を限界まで避けようとするのが無難ではないだろうか。少なくともこの担当者に対して「技術的負債だったのでその機能は削除しました。これからは爆速で価値を届けられます」と胸を張って説明できる自信は私には無い。

問題を二者択一で捉えるのが早すぎる

あまり偉そうなことを言えた口ではないが、イノベーションというのは普通のアプローチでは解決できない、できたとしてもどこかにシワ寄せが言ってしまうような問題を、そうでない方法で解決するものだと考える。そしてプロダクトというのは基本的にはイノベーションでなければならない。

であるならば、そういったプロダクト開発に携わる人間が、「機能を削除するかどうか」というふう「普通の」アプローチを安易に取って良いのだろうか。そもそもその機能をより良いものにアップデートできないのか？当時何を思ってその機能をリリースしたのかちゃんと深堀りできているのか？せめて導線を少し変えるくらいに影響を留められないのか？などなど、いくらでも考えることはできる。

私の上司はよく「PMには7つのシコウが必要」と言っている。

PMが習得するべき「7つのシコウ」を解説！ エムスリー執行役員 / VPoE / PM 山崎聡が考える「PM育成」の指針 | キャリアハック（CAREER HACK）

これによれば、（機能削除に限らず）PMはまず①思考がベースにある。思考とはつまるところ、あらゆる選択肢を検討し、それぞれのメリット・デメリットを勘案し、ベストを選ぶということだと理解している。「削除すべきか否か」という二択にとらわれず、幅広い選択肢を考えるべきだと思う。

ちなみにエムスリーでは「ワイドオプションで考える」ということがよく求められるように感じるし、実際に上司へ相談すると考えてなかった選択肢を提示されるということはよくある。