特にtoB向けのプロダクトのユーザーを語るときには「B」という1つのくくりでは表現しきれないケースも多いのではないかと思っています。

今回は「『B』のなかにどんなユーザー属性が存在するのかを把握することが大切ではないですか？」というお話です。

toBのユーザー = Customer ＋ End-User

↑これは書籍「プロダクトマネジメントのすべて」のなかの一文ですが、このnote記事で言いたいことを端的に表現しています。

「toBプロダクトのユーザー」と表現する「B」の中身を深掘りすると、

• 顧客（この記事では「Customer」と呼びます）

• ユーザー（この記事では「End-User」と呼びます）

にまずは大きく分類されることを把握しておくことが大切です。

• Customer：
  決裁者、上長、プロダクト導入を検討する人

• End-User：
  実際にプロダクトを利用する人

そして「Customer」と「End-User」では、プロダクトに期待することも違えば、思っていること（インサイト、モチベーション…）も様々な点で違うことを理解しておく必要があります。

「Customer」と「End-User」の期待していること・思っていることの違い

プロダクトの特性によっても異なるので一概には言えませんが「Customer」と「End-User」がそれぞれでプロダクトに期待していること・思っていることは、結構違います。

• Customer：
  導入で何らかの成果を出したい、リスクを回避したい→能動的・前のめり

• End-User：
  手間なく進めたい、ぶっちゃけめんどくさい→受動的・なんか言われたからこのプロダクト使ってる

くらい違うこともありえます。

ちなみに、Customer側で期待している“何らかのROI”というのは「月額利用料金など金額的コストの削減」や「生産性向上」がわかりやすいものになります。やはりtoBプロダクトの導入というのは、かなりのコストがかかるケースが多いですから、費用対効果がわかりやすく出ることを望むと思います。

上述のないようだと抽象的なので、わかりやすくするために期待していこと・思っていることの違いを、いくつかのシナリオをもって見てみたいと思います（少し私の憶測・バイアスがかかっているかも…）。

勤怠管理システムの場合

• Customer：
  正確な勤務時間を毎日入力してほしい／残業過多の傾向が発生したらすぐに検知したい／迅速に確定させ給与額などを確定させたい／今利用している支払い管理システムと連携したい

• End-User：
  毎日入力しろと言われるから手間がなく対応したい／部下の勤怠管理などついつい忘れるので異常があれば知らせてほしい

経費管理システムの場合

• Customer：
  申請内容が正しいか確認したい／二重申請などを検知したい／今利用している決裁管理システムと連携したい

• End-User：
  領収書の写真を撮るのも入力するのも面倒／交通費など申請が面倒なので交通系ICカードなどと連携してほしい

デザインツールの場合

• Customer：
  （必要以上にたくさんのツールと契約することはコストなので）高機能なツールがいい／（将来的なツールの乗り換えはコストになるので）長く使えるツールを選びたい／権限管理を正しく行いたい

• End-User：
  いろいろなツールを使ってみたい／チュートリアル記事やアドオンが揃っているツールがいい

End-Userの立場として、勤怠管理や経費管理の入力が「めんどうだなぁ」と思ったことがある方も多いのではないしょうか。一方で、もしあなたがCustomerの立場になったとするならば、当然「正確さ」や「迅速さ」をEnd-Userに、そしてプロダクトに求めると思います。

立場が変われば、当然の期待していることも思っていることも違ってくるわけです。

「Customer」と「End-User」ではプロダクトの使い方も違う

違うことは「期待」「思い」だけではありません。「Customer」と「End-User」では、プロダクトの使い方も違うケースがあります。使い方の違いですと、ざっくりと以下の3パターンに分かれるのではないでしょうか。

1. Customerが、プロダクトを利用しない

2. Customerが、End-Userと同じようにプロダクトを利用する

3. Customerが、End-Userと異なる権限でプロダクトの利用する

この3パターンを、前項と同じくいくつかのシナリオで見ていきます。

勤怠管理システムの場合

1. Customerが役員なので、プロダクト導入の決済はするが、自ら勤怠管理システムは使わない（アカウントはあるが、秘書などに一任している）

2. Customer（＝管理部マネージャー）が、自らの勤怠を登録する

3. Customer（＝管理部マネージャー）が、部下の勤怠の承認をする

経費管理システムの場合

1. Customerが役員なので、プロダクト導入の決済はするが、自ら経費管理システムは使わない（アカウントはあるが、秘書などに一任している）

2. Customer（＝経理部マネージャー）が、自らの経費申請をする

3. Customer（＝経理部マネージャー）が、自部署・他部署の経費申請をチェックする

デザインツールの場合

1. Customer（＝デザインチームのマネージャー）が非デザイナーなので、そもそもデザインツールを使わない（使えない）

2. Customer（＝デザインチームのマネージャー）がプレイングマネージャーなので、End-Userと同じようにデザインツールを使う

3. Customer（＝デザインチームのマネージャー）が、権限管理などの上位機能を利用する

多くのCustomerは、End-Userと同じ機能も使いながら、管理者機能も使うという「ケース2+ケース3」になると思います。しかし「ケース1」のようにプロダクトの導入・部の戦略を決めたりするが、導入後はプロダクトを一切触らないというケースもありえるのです。

プロダクト提供側は「Customer」だけではなく、「End-User」のことも考える

プロダクト提供側の営業やカスタマーサクセスが、オンボーディングや定例MTGで顔を合わせているのは、多くの場合「Customer」になります。なので「Customerの声」＝「お客様の声」となりがちです。

しかし上述のように「Customer」と「End-User」ではプロダクトに期待していること・思っていることも違えば、プロダクトの使い方も違うのことを理解しなければいけません。

そして「Customer」が「End-User」のことを正しく把握しているか？というと、必ずしもYESとは言い切れないでしょう。もちろんしっかり把握していることもありますが、知った気になっている・間違った捉え方をしていることも十分にありえます。

なのでプロダクト提供側としては、「ユーザー」という大きな属性でまとめるのではなく、「Customer」と「End-User」などある程度小さな属性でユーザーのことを知ることが大事です。

「Customer」が言う「End-User」像を鵜呑みにするだけではなく、「End-User」のことをしっかり調査・インタビューを実施し、双方のことをしっかり把握することで、「ユーザー」の正しい理解につながります。

「End-User」の課題解決も、プロダクト導入の成果のひとつになる

Customerは、プロダクトを導入するにあたって「このプロダクトを導入すると、○○という効果があります！」と添えて自らの上長に稟議をあげたり、上長が渋っている場合は説得をします。なぜそこまでするかというと、プロダクトの導入で成果を上げたいのです。

成果というのは「月額利用料金など金額的コストの削減」や「生産性・満足度向上」が代表的なものになるでしょうか。やはりtoBプロダクトの導入というのは、かなりのコストがかかるケースが多いですから、費用対効果がわかりやすく出ることを望むと思います。

そして「生産性・満足度向上」というのは、End-Userの生産性・満足度向上も重要な指標になってきます。プロダクト導入でEnd-Userから
「作業がやりやすくなった」
「効率が上がった」
というフィードバックを受ければ、Customerは当然嬉しいですし、それはプロダクト導入の成果になっています。

なのでプロダクト提供側にとって、「Customer」と「End-User」双方の正しいユーザー理解を進め、双方の課題を解決していくことが、プロダクトにおける価値提供につながっていくのではないでしょうか。