あけましておめでとうございます、Anyflowの坂本です。
気がついたらnoteを書くのが2年ぶりとかになってしまいました、時間が立つのは早いですね。。

noteをサボっていた2年の間もAnyflowの代表とプロダクトマネージャーを兼任しており、「これは失敗したなあ」というのと、「これはうまくいったかも」というプロダクトマネジメントの考え方や失敗をシェアしようと思います。

このnoteは、このような人におすすめです！

では本編 👇

失敗したプロダクトマネジメント🙅‍♂️

 表層の課題を本物の課題と錯覚して開発を進める

前提として、プロダクト(特にSaaS)が解くべき課題というのは、企業で顕在化している課題があり、緊急性が高く、課題解決のためにお金や様々なコストを払ってまで解決したい、という特性を持ち合わせた課題だと考えています。

課題が顕在化しており、緊急性が高く、コストを払ってまで解決したい課題、というのは所謂バーニングニーズであり、本物の課題です。

では、一方で表層の課題というのは何か。
裏を返せば "バーニングニーズではないもの" になるわけですが、例えば新規事業を開発していて、ユーザーインタビューなどで既存の代替手段についてヒアリングしたところ、以下のような声が聞こえてきたとしましょう。

このような声から「UIを現代風にアレンジしてSaaSで提供し、ブラウザで使えるようにすればいいのでは？」「日本語対応と日本語によるサポートだ！」と安直な意思決定をするのは、おおよその場合アンチパターンです。

なぜか。
それは、既存の代替手段において上記のようなインサイトは、あくまで表層化している軽微なペインであり、特にゼロからプロダクトを作り上げる際には解くべき課題ではない、強いペインではない可能性が高いからです。

現状発生している問題を解決している代替手段、すなわち何かしらの作業、サービスやプロダクトにおいて、どんなに素晴らしいモノでも不満や、改善ポイントが一つもユーザーから出てこない事はありません。
特にユーザーインタビューのシーンでは、「何か言わなければ..」という心理状態が働くため、何かしら絞り出してしまいます。

では、どのようにして本物の課題を見つけるのかというと、身銭を切る行為をユーザーがしうるか、という検証をするというのが良いと考えています。

ちなみに、身銭ポイントという概念が以下の本にて紹介されており、身銭ポイントが高いほど信憑性があると判断して良いと思います👇

課題を探索し、解決する課題に値するか見極める際には、その課題を解いた場合にユーザーは身銭を切ってまで（お金を払って使ってくれる、デポジット、相手の時間をもらう等）プロダクトを使ってくれるか？というのは、本物の課題を見分けるリトマス紙になります。

対象ユーザーが身銭を切るまでの課題なのか、という検証を可能な限り早く終えることで、事業開発の時間短縮になると感じています。

 ターゲットにフォーカスしていない

ここでいうターゲットというのは、プロダクトがエントリーしている市場、プロダクトを使う人、決裁を取る人、問い合わせをする人等のニュアンスが混じっています。

海外で最近流行っている、バズワードになっている、自社の近接領域で競合が新しいサービスを始めた等の理由から新規プロダクトや新機能を作った場合、「結局このプロダクトや機能は誰が使うのか？」というターゲットがふわふわしてしまうケースはあるあるかなと思います。

例えばSaaSであれば

• プロダクトに興味があって問い合わせる人

• 問い合わせた人に呼ばれてミーティングに出ている人

• 決裁を取る人

• 運用フェーズにプロダクトを実際触って使う人

• プロダクトの恩恵を受ける人

がバラバラだったりします。
事業進捗と共にターゲットの解像度は上がっていきますが、ターゲットがファジーになっていることで、バリュープロップが語れない、LPやプレスを作る際に誰に何を訴求していいかブレる、わからないといったことが起きます。

ターゲットを絞るのは勇気がいりますが、目の前の1人に刺さらないプロダクトは、インターネットの先にいる更に多くの人に刺さることはないので、勇気を持ってターゲットを絞りましょう。（自戒含む）

記憶が正しければ、家入一真さんが「ラブレターを書くようにプロダクトを作る」みたいなことをどこかで仰っていて、特にLPや商談資料を作る際なんかは、ユーザーさんの顔が思い浮かぶような状態じゃないと刺さるものって作れないよなぁ、と強く感じます。

成功したプロダクトマネジメント🙆‍♂️

ホームランを狙わずにヒットを打ち、本当に必要な機能だけを作る

大変ありがたいことに、商談の中でお客様に「とても短期間で作れるようなプロダクトでは無い」「そんなに少ない人数で作っていたのですか？」という言葉を頂く機会があります。

これらは、エンジニアがケイパブルであるという変数以外にプロダクトマネジメントにおいて、あえてホームランを狙わずにヒットを打ち続け、本当に必要なスコープに限りなく削った上でリリースサイクルを早める、という戦略が積み重なった結果なのではないかと感じています。

ここでいうホームランというのは、「XXという機能を作ったら売上がN倍になるのでは？」といった、一発逆転を狙った仮説主導の博打打ちに近いような施策のことを指しています。

誤解がないように説明すると、ホームランを狙ってはいけないというわけではなく、特に立ち上げフェーズにおいては極々限られたリソースで間違いなく成果を出す必要があり、ホームランを狙う前に確実にヒットを積み重ねる方が合理的であるという話です。

ヒットを打つためには、「あったら便利」という機能の優先度を下げ、仮説主導の開発をしないということが個人的には重要であると考えています。

あったら便利を避けるためには、

1. 開発するモチベーションが生まれた時点で、そのジョブを見定める

2. 特定したジョブを満たしている既存の代替手段を観察し、代替手段が存在していない場合はそもそも作ることをやめる

3. 開発する場合には、ジョブを満たす最小のソリューションを検討し、徹底的にスコープを削り、後で追加できる機能は後で作る

というフレームに当てはめることが多いです。

「使われるはず、使うかもしれない」という機能を作らず、後で追加できるものは後回しにし、拡張できるようなアーキテクチャにしておき、必要性が生じた際に開発していく、というプロダクトマネジメントスタイルを意識しています。（言うは易く行うは難し..）

ただ、この手法はあくまで連続的な改善には有効ですが、非連続性を求めた施策には有効ではない可能性があるので、使い所は見定める必要があります。

👇のイーロン・マスク氏のインタビューが興味深いのでおすすめです。

すべてを理想から始める

ここでいう理想というのは、プロダクトのUXであったり、ビジョン、方向性を指します。

例えが適切かはさておき、例えばPMは将来的に10階建てのマンションにしたいと思っているが、時間がないので10階建てのうち、まずは2階建てのマンションを作るとします。

一方で、エンジニアは2階建てのマンションを建てるだけと理解していた場合に、土台から何から作り方は全く異なりますよね。

PMが実は心の中で10階建てのマンションを建てたいと思っていても、HOWや目先の事だけを伝えた場合、エンジニアは2階建てのマンションを立てることを前提に進めるのは当たり前です。

そして、時間が経過してPMの想定通りに10階建てに増築しようとしますが、2階建てを想定した土台になっているので、増築しようとすると土台がぐらつき、取り戻しがつかなくなるということが起きます。

特にAnyflowというプロダクトは複雑性が高く、拡張性が求められるプロダクトのため、初期にエンジニアに短期、長期的なマイルストーン、ホールプロダクトのビジョン等のすり合わせを時間をかけて行ったのは功を奏しました。

ただ一方で、「本当に必要な機能だけを作る」という話と若干矛盾するためバランスを取るのが難しく、また、設計に多大な時間を要するリスクがあります。（Anyfowは設計だけで3ヶ月くらい要した記憶）

まとめ

ということで、こんな感じでプロダクトを創っていたりします、というnoteでした。

まとめると、

• 表層の課題ではなく、ユーザーが身銭を切る本物の課題を探索する

• ターゲットを絞るのは怖い。が、とにかく絞ってユーザーの顔を頭に思い浮かべながらラブレターの如くプロダクトを作る

• 既存の代替手段がない課題を解かず、スコープをとことん削って早くリリースする

• プロダクトの長期的なビジョンをエンジニアに初期から共有する

という感じです。

やや抽象的な話になってしまいましたが、何かしらお役立ちできていれば幸いです。
更に詳細を知りたい等の声があればコメントやTwitterにて教えて下さい。

最後までお読みいただいてありがとうございました！

----- PR -----
Anyflowに興味がある方（主にエンジニア、プロダクトマネージャ）の方からのDMをこっそりお待ちしてます！！🫵