PdMはお客様からいただく機能要望とどう向き合うべきか
こんにちは。LayerXの本間(@maro)です。バクラク申請とバクラク経費精算のプロダクトマネージャー(以下、PdM)をしています。
最近、息子が拍手を覚えました。落ち込んだ時は息子に拍手を強要して元気を取り戻しています。
--
さて、PdMとしてプロダクトロードマップを決め、それに伴い機能の開発優先度を決めることって難しいですよね。
お客様からいただくご要望、プロダクトビジョンの実現、事業数値へのインパクト、リソース……様々な変数を元に「どのような順序でどうプロダクト成長させることが最適解なのか」を常に考えています。
その中で「お客様のご要望解決だけではプロダクト成長が鈍化するな」と感じることがあります。その背景と「お客様から頂くご要望と機能開発優先度をどうリンクさせてロードマップを描くか」を記事にしました。
記事の前提となる「バクラク申請・バクラク経費精算」というプロダクトの概略は以下のとおりです。
プロダクトカテゴリは「法人支出管理のBtoB SaaS」
すでに多くの企業に導入いただき、複数の業界/企業規模でのPMFが達成されている状態
マルチプロダクト/コンパウンドでのプロダクト拡大を担う1サービス
お客様からいただくご要望は宝。その宝からどう価値を生み出すか
バクラクではお客様から月間1,000件以上のご要望を頂きます。ほぼ全てのご要望にPdMが目を通し、ご要望の裏に隠れたニーズ把握や分類を行っています。
そして、頂いたご要望数や事業インパクトなどを元にRICE（Reach、Impact、Confidence、Effortの頭文字をとった言葉。プロダクト開発の施策それぞれに優先度のスコアをつけるための手法）的なスコアリングを用いて機能の優先度付けを行い、開発ロードマップの作成や見直しをしています。
「頂いたご要望の数が多い」ものは機械的にスコアが上がり、開発優先度は高くなりがちです。この考え方は納得感も高く、不確実性も低く、堅実なプロダクト成長を実現する指標になります。
とはいえ、それだけではプロダクトの非連続な成長にはならず、他サービスとの均一化の道を辿ってしまいがちなんですよね。
大前提、お客様からいただくご要望は宝であり、そのご要望によってプロダクト成長は支えられております。
でもそれだけでいいんだっけ？
「非連続な形でプロダクトバリューを実現するとPdMとして常に向き合う必要があるなぁ」と最近強く感じます。
お客様からいただくご要望から何を導くか、何を作るか
お客様からいただくご要望の多くは「〇〇で困っているのでXXができるようになって欲しい」というフォーマットが多いです。俗に言う「課題」と「解決策」というやつです。
そのご要望をどのような観点から捉えるかで、機能開発は大きく変わってきます。ざっくり自分の中では5つの分類をし、お客様のご要望を元にどのような解決策を導き出すのかを考えています。
その1. 頂いた解決策をそのまま機能検討する
いわゆる「基礎的な機能」はこのケースが多く、BtoB SaaSの場合は一般的な業務フローに従ってプロダクトの利用をする際に「XXがないと業務が進まない」ような機能がこれに該当します。他社サービスとの比較時に◯✕表で表されるようなものですね。
私達のプロダクトを例にすると、「プロダクトの多言語化」などです。(実現に向け目下企画設計中です！)
このようなご要望の場合、ただ実装するのではなく「どうすればより使いやすく、わかりやすく、汎用的にご利用出来る形でお客様に機能を届けられるか」の体験づくりに注力をするケースが多いです。
その2.頂いた解決策とは別の形で機能を検討する
「〇〇で困っているのでXXができるようになって欲しい」というご要望に対し、XXとは別の機能でお客様に価値を届けるケースです。
このケースについてはバクラクのプロダクトデザイナー森さんのnote に超具体的な事例含めて紹介されているのでぜひご覧ください。
その3. 頂いた課題が課題ではなくなるような機能を検討する
その2と近しいのですが、「その課題を解決する」のではなく「その課題自体が課題ではなくなる」ような機能を検討するケースです。禅問答みたいですね。
例えをあげると
「XXの検索をしたい」という要望は「検索せずに必要な情報/コンテンツにたどり着くためにはどうすればよいか」と考える
「印刷したい」というご要望は「紙を使わずに業務を進めるため(印刷しなくてもよくする)にはどうすればよいか」
「〇〇の設定を一括で変更したい」という要望は「変更という業務が発生しなくするにはどのようにすればよいか」と考える
などなど。
左から右に流れる業務フロー図を描いた時「課題に感じている業務」のひとつ前の業務が改善すれば、その業務課題自体が発生しなくなること、ままあるんですよね。
この考え方はアイデア/特別な発想から生まれるわけではなく、徹底的なお客様の業務理解の上に成り立っていて、「誰が・いつ・何をトリガーに・どんな操作環境で・どんな業務をするか」をお客様にお伺いしながら、解決すべきを一緒に探っていくことで見つかります。
—
お客様から頂いたご要望をそのまま作らず「あるべきは何か、よりよい体験は何か」を追求する その2、その3 がバクラクがバクラクらしさたる所以なのかもしれません。
その4. そもそも要望として頂かないものも
少し毛色が違います。お客様からご要望を頂かないけど、課題として解決すべき事項も存在します。
例えばバクラク経費精算の場合。機能に関する様々なご要望を頂くことはあれど、「経費精算をなくして欲しい」というご要望をお客様から頂いたことはありません。
恐らくどの企業も「経費精算に関する業務なんてなくなればいいのに…」って思っているはずなんですよね。業務がなくならない前提で「どうなればもっとラクに正しく処理ができるか」と要望を頂きます。
PdMというロールでプロダクトの機能優先度を決めたり、ロードマップを検討したりする中で、どうしても「プロダクトありき」で考えがちになります。
定期的に立ち止まり「業務の本来あるべき姿」から考えて、それに近づくためのアプローチをしていく必要があります。それが経費精算システムの場合は、" 経費精算がなくなる世界 " だったりします。
その3の「頂いた課題が課題ではなくなるような機能を検討する」と近いんですが、全体の業務フロー図を描いた上でその業務一つひとつがなくなれば、そのサービスは不要になります。
その5. あえてやらない
頂くご要望の中には「お困りごととして把握したものの、あえて実装しない」という機能も多くあります。
もちろん、お客様のご要望をなおざりにするという話ではありません。
この「やる・やらない」の根本にある思想はコーポレートミッションやプロダクトビジョンに基づいています。
LayerXではコーポレートミッションに「全ての経済活動を、デジタル化する」を、バクラクのプロダクトビジョンに「圧倒的に使いやすいプロダクトを届け、ワクワクする働き方を。」を掲げています。
機能実装によってデジタル化からは離れてしまうような業務フローになってしまったり、「課題は解決できるが使いやすさを損ねる」体験を提供してしまうような機能要望に関しては、"あえてやらない"選択肢も取ります。
とはいえ、お客様のお悩みや課題感を無視するというわけではなく、「バクラクなりの解決策」を模索しながら課題解決に挑んでいます。これがその2,3の「別の形で機能検討」「課題を課題ではなくなるように機能検討」に繋がっています。
「あえてやらない」という選択肢を取る場合、開発メンバー・ビジネスメンバー共に「なぜやらないのか」を自身の言葉で説明し、全員が納得した状態で意思を統一することも必要になってきます。
—
フラットに「本来どうあるべきなんだっけ」からバックキャスティングでプロダクトの成長を描く。
言われると「そりゃあ大事だよ」と感じます。ただ、お客様からのご要望を叶えるだけに注視すると、見えなくなりがちです。
「本来どうあるべきか」が実現できれば、そもそもいまお客様が抱えている課題が課題ではなくなることもあります。
お客様の課題とあるべき姿、両軸から機能開発の優先度を考えていきましょうというお話でした。
その実現が難しくて私も日々悩んでいるんですが。
We are Hiring!!
一緒に経費精算がなくなる世界作っていきませんか？
LLMや機械学習を使うことで、経費精算の入力や確認がなくなるかもしれません。あるべき業務フローを定義しそれに最適化されたプロダクトを作ることで、「経費精算」という行為自体がなくなるかもしれません。
私が担当するプロダクトに限らず、バクラク全体として「あるべき」を追求し続けています。
最近、バクラクPdMチームのインタビューやブログ記事をまとめたポータルサイトもオープンしたので、ぜひご覧ください！
カジュアル面談も大募集中です！語りましょ〜！
この記事が気に入ったらサポートをしてみませんか？