この記事はLayerXアドベントカレンダーの企画の一部です。
ここ1年ほどは所属しているLayerXにて、LayerXインボイスという、請求書処理プロダクトの立ち上げ開発を行ってました。特に最近はプロダクトマネージャー(PdM)業務を行っており、事業部内で上半期MVPをもらいました。
正式なプロダクトマネージャーの仕事は試行錯誤しながらでしたが、得た知見や気をつけていることを記しておきます。
1/ 本業のLayerXでは1年強ほどブロックチェーンはお休みしてB2BSaaSの開発とプロダクトマネージャー(PdM)をして、DX事業部(SaaS事業)内で上半期MVPをもらいました。
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
まだ全然成果を上げられていないと思うものの、この機会にPdMとして意識していること、意識したいと思っていることを言語化してみます
ユーザーの業務理解がまず最初の一歩
2/ まずユーザーの業務を理解する。請求書の支払業務といっても、受け取りや支払など細かい点では各社様々なフローがあり、利用会計ソフトや運用方法によって細部の業務は異なる。
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
各社最適化したオペレーションでもあるので、業務に合わせられるソフトウェアのケイパビリティを持てるように努める
今のプロダクトの立ち位置を見極める
B2BSaaSではマーケットがいくつもあり、1つの市場で売れるものを作れても、次々と別の市場にアプローチしていくことが必要です。
3/ 今のプロダクトの立ち位置を見極める。B2BSaaSは複数マーケットが対象になる。規模の軸や業界の軸でマーケットを切る。自分たちは今どの立ち位置にいるのか、というところが意識しないと迷子になる。
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
どこにいて、どこに向かうのかを理解する基本の大事さ。https://t.co/9RWYr88Omj
参照している記事ではPMFを他市場に広げることを「水平展開のPMF」、「垂直展開のPMF」と呼びました。
意識すべきはアウトカム
「どれだけの機能を作ったか」ではなく、「どれだけユーザーに役立ったか」が成果だとすべきという話。
4/ ロードマップにはアウトカムを意識する。機能数をベロシティとして見るのではなく、アウトカム（成果）をベロシティとして見るべき。（他社PdMに推薦してもらった本より）
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
B2BSaaSにおいては、対応できた業務フローがアウトカムとして大きな意味を持つのではないかと思う。
https://amzn/to/3l4Fsah
じっくり読み込んだ「プロダクトマネジメントのすべて」という本では、この概念を「アウトカム」と呼んでいました。B2BSaaSでは、「ユーザーの業務フローをカバーできたか」がアウトカムだと思っています。
内部・外部でのコミュニケーション=異なる情報を集めることが大事
プロダクト開発のための「コミュニケーション」は人間関係を円滑にすることを第一目的ではなく（それはそれで大事ですが）、第一目的は「異なる情報を集めて意思決定に役立てること」です。
5/ チーム内で異質な情報を持っている人たちとそれぞれコミュニケーションを取る。B2BSaaSにいる新規ユーザーに提案をしにいくセールス、既存ユーザーの業務に接するカスタマーサクセス(CS)。そして開発チーム。これらはそれぞれ持っている情報が違う。
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
それぞれ話すことで多面的に情報を把握する。
6/ ユーザーのフィードバックは直接聞けるほど良い。全てのユーザーの声を聞きに行けるわけではないが、それでも直接ユーザーと対話することが大事。
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
特に、新しいマーケットのユーザーについては自分が知らない情報をたくさん持っているのでなるべく聞きにいくべき。
手を動かしてから見える景色もある
不確実性は、適切な情報が増えるほど低くできます。即ち、絵空事ではなく、途中までものを作ると見える景色は異なるので、そういうタイミングで振り返ってみましょう。
7/ 作ることで情報量が増えることを理解する。途中まで作ると、やはりこの機能は違うなとかこうした方がいいという再考余地ができる。
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
これはきっちり最初に設計してもわからない種別のもので、不確実性が高いものの場合、途中まで作ってみて再考してみる気持ちを大事にする。
体験も新機能。要件定義書に書かれる類のものではない
どんなによいものを作っても、体験が疎かではユーザーに使われません。
8/ 体験も新機能の一部。B2Bの開発ばかりやってきたキャリアだからかB2C出身と比べて僕はこの意識が低かった。機能があっても最初の体験が悪いと業務に乗らない。CSへの問い合わせも増える。
— 花村 直親 Nao Hanamura (@naomasabit) October 3, 2021
デザイナーや既存ユーザーに接しているCSを巻き込んで体験に違和感がないかフィードバックをもらうべき
作る段階、作った後の段階でデザイナーや既存ユーザーと接するカスタマーサクセスチームに聞いてみると珠玉のフィードバックを得られます。
「体験」というのは論理的に、左脳が発達した人種だけで考えると疎かになりがちです。機能だけでなく、「体験の品質保証」を忘れないようにしましょう。
さいごに
meetyを始めました。30分程度オンラインでお話しするサービスです。
会社のカジュアル面談という体ですが、プロダクトマネジメントのことでも、開発のことでも、ブロックチェーン、NFT、暗号通貨、キャリアのことでもなんでも話します。いつまで開いているかはわからないですが、興味あればお気軽に申し込んでみてください
こちらは私のTwitterアカウントです。
