はじめに

@yutakikuchi_です。

プロダクトマネジメントの本や資料の中に、プロダクト検証を行うためのステップ、それらを行うためのフレームワークなどは頻繁に目にしますが、それらはあくまでも理論的な部分であり、実際に遭遇するプロダクト開発の問題はまた異なる状況かと思っています。よってこのMirror投稿では実践に即した課題を取り上げ、それをどのような考えや手順で解くかを考えていくための内容を記載します。プロダクト開発をすすめる上での泥臭さがもっと世の中に伝わればと思っています。

本Mirrorへの投稿の内容の対象としてプロダクト種別は「課題解決型」の「toBプロダクト」、フェーズとしては「初期・導入期」をイメージしています。toCプロダクトには当てはまらないの？という疑問も出てきそうですが、toB・toCプロダクトは野球とサッカーぐらいにそもそも競技が違いますし、同じtoBプロダクトの中での発展期などはフェーズが違い過ぎてプロダクト事業に求められるアクションも大きく異なります。

僕自身もここでの投稿内容の意識は持っていはいましたが、実際に意識してても行動に移せず失敗した経験があるので、自身の反省としても記載しています。

「T字型のユーザーターゲット」とは**一般的な用語でもなんでもありません。**勝手に僕がプロダクトの説明の際に使っている単語になります。もしかしたらもっと良い呼び方があるかもしれませんので、呼び方は募集します(笑)。

T字型のユーザーターゲットの定義は2軸で、縦軸にユーザーの課題の深さや分かりやすいユースケースのレベル、横軸にユーザー数や業界の広さとして取ります。

Platform型・SaaS型のいずれの課題解決型toBプロダクトは事業の大きさが上の2軸の掛け算で決まります。ユーザー(お金を支払うのは顧客)の大きな課題に対して解決できるプロダクトの価値が単価として決まり、それが同じ課題をもつユーザー何人に響くか・利用してもらえるかでそのプロダクト事業の大きさがほぼ定義されます。

プロダクト開発の観点で課題の深さやユースケース事例とユーザー数のどちらも重要なのは自明ですが、どっち優先してやる？というのを特に初期・導入期ではそのプロダクトに関わるメンバー全員で認識を合わせることが求められます。意外とこの認識がチーム内の人によってバラバラに成っているケースが多いのではないでしょうか。

結論としては初期・導入期はそのプロダクトを利用したユーザー数よりも、1、2社内のユーザーでも良いのでユーザーの課題を解決した分かりやすい事例をそのプロダクトを使って実装することです。よって、「縦軸」をとにかく意識します。

もちろん、プロダクトの発展期からはプロダクトを利用してくれるユーザー数にしたがって規模の経済が働き、高利益構造が作られるべきですが、導入期・初期からいきなりユーザー数の方を意識してプロダクトの方向性を設計すると、Core機能の定義が難しく方向性がブレやすく、使い手からユースケースが見えづらくなる状況が多いです。もちろん、プロダクトとしての価値は処理の再現性がその中で生まれることにあるので、理想としてはユーザー数としつつも、導入期・初期はあえてスケールをしない戦い方が必要になります。

少ないユーザー数でもプロダクトを活用した事例として作っていく価値をまとめると

• 社内リソースを集中して事例づくりにフォーカスできる

• 仮に1社でも強力な事例が作れたとして、その類似の課題を持つほかの企業ユーザーに説明がしやすい

• 初期・導入期でもエンタープライズ型でユーザーに導入が可能にもなり、事業の安定性を説明しやすい(超重要)

特に、経営者や事業責任者レイヤーは最後の数少ないユーザーに対してもエンタープライズ型でも導入可能な要素がプロダクト内にあり、ある程度初期から数値がついてくると社内外への説明もしやすく事業継続性に安心が持てますし、(最悪)エンタープライズ型のビジネスである程度の事業規模(15人ぐらいの組織で5億ぐらいでしょうか。)までは持っていけるはずです。

分かりやすい事例を作ったあとの話ですが、プロダクトをその他のユーザーにも使って課題解決をしてほしいので、その事例を素にユーザー数を少しずつ、少しずーつ広げていく必要があり、プロダクト提供側のチームはそのためのアクションが求められます。その内容については別でMirrorに書きたいと思います。

僕自身もプロダクト開発のアドバイスを複数行う中で、プロダクト導入期の中で幅を広げようとしてものを作った結果導入が思うように進まずに、ユースケース事例づくりに方向を転換し事業やり直したものを数多く見てきた経験もあり、そのためにこの順番意識の重要性を書いてます。

縦の限られたユーザーのユースケースづくりを先にすすめるとした場合、プロジェクト型、ユースケースにフィットさせるためのインテグレーション要素が必要になる可能性があり、一般的な汎用性を持つプロダクト開発と比較すると求められるスキルが異なります。もちろん、プロジェクト型、汎用的なプロダクト型の両方を担える人材がチーム全体として保証されているのであれば、組織づくりの懸念は無視可能かと思います。

初期・導入期にユースケースづくりにフォーカスするのであれば、プロジェクト型人材であり、インテグレーション対応ができ、エンタープライズ要素でプロダクトを導入ができる人を中心として組織を作ることが望ましいです。

その他、**ユースケースを作る組織と汎用的に仕組み作りをする組織と分けて、並行してプロダクト開発をすすめることは理想ですが、これもあまりおすすめしません。**理由はシンプルで、汎用的にもの作りをする人が一番のユーザーである深い課題とユースケースを自分事として知らずに作ってしまう可能性があるので、初期は多少大げさですが、全員でユースケースにフォーカスが鉄則です。汎用的なプロダクト展開する任務を実行することは、強烈なユースケースをチームとして知ってこそできることでもあるので。

最後まで読んでいただき、ありがとうございました。今後も上のように理論的な話以外に実践内容を書いていきたいと思います。ご意見や質問は全てTwitterのDMで受け付けております。よろしくお願いいたします。@yutakikuchi_

はじめに

@yutakikuchi_です。

プロダクトマネジメントの本や資料の中に、プロダクト検証を行うためのステップ、それらを行うためのフレームワークなどは頻繁に目にしますが、それらはあくまでも理論的な部分であり、実際に遭遇するプロダクト開発の問題はまた異なる状況かと思っています。よってこのMirror投稿では実践に即した課題を取り上げ、それをどのような考えや手順で解くかを考えていくための内容を記載します。プロダクト開発をすすめる上での泥臭さがもっと世の中に伝わればと思っています。

本Mirrorへの投稿の内容の対象としてプロダクト種別は「課題解決型」の「toBプロダクト」、フェーズとしては「初期・導入期」をイメージしています。toCプロダクトには当てはまらないの？という疑問も出てきそうですが、toB・toCプロダクトは野球とサッカーぐらいにそもそも競技が違いますし、同じtoBプロダクトの中での発展期などはフェーズが違い過ぎてプロダクト事業に求められるアクションも大きく異なります。

僕自身もここでの投稿内容の意識は持っていはいましたが、実際に意識してても行動に移せず失敗した経験があるので、自身の反省としても記載しています。

「T字型のユーザーターゲット」とは**一般的な用語でもなんでもありません。**勝手に僕がプロダクトの説明の際に使っている単語になります。もしかしたらもっと良い呼び方があるかもしれませんので、呼び方は募集します(笑)。

T字型のユーザーターゲットの定義は2軸で、縦軸にユーザーの課題の深さや分かりやすいユースケースのレベル、横軸にユーザー数や業界の広さとして取ります。

Platform型・SaaS型のいずれの課題解決型toBプロダクトは事業の大きさが上の2軸の掛け算で決まります。ユーザー(お金を支払うのは顧客)の大きな課題に対して解決できるプロダクトの価値が単価として決まり、それが同じ課題をもつユーザー何人に響くか・利用してもらえるかでそのプロダクト事業の大きさがほぼ定義されます。

プロダクト開発の観点で課題の深さやユースケース事例とユーザー数のどちらも重要なのは自明ですが、どっち優先してやる？というのを特に初期・導入期ではそのプロダクトに関わるメンバー全員で認識を合わせることが求められます。意外とこの認識がチーム内の人によってバラバラに成っているケースが多いのではないでしょうか。

結論としては初期・導入期はそのプロダクトを利用したユーザー数よりも、1、2社内のユーザーでも良いのでユーザーの課題を解決した分かりやすい事例をそのプロダクトを使って実装することです。よって、「縦軸」をとにかく意識します。

もちろん、プロダクトの発展期からはプロダクトを利用してくれるユーザー数にしたがって規模の経済が働き、高利益構造が作られるべきですが、導入期・初期からいきなりユーザー数の方を意識してプロダクトの方向性を設計すると、Core機能の定義が難しく方向性がブレやすく、使い手からユースケースが見えづらくなる状況が多いです。もちろん、プロダクトとしての価値は処理の再現性がその中で生まれることにあるので、理想としてはユーザー数としつつも、導入期・初期はあえてスケールをしない戦い方が必要になります。

少ないユーザー数でもプロダクトを活用した事例として作っていく価値をまとめると

• 社内リソースを集中して事例づくりにフォーカスできる

• 仮に1社でも強力な事例が作れたとして、その類似の課題を持つほかの企業ユーザーに説明がしやすい

• 初期・導入期でもエンタープライズ型でユーザーに導入が可能にもなり、事業の安定性を説明しやすい(超重要)

特に、経営者や事業責任者レイヤーは最後の数少ないユーザーに対してもエンタープライズ型でも導入可能な要素がプロダクト内にあり、ある程度初期から数値がついてくると社内外への説明もしやすく事業継続性に安心が持てますし、(最悪)エンタープライズ型のビジネスである程度の事業規模(15人ぐらいの組織で5億ぐらいでしょうか。)までは持っていけるはずです。

分かりやすい事例を作ったあとの話ですが、プロダクトをその他のユーザーにも使って課題解決をしてほしいので、その事例を素にユーザー数を少しずつ、少しずーつ広げていく必要があり、プロダクト提供側のチームはそのためのアクションが求められます。その内容については別でMirrorに書きたいと思います。

僕自身もプロダクト開発のアドバイスを複数行う中で、プロダクト導入期の中で幅を広げようとしてものを作った結果導入が思うように進まずに、ユースケース事例づくりに方向を転換し事業やり直したものを数多く見てきた経験もあり、そのためにこの順番意識の重要性を書いてます。

縦の限られたユーザーのユースケースづくりを先にすすめるとした場合、プロジェクト型、ユースケースにフィットさせるためのインテグレーション要素が必要になる可能性があり、一般的な汎用性を持つプロダクト開発と比較すると求められるスキルが異なります。もちろん、プロジェクト型、汎用的なプロダクト型の両方を担える人材がチーム全体として保証されているのであれば、組織づくりの懸念は無視可能かと思います。

初期・導入期にユースケースづくりにフォーカスするのであれば、プロジェクト型人材であり、インテグレーション対応ができ、エンタープライズ要素でプロダクトを導入ができる人を中心として組織を作ることが望ましいです。

その他、**ユースケースを作る組織と汎用的に仕組み作りをする組織と分けて、並行してプロダクト開発をすすめることは理想ですが、これもあまりおすすめしません。**理由はシンプルで、汎用的にもの作りをする人が一番のユーザーである深い課題とユースケースを自分事として知らずに作ってしまう可能性があるので、初期は多少大げさですが、全員でユースケースにフォーカスが鉄則です。汎用的なプロダクト展開する任務を実行することは、強烈なユースケースをチームとして知ってこそできることでもあるので。

最後まで読んでいただき、ありがとうございました。今後も上のように理論的な話以外に実践内容を書いていきたいと思います。ご意見や質問は全てTwitterのDMで受け付けております。よろしくお願いいたします。@yutakikuchi_