BtoB SaaSにおけるプロダクト開発の勘所

ここ最近になって BtoB SaaS の立ち上がりが目覚ましくなってきており、様々なドメインでプロダクトが誕生しています。

しかしながらその一方で BtoB SaaS のプロダクト開発ができる、あるいは経験があるデザイナーや PdM の不足が顕著になってきています。これは本業である HERP (採用管理プラットフォームの BtoB SaaS です)で採用活動をしている私自身が感じていることでもあり、副業で BtoB SaaS プロダクトの立ち上げの相談を数多く受けることから感じることです。

デザイナー自体の人口としてはこの数年でだいぶ増えてきた印象ではありますが、BtoB SaaS という領域は正直まだまだニッチで、なおかつスキルがある一定以上要求されるため「不足している」という認識をしています。言ってしまえば単純に BtoB SaaS プロダクトの開発が難しいということです。

今回は BtoB SaaS のプロダクト開発のどこが難しいかについてとそれに対する解決策、そして楽しさをまとめてみました。いろいろなデザイナーやPdMが BtoB SaaS 領域に興味を持ってもらえればうれしいです。

BtoB SaaS のプロダクト開発が難しい理由

そのドメインのエキスパートであることが稀なのでターゲットのインサイトを得にくい(想像しにくい)

BtoC 領域のプロダクトは得てして自身がターゲットになりうる傾向にあります。しかしながら BtoB 領域の場合はほとんど自身がコアなターゲットになりません。

例えば、私がデザイナーとして開発している HERP ATS は採用管理に関するプロダクトです。しかしながら、私は実際に企業で採用担当者として数年働いてその後デザイナーに転向した、というような経歴ではないため、採用という領域に関してのエキスパートではありません。

即ち、プロダクトを開発していくにあたりターゲットとなる「採用担当者」のインサイトを得にくいのです。ターゲットがどういう成果を求めていて、それに対してどんな打ち手が存在し、どれを選び取るべきか想像しにくいのです。ここが BtoB SaaS のプロダクト開発の高いハードルのひとつとなります。

そのドメインに関する知識にアクセスしにくい

どんな業務フローであるのか、そのときにどんなツールを使っており、どんな成果と指標を追っており、どんなことに困っているのか。それを把握することが単純に難しいです。

例えば、Googleで採用担当者の仕事内容を検索すれば表層的で浅いレイヤーの業務フローは知ることができますが、そのときに何を思っているかや具体的なオペレーションで何が起こっているか等はわかりません。

そのドメインに関する本当に価値ある情報や知識は、ドメインエキスパートに対してインタビューをする、あるいは自身で実際に業務を行ってみることではじめて手に入れることができます。ドメインエキスパートを捕まえてインタビューすることもなかなか難しいですし、また自身で実際に業務を行ってみることもなかなかその環境を用意できません。つまり、かなりコストが高いです。

また、競合が存在する場合はどういうプロダクトであるのか調査したくなりますが、BtoB 領域のツールはなかなか気軽に試すことができないのでそこも情報としてアクセスしにくいです。

要件が膨らみがち

業務を遂行するために必要最低限な機能がそもそも多いため、往々にして要件が膨らみがちです。その膨らみがちな要件を破綻せずに、スケーラビリティも確保しつつきれいに定義するということが本当に難しいです。

業務フローが異なる場合が多いため開発スコープを決めにくい

複数のドメインエキスパートに対してインタビューをしたことある人なら経験があるかもしれませんが、人によって業務フローが異なる場合が多いです。

例えば「分析」という業務に対して、AさんとBさんとでは追っている指標が微妙に異なればレポーティングの方法も異なり、一体どこにフォーカスすればいいのだろう?ということがよく起こります。

特にスタートアップではリソースは限られているのでその全てを盛り込もうなんてことはなかなかできません。そこの意思決定に関しても難しさのひとつです。

カスタマーサクセスが変数として入る

プロダクトや機能は作って終わりではありません。そのプロダクトあるいは機能を作ってユーザーに使ってもらい、ユーザーが求める成果を得てはじめて意味があります。

その際に切っても切り離せないのはカスタマーサクセスであり、プロダクトの体験設計に密に関わってきます。カスタマーサクセスチームによる丁寧なユーザー支援を前提とした運用を想定するなら、かなり高いリテラシーを有するターゲット向けに体験設計してもいいですし、そこを切り捨てるならその分の仕組みをプロダクトに内包する必要があります。

SaaS ではチャーンレート(解約率)を重要指標として追いますが、チャーンを防いで使い続けてもらう仕組みを考えながらプロダクトを作る必要があるのです。

ではどうすればいいのか

ドメインエキスパートを確保する

ドメインエキスパートを確保できるかどうかでインプットの量と質、打ち手の精度の高さが決まります。何かしらの方法でつながりを作ったり、気軽にいろいろ聞ける環境を作っておくことが大切です。

ちなみに HERP 社ではユーザー様と Slack の Shared Channel を作成したり User Community を作ったりしていつでもヒアリングしたりフィードバックをいただけるような仕組みを作っています。

業務フローのパターンを徹底的に洗い出す

難しさのセクションでも述べましたが人によって(企業によって)業務フローが異なる場合があります。業務フローの全てのパターンをできる限り洗い出しましょう。

ここの精度によってどれだけユーザーに刺さるかとその後のスケーラビリティが決まるなという肌感覚があります。また、データベース設計にも大きく関わってくる部分であるため、プロダクト開発でもっとも大切な部分だと思います(ここの精度が甘くて、間違ったあるいは負債になりうるエンティティの定義をする事態になったりします...)。

業務フロー同士の関係性を整理する

単一の業務フローを考えるだけでなく、複数の業務フロー同士の関係性を整理することも大切です。体験として、データとして、それぞれどこでタッチポイントを持っており、どう連携してあげれば破綻なく同時に存在できるのか考える必要があります。これが本当に難しいですが...。

そのドメイン特有の指標や具体的な情報がユーザーの成果にどう結びつくか整理する

ユーザーが求めている成果とOOUIの概念で言うところのオブジェクトがどう結びつくのか整理するとUIデザインフェーズで自ずと答えが見えるようになります。

思考停止してこういう業務フローにはこういう体験とUIだな、と決め打ちで作っていくと負債となります。

ドメイン知識について社内Wikiなどでまとめる

そのドメインで経験を積めば自ずとドメイン知識は定着しますが、全ての人が全てのドメイン知識を持てるわけではないので情報をオープンな場にまとめておくと役に立ちます。

特に新しく入社してきた社員やインターン・業務委託がキャッチアップしてすぐにのびのび働けるようにするための仕組みとして大切です。

BtoB SaaS のプロダクト開発の楽しさ

BtoB SaaS のプロダクト開発に関して難しい!ということしか言ってない気がしますが、もちろん楽しい部分もあります。

複雑な業務フローの整理と要件定義がパズルみたいで楽しい

複雑であることが難しさでもあり楽しさであります。個人的にはパズルや謎解き感覚でプロダクト開発をしています。

謎解きのヒントであるユーザーのインサイトを取りに行くと、取りに行った分だけ解像度高く正解が見えてきて、その正解をユーザーにぶつけて答え合わせしたときに反応が得られることがとても面白いです。BtoB SaaS ではユーザーの実際のフィードバックを密度高く得られることも醍醐味ですね。

UIデザインやUXの水準がまだまだ低く、わかりやすく価値を提供できる

toC 領域(特にモバイルアプリ)はこの数年でUIデザインやUXの求められる水準が非常に高くなり成熟してきたと思うのですが、toB 領域はまだまだです。既存のプロダクトがレガシー(というか不便)であることがザラにあります。

業務フローにフィットした体験で、ユーザーにやさしいUIデザインという当たり前なことだけでまだまだわかりやすく価値を提供できる環境であることがやりがいとなります。

そのドメインに与えるインパクトが大きい

ユーザーが真に求めるプロダクトを再定義して生み出すことができればそのドメイン(業界)に与えるインパクトがかなり大きいです。例えば、CRMツールの Salesforce は CRM 領域で世界的に主流となっていますが、これは他に取って代わるプロダクトがなかなか現れないくらいインパクト(価値)があるからです(もちろんプロダクトのセールスやマーケティング等の他の要素も影響してますが)。

人々の生活を大きく変える!というようなことはできないかもしれませんが、ビジネスの世界で金銭的にもカルチャー的にも大きくインパクトを与えられるのはわくわくすることだなと感じます。

最後に

toC 領域はキラキラしてて楽しそうで、一方 toB 領域は地味でこつこつやっていくだけ、というようなイメージですが、実際は非常にやりがいがあるのでもっと BtoB SaaS のプロダクト開発に関わるデザイナーや PdM が増えたらいいなと思います。

HERP で一緒にプロダクト開発をしてくれるデザイナーやエンジニアを募集してますし、

あるいは副業で BtoB SaaS プロダクト開発のお手伝いをしたりしてるので、どちらにせよお声がけしていただければなと思います。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

サポートは今後のインプット/アウトプットのために使ってまた皆さんに還元します!

うれしいです!
29

オオカワラ

UI/UX Designer at HERP, Inc.

#スタートアップ 記事まとめ

スタートアップが手がけたnoteが集まるマガジンです。スタートアップが読むべき、知るべきnoteも選んでいきます。
1つ のマガジンに含まれています
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。