OldLionの備忘録

年老いたライオンは錆びない。狩りを続け、振る舞いは日々深みを増していく。 いつまでも自分を忘れず、狩りを忘れぬライオンでありたい。 そんなライオンになるための日進月歩。

製品開発項目評価について ースタートアップはどう優先順位をつけるべきかー

製品開発部に配属されて2ヶ月、MRD(市場要件定義)を試行錯誤の元に繰り返してきた。企業の顧客が100とかを超してくるのであれば、既存の顧客や新規顧客から新規機能のペルソナを絞り込み、MVP(最小機能製品)の定義を実施することは比較的メソッドが固まっている。

- 第一検証:プランニングの検証=ユーザーヒアリングとユースケースを定義する

- 第二検証:デザインの検証=モックアップのUXをテストする

- 第三検証:プロダクトの検証=プロダクトを提供し、実際のユースケース通りに動くかテストする

- 第四検証:利用検証 =実際に製品が使われているか、使われていたとして望まれる結果は生まれたのか

これらのプロセスも非常に曖昧なことが多いので、よりオペレーションの枠組みを決定していくのは絶対に必要。

 

だが、問題なのは、例えば対象顧客が殆どいない段階での要件定義をどうやるのか、という問題。今直面し、今までも直面していたのは、業界を理解するメンバーからの声で全てのロードマップが決まってしまうことだ。

例えば、ケーキを作っているとしよう。そのメンバーが「競合は生クリームの口溶けを重視しているから、うちもそうしよう!」と言った時に、果たして受け入れるべきなのか、だ。受け入れた方がいいに決まっているけど、それが他の要件と比較してなぜ優先すべきか、が分からない。だが、否決する理由もない。これは要件定義に説得力を持たせる、という製品開発部を悩ませるタネになる。

正直、顧客の「肌感」を知っている現場の人間からの意見を無視できるほどPMやPMMは賢くないのだ。

 

まず、現場サイドで持つ大きな文脈でのあるべき機能を調査し、それをas is/to beで理想像から逆算して、反映させることである。これはTop-Downアプローチで、最早目の前のクライアントがどうこうとか関係なく、競合と自社が「どうしたいか」、顧客が「何を望んでいるはずだ」と仮説ベースで進めていく方法。これだと、顧客インタビューの欠陥があるとはいえ、説得力がある。なぜなら事業インパクトを最大化する軸での要件順位付けの結果であるはずだからだ。

 

問題は開発工数がかかるけど、その要望が Bottom-upで提案される場合。(上記のクリームの例みたいな) 絶対に優先すべきは「その機能がないと買わない機能」が出てくる時。これはペルソナが明確なので、製品要望として説得力を持たせやすい。

では顧客がいない時にはどうするべきか。アイデアとしてでしかないが、現場サイドと、対象顧客との課題の深堀りを行うこと、 そして考えられる反証疑問を一つでも多く用意することだ。

- 顧客が機能がないことでどのような課題を解決できないのか

- 課題を解決するのに今回の機能は必要十分な機能なのか

- その課題を解決したいと思うであろうクライアントはどんな企業か

- 優先順位は高いのか、低いのか(Revenue Impact/Churn Impact/ CH Impact vs Effort)

 

こう書くと簡単そうな感じがするけど、なぜその機能が必要なのか、が明確な機能はほぼないと言っていい。「今AAという課題に対してはBBという解決策があるけど、CCが必要なのはなぜ?」「CCは『あれば良い』くらいなのでは?」とか、「AAという課題が解決することで喜ぶのは本当はBBというペルソナで、今営業ターゲットしているDDとは相違がない?」とか、色んなことを考え、その要望を「やらない」としてジャッジできる決断力は大事な気がする。また、要望を上げてもらう時には要点を絞って説明してもらう必要もある。

往々にして、感情的になりやすいBottom-upアプローチ。現場でのNice to HaveをMustにする努力と共にあって初めて成り立つ気もするんだよね。