また見返す可能性の高い記事を しています。
クリップ
📎 クリップした記事
プロダクトがPLG的に一人歩きして購入まで至り、自分で価値を出していく事はあり得ないと考えています。相手は人ではなく組織であり、様々なステークホルダーを経て意思決定をし、事業を営む企業体です。
購入から価値創出まで、様々な障壁を段階を経て解消していくことが必要。プロダクトの価値を分かって頂ける担当者の方に信頼いただいた上で結託し、どの部署・ユースケースを対象とするか。どういうプロセスで導入するのが現実的か、またその後はどういった風に展開し、価値を最大化していくのが良いか。営業やカスタマーサクセスがリードし、一蓮托生してお客様を支援していく必要があります。
また、"プロダクトの解釈"も重要な仕事です。大企業のシステム・業務フローや社内法系は個別最適化され、独自の複雑な進化を遂げていることが多くあります。しかし他方で、安易にN1の顕在ニーズを起点としたプロダクト開発をしてしまうと、最適化されすぎてしまいSaaSとしての汎用性は失われるでしょう。プロダクトは個社別・ユースケース別のニーズを捉えた上で、できるだけ汎用化して開発するべき（＝汎用化で得られる市場規模 vs 個社・ユースケース最適化による顧客価値向上、のトレードオフが加味される）であり、こうして汎用化されたプロダクトを再度N1ニーズに解釈して製品価値を最大化していくことも、営業やカスタマーサクセスの重要な仕事だと考えています。
特定の１社にどうしても売りたいという気持ちが強くなる事はわかるが、もしその一社以外にニーズがない機能だとしたら、作らない方がよい。もちろん個社の為ではなく汎用的に作る事を意識すると思うが、実際大体 2/3以上の機能は使われない。そういったエッジケースに集中するよりコア価値を磨き上げていくことが重要。
感想
ソフトウェアに無駄が多くなると、その分だけコードが複雑になります。またコードが複雑になるということは、機能開発のさいにそのコードでバグが起きないように意識する必要が生まれます。つまり複雑になればなるほど昔なら簡単だと思って簡単にかけてた変更が、とてもむずかしい変更になっていくのです。これが複雑化による生産性低下です。
また過去のコードは、その過去の時点では1secで処理できてたとしましょう。その時点ではデータも少なかったり、処理もシンプルだったりなどで早かった処理も、徐々に徐々に遅くなります。つまりコードは変わってないけど顧客が感じる体験（この場合は早さ）は悪くなります。パフォーマンスもUXであるため向き合う事に更にコストをかけることが重要になってきます。
まとめとして、「ソフトウェアの性質として、増やすリターンより、増やすリスクも高まる事を理解しつつ、何が重要か今本当にそれが重要かを判断して開発することが大事」そしてそのためには「エンプラ顧客の場合は特にセールスが市場や顧客理解を高め、プロダクトに対しての顕在ニーズはもちろん、潜在ニーズを獲得していくことがプロダクトづくりにはとても重要になります」
🏷️ タグ
クリップ
クリップ
🗞 登場した用語まとめ
PLG / Product-led Growth
PLG / Product-led Growth