見出し画像

AIを活用したEnterprise向けSaaSの 『ほどよしMVP』をどう作るか

こんにちは!ストックマークでPMM(プロダクトマーケティングマネージャー)を担当している田中(@t_kazuo1984)です。
(本記事はストックマークアドベントカレンダー 19日目の記事です)


はじめに:本noteでお伝えしたいこと

本noteでは昨年から担当している『Astrategy』のMVPについて、これまでの学びをまとめています。
PMM/PdMの方はもちろんのこと、コンサルタントからPMM/PdMを目指そうと思っている方の少しでも参考になれば幸いです。

【結論】
Minimum=最低限って難しい、という話です。


自己紹介

10年ほど、事業戦略や新規事業に関するコンサルティングをする中で、AIによる経営意思決定が可能になるのではと思い、前職では特許・論文の自然言語処理を、現職ではニュースの自然言語処理を武器にしたプロダクトづくりをしております。やりたいことは、転職時にnoteを書いているので、お時間があればご笑覧下さい。

ストックマークのミッションとビジョンは下記のとおりです。

Mission:
 価値創造の仕組みを再発明し、人類を前進させる

Vision:
 AIとヒトのポテンシャルを最大化し、
 顧客価値経営を実現するプラットフォームを提供する

上記のMission、Visionを実現するために、2プロダクトのPMMを担当しています。昨年は、ニュースからビジネスチャンスを発見する『Astrategy』というプロダクトのPMMを担当し、この11月から組織的な情報収集・共有を支援する『Anews』のPMMも担当しています。


MVPとは

MVPとは、Minimum Viable Productの略で、日本語にすると「最小実行可能製品」となります。
要するに、『狙った課題を解決することで、ユーザーが感動するかを判断できる最小限の製品(のように見えるもの)』と解釈しています。
MVPがなぜ必要かと言えば、すべてはこの馬田さんの資料、
さらに言えばこの1枚のスライドに集約されると思います。
解くべき課題は本当にそれで良いのか、それを知るための手段です。

そして、MVPが語られる時によく見る、車輪から作るのではなく、移動価値を検証するために、スクーターを提供するところから始めなさい、という図も端的にその意味を表していると思います。
※後ほど触れますが、図の2段目までを記載したものをよく見かけますが、あれは完全に罠だと思います。完全に勘違いしてました。

プロダクトづくりにおけるMVPの知識が豊富に得られるのに、なぜ今MVPの話を書いているかと言うと、次の3つのしくじりを経験し、これからMVPを作る時は、この学びの上にプロダクトづくりをやろうと決意したからです。

※MVPと記載していますが、プロダクト全体というよりも、プロダクトの価値を強化するための個別機能の価値検証の色合いが強い点はご了承下さい。


3つのしくじり先生

山のようなしくじりがありますが、
この3つのしくじりから得た学びが深かったです。

1.盛りだくさん

最初のしくじりは、何をMVPとして検証しているのかが曖昧、または検証単位が大き過ぎるMVPを作ってしまうというしくじりです。
今思えば当たり前なのですが、ペルソナやジャーニーの解像度が低いとツボ(お金を払ってくれる価値)が見えないorありとあらゆるものがツボに見える病に感染します。
コンサル時代の経験から、
・『新規事業を考えるための事業環境把握』は確かに課題である。
・事業環境を把握するためには、PEST→5Fs→3C→SWOTのストーリーが必要である。
・これらを分析するためには、XXX視点での分析が必要である。

といった仮説に基づき、これらを1つのジョブとして検証しようと考えました。

しかし、「世界平和」とまではいかないものの、「事業環境把握」もかなり大きな単位であり、ユーザーが感動したかを検証するには不適格な単位でした。そこで、以下2点を明らかにすることを優先しました。

コンサルティングで解決していた事業環境把握の中で
「どの価値が最も求められているのか」
②「どの水準まで解決できれば価値を受け取って貰えるか」
という2点です。

この見極めこそがPMMの責任であり、それが不十分な中で、MVPの範囲をさらに拡大したり、解決精度を上げようとしたりしたのは失策でした。
数多くのヒアリングをもとに、ペルソナとジャーニーをメンバーと共に検証し、どの単位で価値が生まれるのかを徹底的に議論する、これに尽きます。

2.UI品質の軽視

2つ目のしくじりは、ユーザーに価値を検証して貰うためにも最低限のUI品質が必要でそれを軽視してしまったというものです。これは大きく分けると2つのしくじりを含んでいます。

①並列的なMVPの提供
BIツールにおける『思考の流れ』は欠かせない要素です。
ペルソナを絞らない中で、自由に使って貰うことを想定すると、思考の流れをガイド(強制)するUIは敬遠され、どんな思考の流れでも使いやすい、すなわちすべての機能が並列に存在するUIにしたくなります。
しかし、それがユーザーを混乱させ、本来検証したかった価値に届く前に脱落させてしまうという失敗を繰り返しました。
ある意味、「盛りだくさんMVP」の負の遺産を引きずったまま、そこにメスを入れずに「課題解決戦線」を拡大させてしまいました。複数のMVPを走らせ、MVPにファンが付くと、MVPを卒業させて完成品を作るべきところを、さらに大きな課題を解決するためのMVPを作ってしまうという失敗です。
結果、価値がぼやけてしまい、チャーンに悩まされるという絶望を味わいました。検証した価値を完成品として提供する、これをしないならMVPを作る意味すらありません。安易に戦線を拡大して逃げずに、一点突破の価値を明確にし続ける。これもPMMの重要な責任だと痛感しています。

②ユーザビリティの変動性(再教育コスト)
ユーザーに届ける価値は同じであっても、価値を得るためのユーザーの行動が変わってしまっては検証した価値も変わってしまうというしくじりです。以下の図にあるように、移動に価値があるかを検証するのであれば、スクーターでも、バイクでも、自動車でも変わりはありません。しかし、ユーザーが「風を切って走る移動価値」を認めていたのに、車の中に入って移動することになると検証していた移動価値の一部が変化します。さらに、その移動価値のMVPを提供する時間が長ければ長いほど、完成品の再教育コストが跳ね上がります。
特に、大勢のユーザーが関与し、それぞれの関係者の意図が交錯するEnterpriseにおいては、最初から円形のハンドルで車体の中で操作する移動体を提供していないと、本来の移動価値は同じでも、改めて全体の価値を複数人で検証することになってしまいます。
少なくてもユーザーから見た時に、得られるアウトカムと得るために必要な操作はMVPの段階から見た目や文言も完成形と近いUIにしておくことが重要と感じています。ただ、この完成形と近いUIという呪縛は開発速度を左右するため、ユーザーの行動・感情を自らに降臨させて考えつつ、一部のユーザーや社内メンバーにユーザビリティテストに協力して頂き、最低限になるように注意しております。

出所:Framework to build an MVP (Minimum Viable Product)

3.手作業の限界

3つ目のしくじりは、手作業コンシェルジュ型MVPでは追いつかないというしくじり?です。

我々のプロダクトは数万を超えるメディアから、自然言語処理AIを活用して、必要な情報を抽出し、ビジネスチャンスとなる課題や他社の先行事例を抽出する価値を既に届けています。

そこから更なるMVPを作ろうとすると、蓄積しているデータを別の確度から処理する必要があるのですが、正直人間の限界を迎えつつあります。
これはもはやテックスタートアップの永遠の課題と言えるかも知れませんが、従来は人が解決していたことをテクノロジーの力で、高度に高速に解決することがテックスタートアップの存在意義です。
モックアップで、買いたいと言って頂いても、実データから得られる示唆が有用ではないと正式契約にはなりません。しかし、実データを作ることが人力では難しい領域に我々は挑戦しています。技術進化と共に、検証できる価値も更に上がるため、素晴らしいR&Dメンバーに協力して貰いながら、技術を実装したMVPで検証するというのはこれからのスタンダードになるかもしれません。

とはいえ、CS(カスタマーサクセス)を通じて、プロダクトを作らないで検証できることもまだまだあるので、ユーザーの価値をあらゆる方法で追求していきます。


まとめ

「ほどよし」=「何が最低限なのか」を探り続けた1年間でした。

  • 市場を顕在化させる最低限のメッセージは何か

  • 最小単位のジョブとしてどこまでが最低限の範囲なのか

  • 感動する最低限の水準はどこか

今改めて振り返ると、我々の場合、3つの検証を同時並行的にやっていたと改めて思います。

①価値MVP:お金を払う人がいることの検証(Enterpriseの難しさ)

  • Enterprise特有の難しさもあり、もっと解決価値が高い課題、そして我々の技術で解決可能な課題があると思います。ただ、課題をまとめるのではなく、検証可能なジョブで区切って検証します。ここは引き続き、MVPを作って挑戦していきたいです。

②市場MVP:お金を定期的に払う人が大勢いることの検証(SaaSの難しさ)

  • 企画業務が主たる業務の方には熱狂的なファンになって頂いていますが、さらに幅広い部署の方々から、業務で考える時になくてはならないSaaSだと認めて頂けるように、UI品質も意識して作り込んでいきます。

③技術MVP:本当に実現できるかの検証(AIプロダクトの難しさ)

  • ご要望として多いのが、プロダクトを活用したコンサルティング(調査支援)をお願いしたいというものです。これは、CS(カスタマーサクセス)を高く評価頂いている反面、まだまだユーザー負荷が大きい、アウトプットがツール利用者のスキルに依存してしまう、ということの裏返しだと思っています。技術を実装したMVPによって、ユーザー単独でアウトカムがいつでも得られる体験の検証を今後も続けていきます。

①〜③が掛け合わされると、飛躍的に難易度が上がるので、とてもやりがいがありますし、それが実現した時のインパクトを考えるとワクワクが止まりません。ただし、MVPが本当に難しい。

いろいろ書きましたが、MVPについて思うことはこの一言に集約されます。

MVP自体は、今直ぐにできる最低限の価値検証製品であり、恥ずかしくて仕方ない時もあるかもしれません。しかし、それが我々の目指す世界を一緒に作ろうとしてくれるユーザーを更に理解し、感動が増える解決策のヒントが得られるのであれば全く問題ないという達観が大事だと思います。そもそもユーザーの感動がなければ、恥ずかしいどころの話ではありません。
全くの無価値なものですから。
最速で学習するために妥協と諦めは必要ですが、MVPにこそ魂を込めるべきで、そこから最大限の学びを得て、チームと共有すべきです。
そのMVP達がチームを急速に育て、ターゲットユーザー全員が感動するプロダクトに辿り着く礎になっています。(ありがとう、卒業した機能たち)
『ほどよしMVP』とはそれができるMVPだと思います。

以上になります。

引き続きストックマークは、積極採用中です。
是非一緒に魂を込めたMVPを作って、世界を変えていきましょう!



この記事が気に入ったらサポートをしてみませんか?