こんにちは、ROBOT PAYMENTの伊藤です。
請求業務を自動化するクラウドサービス「請求管理ロボ」のPMをしています。
突然ですが、「開発ロードマップ」を決定する際の優先度ってどうやって決めていますか？
- 顧客からの要望が多そうな機能から？
- すぐに開発ができそうな機能から？
透明性のある意思決定を効率的に行うためにも、開発の優先度決定はデータという客観的な根拠に基づくべきですよね。
弊社ではこのようなデータドリブンなプロダクトマネジメントを行うために、今年からProductboardというツールを導入しました！
この記事では、Productboardの導入に至った背景、導入の効果やポイントについてご紹介したいと思います。
Productboardとは？
まずはProductboardとはなんぞやという話ですが、一言でいうと
開発判断に必要な情報を一元管理して、ステークホルダーに対して可視化するための、プロダクトマネジメント支援ツール
です。
プロダクトマネジメントでは、プロダクトビジョン・顧客要望・開発リソースの三方を見ながら、プロダクトの価値を最大化するために何を開発して、何を開発しないかを決める必要があります。
やってみてわかったのですが、プロダクトマネージャーという役割は意思決定の連続です・・・決めないと何も進みません。
この際にやってはいけないのは、たまたま手元にあった情報を元に何となくで決めてしまうことです。
一貫性のある意思決定ができなくなるし、ロジックがないと判断に時間がかかってしまうので非効率でもあります。
これを防ぐためにあるべき状態は、
- 意思決定に必要なデータが一元管理されている
- データを元に、開発可否を判断する指標が定量化・可視化されている
- 開発判断基準が明確である
かと思います。
Productboardはこのような「データドリブンなプロダクトマネジメント」を実現してくれるWebサービスなのです。
導入に至った背景
そもそも今回なぜProductboardを導入するに至ったのか。弊社では主に３つの課題を認識していました。
その１：もっと幅広く顧客要望を集めたい
弊社では利用企業から何らかの要望があった場合は、CSやサポートデスクが専用のGoogleフォームに登録する運用をしています。
しかし流石に全ての利用企業に常時聞いて回るわけにはいかないので、どうしても利用企業にとって影響度の大きいものや明示的なリクエストがあったものが主になってしまいます。Nice to Haveレベルや接点の少ない利用企業の要望は拾いきれていませんでした。
一方、弊社から利用企業へのコミュニケーションはどうでしょうか。
弊社ではプレスリリースやリリースノートで機能追加や不具合修正を公表させていただいているのですが、内容は完了の報告が主になります。
しかし、利用企業側では今後の開発予定についても気にしています。
最近では改正電子帳簿保存法やインボイス制度に関して、たくさんの利用企業から対応予定のお問い合わせをいただきました。
この際に開発予定を確認できる公式チャネルが無いので利用企業はCSやサポートデスクに直接確認しなければなりません。結果、重複した照会も発生してしまいます。
このような状況を改善するためにも、今後の開発予定について弊社から積極的に情報開示を行い、幅広くフィードバックをいただく仕組みが必要なのではと考えていました。
さらに失注関連の情報をプロダクト開発に繋げる仕組みが無いという課題もありました。
特定の機能が不足していることによって、多くの失注が発生しているのであればそれも踏まえて開発対象を決めたいですよね。
弊社ではSalesforceで商談管理を行っていたので、この情報をプロダクト開発にも活用したいとも考えていました。
その２：開発判断に必要な情報を効率的に収集・管理したい
顧客要望を収集したら次は何をするでしょうか？
収集した要望から開発候補となる機能を抽出しプロダクトバックログを作成、各種指標を元に優先度設定を行い、開発すると決まったらロードマップに組み入れる必要があります。
これらの作業は、基本的に全てスプレッドシート上で手作業で行っていました。
ご想像に難くないと思いますが、これは中々のハードワークです・・・
特にロードマップは開発優先順位の入れ替えが発生することが少なからずあるので、その度にスプレッドシートをいじくる必要があります。（田本さんお疲れ様です・・・）
プロダクトのスコープ、開発リソースともに今後も増えていく想定なので、スプレッドシート管理からの脱却は喫緊の課題でした。
その３：開発する機能を定量的な指標で評価する仕組みを作り、見える化したい
「プロダクトバックログから次は何を開発するべきか？」は常にプロダクトマネージャーの頭を悩ませる問題です。
この点、弊社では明確な判断基準がない状態でリスト全体を見ながら優先度を判断していたのが実態でした・・・
このようなやり方だと毎回判断に時間をかけてしまいますし、他の社内ステークホルダーから見たときに意思決定のプロセスが明確ではありません。
定量化された指標に基づく明確な判断基準を導入する必要がありました。
Productboardで出来ること
これらの課題を解決する手段としてProductboardを導入することを決めたわけです。
ここではProductboardを選定する理由となったポイントを3つご紹介します。
その１：顧客要望を一元管理できる
Productboardではあらゆる情報ソースからの顧客要望（Insightと呼ぶ）を一元管理することができます。
しかもメールやSalesforce、Slack等の外部サービスとの連携機能があるので、登録の自動化がとても簡単です。
更に登録したInsightの中に特定の機能に関する要望があった場合は、開発候補（Featureと呼ぶ）として登録しInsightと紐付けておくことができます。このFeatureに紐付ける際に得点を０〜＋３で設定することができ、後で説明するUser Impact Scoreが計算されます。これによりどのFeatureがどの程度顧客から要望されているかが一目瞭然になるのです。
その２：開発判断に必要な指標を定量化できる
開発候補はFeatureと呼ばれ、Feature boardという画面で一覧することができます。
あらかじめ判断指標を定義・入力しておけば、こちらの画面で各Featureの開発判断指標を確認することが可能です。
CS・営業、開発チームにもここを見てもらうことで、どのような機能が要望されているか、今後何を開発しようとしているかについて共通認識を持つことができます。
ちなみに判断指標は基本的に企業やプロダクトに応じてカスタムで定義・設定することになりますが、Productboard標準で用意されているものもあります。ここでは、弊社で活用している以下２つを紹介しておきます。
- User Impact Score：顧客からどの程度要望されているFeatureかを定量化したスコア。先ほど説明したInsightの紐付けから積み上げられる。
- Opportunity Value：Featureを提供することで見込める新規MRR。
これら標準の指標とカスタム指標を組み合わせて、プロダクトに応じた判断指標を定義します。
その３：ロードマップのメンテナンスが簡単
Productboardにはロードマップ機能もあります。
開発が決定したFeatureに対して開発開始・終了予定日を設定できるのですが、それを元に開発ロードマップを自動表示することができます。
ちなみに、この画面上で開発予定をずらすと自動的に開発開始・終了予定日も変更してくれます。痒いところに手が届いてます！
その４：Portal機能で開発予定を外部に公開できる
登録したFeatureはPortal という機能を利用して外部に公開することができます。
各Featureは開発予定機能としてカードで表示され、利用企業は中身を確認するだけでなくコメントすることも可能です。
これにより利用企業に開発予定を周知し、更に幅広いフィードバックを効率的に収集することが出来ます。
実際にProductboard自体もこの機能を利用して今後の開発予定を公開しています。
導入のポイント
この記事を書いている時点では、Portal以外の機能について社内でパイロット運用を開始した段階です。
ここではパイロット運用を開始する前に、実施しておくべきポイントをいくつかご紹介します。
その１：顧客の声を集約する仕組みを構築する
顧客要望をInsightに集める仕組みを構築する際には、既存のプロセスをなるべく変えないことを念頭に置きました。
まだどのようなやり方が正解かわからない状態でしたので、一気に変えるのではなく、既存のデータを既存の形式で取り込み、内容を見ながら調整していくアプローチです。
結果、既存の入力方法には大きな変更を加えること無く、顧客要望をInsightに集約するフローを構築しています。
Salesforceとは標準の自動連携機能、GoogleスプレッドシートについてはZapierを利用して自動連携を実現しています。
実際に取り込んだInsightをFeatureにマッピングして、計算されたUser Impact ScoreとOpportunity Valueを見ると予測と合っている部分と合っていない部分があり、とても興味深いです。特にOpportunity Value（＝機能を提供することで獲得できる見込みMRR）は、「こんなにMRRを逸失していたのか・・・」と感じるとてもリアルな数字です。
その２：開発優先度の判断指標を再定義する
Productboardでは開発優先度の判断指標を柔軟に定義できます。が、それは指標の定義を自分たちで行うことを意味します（一部標準指標を除いて）。
会社の事業戦略やプロダクトに合った開発判断の指標を定義しなければ、Productboardはただの箱になってしまいます。
という訳で、弊社請求管理ロボを開発していくにあたっての開発優先度の判断指標を改めて定義しました。
その３：社内ステークホルダーに説明する
Productboardはプロダクトマネージャーだけのツールではありません。
経営層、カスタマーサクセス、ヘルプデスク、営業、開発エンジニア、などあらゆる社内のステークホルダーに対して今後の開発ロードマップを共有するためのツールでもあります。
特に顧客からの要望に日常的に接する機会が多いカスタマーサクセス、ヘルプデスク、営業のスタッフには、自分たちが収集して報告した要望がプロダクトマネジメントの中でどのように取り扱われているかを理解してもらう必要があります。
このために、カスタマーサクセスやヘルプデスクの担当者には設計段階から意見を聞き、更にパイロット運用の開始前には主要な社内ステークホルダーにたいして導入計画を説明する場を設けました。
今後やってみたいこと
まだパイロット運用を開始したばかりの段階ですが、今後は以下のようなトピックに取り組んでいきたいと思っています。
- Productboardを社内に定着化
- 残念ながらまだまだ社内で「今後の開発予定を見たければここ！」というレベルで認知されていません・・・。主要な定例会議で共有・参照するなどして、社内での啓蒙活動を続けていきたいと思っています。
- Portalの導入
- 弊社プロダクトのユーザに開発予定を公開するためのPortalの導入もこれからです。年内早い段階では公開に漕ぎ着けられるように、企画を進めております！
- コミュニティの活用
- Productboardではツールの提供だけでなく、プロダクトマネジメントにおけるベストプラクティスや事例を共有するためのコミュニティも提供しています。セミナーも定期的に開催されているので、ここから他の企業がどのようにProductboardを活用しているか参考にしてみたいと思います。世界中のプロダクトマネージャーと1on1を繋げてくれるサービスもあったりして面白そうです！
まとめ
最後にProductboardについて、全体的な感想を。
ユーザビリティについては、UIが洗練されているので操作性が高く、サクサク動いてくれるのでとても使いやすいという印象です。
Productboardのサポートチームに何度か照会する機会があったのですが、とてもフレンドリーで対応もタイムリーだったので、サポート体制は問題なさそうです。ただし日本語対応はしていないので、全て英語になります・・・。
一方、開発優先度の指標についてはカスタマイズ性が高いので、きちんと自社のプロダクトに合った指標と設定基準を定義することが重要だと感じました。複数の指標から別指標を自動計算してくれるような機能があると尚いいなと思います。
直近、125百万ドルの資金調達にも成功したみたいなので、今後の展開が楽しみです。
We are hiring!!
絶賛仲間募集中です。
