
PdMマインドセット "Not how, but why."
こんにちは、株式会社 ROXX back check 事業部の Shohei です。
先日、同じ PdM チームの同僚と一緒に「ワカンダフォーエバー」を見ようということで、公開初日に劇場へと足を運んできました。
仕事を忘れて映画世界に存分に浸っていたのですが、劇中の「重要なのは How じゃない、Why だ。」というセリフによって、元自衛隊員に起床ラッパを聞かせて起こすドッキリ動画のごとく脳ミソが一気に仕事モードへと引き戻されました。
これから鑑賞する PdM の方はご注意ください。
プロダクトマネジメントに携わるようになって半年ほど経つのですが、PdM においてこの「Not how, but why.」の重要性と、同時に脆さも感じています。この note ではその2つについて考えていきます。
余談ですが、MARVEL シリーズを追っていないチームマネージャーに劇中のセリフのことを話すと「良い映画ですね」と言っていたため、何か誤解を与えてしまったかもしれません。
真の問題を理解する
プロダクトには日々多くのフィードバックが寄せられます。
私たち BtoB のプロダクトではフィードバックソース元は顧客、ユーザー、社内メンバーやステークホルダーなど多岐に渡ります。
これらを眺めていると「こういう機能を追加してほしい」というリクエストが多いことに気付かされます。
これらのリクエストは一見合理的で、魅力的に映ります。しかし「追加してほしい」という事象は真の問題が引き起こしているものに過ぎず、その真の問題はリクエストした本人の無意識の中に閉じられていることがほとんどです。
プロダクト開発に携わるものにとって、見た目に惑わされず要望の核心に迫り、真の問題を理解することを常に心がける必要があります。
脆さ
真の問題を理解することが重要だと頭では分かっていても、数多くのフィードバックを眺めていると、そこで見つけた (一見) 魅力的なリクエストに一目惚れして、ふと手を伸ばしたくなることが起こりえます。
その How を拾い上げてしまうと、「この機能を追加すれば、あの課題も解決するかもしれない」と点と点が繋がったように感じられてしまい、その How に合いそうな課題を探して当てはめようという考えにまで及んでしまうことがあります。
最悪のケースだとアイデアに合いそうな課題を作りだそうとすらしてしまうかもしれません。
これはいくら気を付けていても起こりうることで、アイデアを漫然と採用してしまうケースだけでなく、「ユーザーのことはよく理解しており、こういう課題は存在するのだ」という思い込みが引き起こしてしまうこともあります。
フィードバックの項目に組み込む
どんなに魅力的な How であってもすぐに飛びつかず、ユーザーの実在の問題を解決するものなのかを注意深く検討しなければなりません。
これを普段から心がけるためには、マインドセットを変える必要があるかもしれません。
マインドセット(mindset)とは、自身の習性として根付いた物の見方や考え方、を意味する表現。「思考態度」と訳されることもある。先入観・信念・判断基準・無意識の思い込み、等々の思考の傾向を指す。
「マインドセットを変えるぞ」といくら強く誓っても、具体的な行動に落とし込まないと習慣づけることはできないはずです。決意を新たにすることは人間を変えるのに全くの無意味だとも言われています。
人間が変わる方法は三つしかない。一つは時間配分を変える、二番目は住む場所を変える、三番目は付き合う人を変える、この三つの要素でしか人間は変わらない。もっとも無意味なのは、「決意を新たにする」ことだ。かつて決意して何か変わっただろうか。行動を具体的に変えない限り、決意だけでは何も変わらない。
弊社ではこの「行動」をフィードバックフローの項目として組み込むことで、マインドセットの変化を仕組みとして補っています。
フィードバック項目
顧客やステークホルダーからのフィードバックを報告するフォームには、以下の項目を含んでいます。
フィードバックの原文をそのまま記載
課題や事実を記載 (解決策は書かず、課題の事実を書いてください)
顧客 (ユーザー) はどうなりたいか
「フィードバック原文」には How が書かれていることが多いです。
ただただユーザーからのフィードバックを集めようとすると、この原文レベルの情報ばかりが集まってしまうでしょう。情報が狭かったり偏っていたりと、真の問題を掘り当てるにはまだまだ難易度が高いと感じると思います。
「課題や事実」は記述者に真の問題への一歩目を踏み出すキッカケを与えます。何が起きていて、なぜその How を欲しがっているのか、事実を捉えようと考えることは情報の偏りを補正できると考えています。
「顧客はどうなりたいか」の項目は PdM が強く欲している情報であり、Why へのアプローチの大きな助けとなるはずです。
まとめ
フォーマットだけでは書き手の属人的スキルの差を完璧には埋められないため、PdM が情報収集に動くべき範囲となりますが、手がかりが得られているため幾分も楽になるはずです。
記述する機会の多いセールスや CS にとっても、このフォーマットに沿ったフィードバックを繰り返すことで、顧客から得る一次情報の質の向上も期待できます。