こんにちは、DMMオンラインサロンのプロダクトマネージャーの金子です。

オンラインサロン事業部のプロダクトマネージャーとして、組織が注目するポイントを「機能」から「課題」にシフトするということに取り組んできました。

私は、機能について考えるタイミングを遅らせれば遅らせるほど、ユーザーに早く価値を届けられる、と思っています。

そう思う理由と、課題に注目するために行ったことを紹介します。

機能に注目している状態とは？

上のいずれかに当てはまる場合、課題ではなく機能に注目している状態になっているかもしれません。

早すぎる段階で機能に注目すると、小さいユーザー価値を届けることに大きなコストを注ぎ込んでしまう、という恐ろしいことが起こります。

機能に注目すると何が悪いのか

機能を出すことが目的になってしまう

こんなことをステークホルダーから言われたり、自分自身で感じたことはありませんか？

私は、プロダクトマネージャーになってすぐにこの壁にぶち当たりました。
課題ではなく機能に注目していると、いつの間にか機能を出すこと自体が目的になってしまい、「ユーザーの課題を解決して、価値を届ける」という、本来やりたかったことからどんどんずれていってしまいます。

つまりは、ビルドトラップというプロダクトマネジメントの「罠」にかかってしまっていた状態でした。

ビルドトラップについてはこちらの記事がとてもわかりやすいので、ぜひご覧ください。

ユーザーへの価値提供が遅くなる

私は、早すぎるタイミングで機能に注目してしまうと、ユーザーへの価値提供が遅くなると考えています。

一見すると「早く作る機能を決めて、早く機能をリリースすれば、早くユーザーに価値を提供できるのでは？」と感じるかもしれませんが、真逆の結果を生みます。

なぜ価値提供が遅くなるかというと、主に2つの理由があります。

早すぎるタイミングで作る機能を決めてしまうと、その機能が誰の何の課題を解決するのかがあやふやなまま開発が進んでしまいます。
そして、他の機能の可能性を考慮しないまま、なんとなく良さそうな機能の開発が始まってしまい、以下のループにハマります。

このループが常態化すると、あらゆる観点で不健康になっていきます。

その結果、ユーザーに価値を提供できないまま、インパクトが小さい機能がどんどん増え、プロダクトが複雑になり、ユーザーが離れてしまう...といったように、プロダクトの成長を完全に止めてしまうことにつながりかねません。

課題に注目する空気をつくる

プロダクトの成長が止まることを避けるためには、機能ではなく課題に注目することが大切です。
さらに、個人ではなく組織で課題に注目すると、より良いサイクルを生むことができます。

組織全体が課題に注目するために、私が行ったことを2つ紹介します。

課題でコミュニケーションを取る

もともとオンラインサロン事業部では、セールス、マーケティング、カスタマーサクセスなどのステークホルダーから機能要望を吸い上げて、スプレッドシートで管理していました。

機能要望なので、「機能」や「やりたいこと」が書いてあり、それが実際にどれくらいのユーザーが望んでいるのか、それに関する行動データがどうなっているのか、は可視化できていませんでした。

そのため、PdMが無数にある要望の中から優先度が高そうなものをピックアップして、1つ1つの機能要望に対して深堀りする必要がありました。もし「優先度が高そう」という仮説が外れていたら、それをひたすら繰り返していく…といった形です。

ただ、このプロセスを日々進んでいく開発と同時にこなしていくには、単純に物量が多すぎて無理がありました。さらにPdMがボトルネックになってしまう可能性もありました。

なので、機能要望ではなく課題そのものを吸い上げるようにしました。
私は、誰か1人が課題を深堀りするよりも組織全体が課題を深堀りする方が強いプロダクトを作れると考えているので、メンバーそれぞれが深堀った課題を起票して、それを吸い上げる、というアプローチに変えました。

具体的には「誰の、どういう課題を解決したいか」を明確にしてスプレッドシートに起票するように運用を変更して、課題を吸い上げられる土台をまず作りました。

もちろん、シートのフォーマットが変わればいきなり改善されるわけではありません。フォーマットを変えたのは、あくまでコミュニケーションの土台にするためです。

課題管理シートを定期的に見る会を開き、会の中で課題を深堀ったり、課題が明確でないものは再考してもらったり、事実を掴みきれていないものはデータを取ったりすることで、課題を深掘るという行為が自然なものになるように、空気をつくっていきました。

わりと地味めな取り組みだと思いますが、ステークホルダーと接点を多く持ち、課題に注目するコミュニケーションを取り続けることが大事だと思っています。

ロードマップに課題を書く

機能ではなく課題に注目するためのもう1つの取り組みとして、プロダクトロードマップに課題を書き込むようにしました。

今まではロードマップに機能が書かれていたので、どうしても目標が「〇〇機能をリリースする」のように機能に引っ張られ、その機能をリリースすること前提でスタートしていました。

こうなると自然と「○月○日までにリリースしなければ…！」というメンタルになってしまい、機能の目的や誰の何の課題を解決するのか、を一度立ち止まって考え直すことがとても難しくなります。

なので、ロードマップに課題を書き、機能リリースではなく課題解決を目標としました。

ロードマップに課題を書き込むために、まずプロダクトマネジメントチーム主導でユーザーのオンラインサロンの体験を可視化しました。

可視化したユーザーを元に、DMMオンラインサロンが大切にしているものを明らかにし、ビジョン・ミッションのリニューアルも進めました。
ここについては別の記事で紹介したいなと思っています。

定量的・定性的な調査を並行しながら、リニューアルされたビジョン・ミッションをベースに、事業部長や各チームリーダーなどのステークホルダーを巻き込み、サービスの課題を洗い出して優先度をつけ、優先度が高い課題をロードマップに入れました。

その後、優先度が高い課題を解決するために、どういう解決策がふさわしいのかを考え、具体的な機能に落とし込み、優先度をつけ、課題に紐づけてロードマップで管理しています。

これにより、もともとは

という流れだったのが

という流れに変わりました。

本当に直近の取り組みなのでまだ具体的な成果は出ていませんが、流れが変わったおかげで開発せずに課題を解決できたり、より解像度の高い解決策が出てきたりすることを期待しています。

ロードマップに関しては、こちらの記事を目がちぎれるぐらい参考にしました。
本当にありがとうございます。

まだ悩んでいること

課題起票運用の厳密さ

課題を起票できる土台ができたので、機能名だけが起票されることはほとんどなくなりましたが、起票されるものすべてが深堀られた課題になったかというと、そういうわけではありません。（そもそもそれが正しい姿か、というと違う気もしますし）

課題を深掘るのは時間がかかるプロセスですし、それに慣れているメンバーとそうじゃないメンバーでも負荷が違います。

課題を起票できる土台を作った意図は、ユーザーから「〇〇機能がほしい」というリクエストがあれば「つまり何が課題なんだろう？」という風に、課題を深掘ることを自然な行為にしたい、という意図です。

ですが、ここの運用をかっちりしすぎると、そもそも課題や要望自体が表出しなくなる、という新たな課題が生まれます。

ここの調整は難しいところですが、試行錯誤しながら、他の取り組みなども絡めて、少しずつちょうどいいポイントを見つけていきたいなと思っています。

課題を深掘れる環境が行き届いていない

SQLを書いてデータ分析ができる環境が事業部全体に浸透しきっていないため、定量的な課題の深堀りができるメンバーが限られています。

これによってスムーズに課題の深堀りができない状態になってしまっているので、組織全体として課題を意識して、より良いプロダクトを作っていけるようになるためには、組織のほとんどのメンバーが自然にデータ分析できる環境が必要だと感じています。

人事評価・予算獲得スケジュールとのズレ

「取り組む課題を決めたあとに、解決策（機能）を考える」という風にプロダクト開発の流れを変えたので、どうしても今までよりも具体的な解決策が出るタイミングが遅くなります。

ユーザーに価値を届けるまでは早くなっているはずですが、解決策が出るまでは遅くなるので、解決策をベースとした人事評価や予算獲得のスケジュールとはギャップが生じます。

解決策がセットでないとそもそも予算獲得自体が難しい、ということも場合によってはあると思いますし、ここは目標設定などとも足並みをそろえていかなきゃいけないと考えています。

まとめ

今回紹介したもの以外にもたくさんの取り組みがあるので、また別の記事で紹介したいなと思います。

今でも試行錯誤しながらプロダクトマネジメントを実践しているので、ぜひみなさんの意見や経験もお聞かせください！

ここまで見ていただき、ありがとうございました。
ぜひフォローをお願いします🙇‍♂️