HRBrain Advent Calendar 2022 カレンダー2の18日目の記事です。
はじめに
こんにちは。
株式会社HRBrainで労務サービスのプロダクトマネージャーをしています @Moou0820 です。
中途入社して2か月が経ち、長い間toCのサービス開発に携わっていた私が初めてtoBサービスの開発に参加し、同じサービス開発でも根本的に考え方が違うな..と感じましたのでその事を書かせて頂ければと思います。
何が違うのか
まずtoCとtoB開発の違いですが、toCのサービスではユーザーの属性や利用タイミング等の仮説を立てた上で、定量的なログを計測し課題箇所の改修を行います。そのPDCAを回す事により、仮説を検証しそれを立証していきます。
逆にtoBサービスの場合、ユーザーの課題が既に有りそれを1つ1つ解決することでユーザーニーズに応えていくというプロセスになります。
入社して1か月が経った頃になんとなく今までのやり方では上手く進まない事に気づき、これまでのtoCのPdMスキルやマインドを一度捨て改めて考えなおす必要があると感じました。
toB開発の難しさ
ユーザーの業務理解が必要
課題が明確であってもその業務に携わってきたわけではありませんので、実際に使用する状況を理解する必要があります。
誰が、いつ、何の作業を、何のツールを使って作業しているのかといった業務フロー等の前提知識はもちろんのこと、その業務自体のドメイン知識も必要になります。
数字で判断出来ない
その機能が存在するという事がセールスに響く場合がありますので、定量の数字だけを見て削除等の判断をすることが出来ません。
ヒアリング出来る母数が少ない
toCサービスとは違い、多くの方からフィードバックやヒアリングが出来るわけではありません。課題感や要望優先度にかなり差異が出てしまう事もあります。
これらの問題を開発チームでどう解決していくのかが私の悩みでもありました。
大切なのは周りと連携すること
toB開発に関して全てをプロダクト開発だけで解決出来ることはできません。
入社当初「ビジネスサイドと連携をしながら進めて下さい」と言うアドバイスを頂いていました。
ただ、今まで開発チームだけで課題から立証まで進めていた私には全く無い思考だったのでいまいち「連携」がどういうことかわかっておらず行動に移すまでかなり時間がかかってしまった気がします。
課題によってはセールスやカスタマーサクセスといったビジネス組織に相談し、一緒に動く事が必要で、その中でプロダクトとしての優先度や落とし所を決定し開発に着手していく。
この考えに気づけた事で少し目の前が開け、モヤっとしていた問題の糸口とtoB脳への一歩を踏み出せた気がします。
最後に
toCの新しい領域を切り開いていく開発とは違い、toBサービスの開発は決して派手なものでは無いと思います。
ですが、ユーザーの課題を確実に解決しそれを使って頂ける環境が必ずあり、リリースした機能に関してのフィードバックがすぐにいただける。
この環境はありがたく、新しい面白みを感じています。
最後まで読んで頂きありがとうございました。
素敵なクリスマスをお過ごしください ☆＊*
HRBrainでは引き続き仲間を募集しております。詳細は下記からご確認ください。
https://www.hrbrain.co.jp/recruit