プロダクトを失敗しないために考えていること

こんにちは、soeasy CTO の 小原(@shota_kohara) です。 soeasy buddyというB2B SaaSのプロダクト責任者をしてます。この事業はプロダクトアウト的な側面が強く、長い間プロダクトの方針を慎重に考えてきました。このプロダクトの意思決定について効果的な成長を導くために自分なりに考えたことをシェアしてみたいと思います。

汎用的な内容を意識していますが、適応できる事業形態やフェーズにはバイアスがかかっているかもしれないのでご容赦ください。

※ ヘッダ画像は みんなのフォトギャラリー（β） で可愛かったものを利用させていただきました。

プロダクトで出来ることの幅を増やさない

顧客要望やPRの獲得施策などで、プロダクトゴールと関連度の薄い機能を追加してたりして、体験の幅を広げることがあります。(例えばBtoB SaaSが徐々にグループウェア化していくような。)

一見プロダクトの幅が広がって便利になったように感じますが、実際は機能が増えるごとにユーザーにとっては選択肢が増えて複雑性が上がるのでプロダクト活用の難易度は高くなります。

大なり小なりプロダクトオンボーディングに悪影響を与え、toBならCSに提供コストの制約をかけることになったり、toCならわかりにくくて離脱につながることがあります。また利用されない機能はNPSにも繋らないので機能の複雑性は相性が良くないです。

機能を増やす場合は既存の体験の質を高める目的で体験を縦に深堀りする方針が基本は無害有益なので、体験の幅を増やす場合はトレードオフを意識しつつプロダクトゴールを修正するのが良いかなと考えています。

ユーザーの負を計画的にコントロールする

プロダクト戦略を立てるときは基本的にユーザーの課題をトリアージすることかと思います。ユーザーが負を感じたタイミングで適切な機能をリリースすることは、単純な課題解決だけでなく、よりリアルなフィードバックが得られ効果的なプロダクト学習につながります。

ユーザーが負を感じる体験を事前に予測して計画的にアレンジすることができれば、最適な機能のリリースタイミングがつかめるので効果的なプロダクト戦略を立てるためには有効です。

負を計画的に予測するためには体験のバリューチェーンを設計することが良いと考えています。最も理想的で正しいバリューチェーンを設計できたとすると、基本的にユーザーの負はこのチェーン上にマッピングできるようになります。そしてチェーン上流のボトルネックを解決すると、滞っていた下流の体験にユーザーが流れ今まで潜在して気づかなかった課題が顕在化する傾向があります。このように体験のボトルネックはバリューチェーンの上を流れていく傾向があります。

高い精度の体験のバリューチェーンを上流から課題解決していくことでユーザーが負を感じる順番を予測コントロールできるようになって、効果的なプロダクト戦略を立てることができると考えています。

プロダクトの進化速度をコントロールする

基本的には自信度の低い仮説を見切り発車で機能リリースしないほうが良いと考えています。仮説を外して中長期で見たときに機能負債になるリスクが高いからです。

可能な限り機能をリリースする前に仮説の精度を高めた方が良くて、十分なファクトが集まらない場合はその部分の意思決定は先送りできるように開発や事業を工夫して時間を稼いで学習を待ちます。機能リリースでしか仮説検証できないシーンでは、課題を分解して最小機能で成立するようにして、機能も取り外し可能な形で実装します。

大きい組織などで過剰に開発リソースがあって、仕事を作るために必要か良くわかってない機能を新しく開発するみたいなシーンで、実装がプロダクトの仮説を追い抜かすようなケースは観測しました。ここで下手にプロダクト体験を広げてしまって上記のトレードオフも発生する場合マイナスに働くこともあるので考えものです。

リソースはある分つかいたくなるので、機能企画が未熟ならハンドリングできない開発リソースは敢えて抑えて本当に必要なものだけ作らざるを得ない環境で縛りプレイした方がいいのかもと考えました。

先人の課題解決方法を学ぶ

課題解決方法を考えるときに既存のプロダクトから課題解決のインスピレーションを得るのはとても有効なので、可能な限り引き出しを増やしておくと良いと考えています。

極端に新規性が高い課題解決でもないかぎり、課題を細かく分解していくと、類似する課題を解決しようとしている既存プロダクトの機能が基本的には存在します。(自分の経験則的にはですが。)

機能企画の都度、類似のプロダクト機能を使いこみ定性的に分析して、課題背景とアプローチ方法そして結果的に解決された課題をセットにして記憶しておけば、プロトタイピング前の脳内仮説検証に比較的リアリティを持たせられるので効率的に学習できます。またその後自社で行った施策の定量結果を非同期で結びつけて記憶しておけば数値感覚分精度も上がっていきます。

細分化された課題解決のパーツを蓄えることで、その組み合わせで本来解決したい複雑で入り組んだ課題に効果的にアプローチができると考えています。

機能企画で課題至上主義になりすぎない

ミスリードを招きかねないと考え追加するか迷った項目で、生暖かい目で見守っていただければ有り難いです。

機能企画を考える上で重要度の高い課題を1つ設定して最適な打ち手を考えるというのは、おそらく基本系であり多くのケースでシンプルで最適なアプローチだと思います。ただ、1つの課題を基準とした機能企画が必ずしも効果的だというわけではありません。

最終的にリリースするのは課題ではなく解決方法(=機能)であり、機能と解決する課題は必ずしも1対1で対応するわけではないです。任意の課題を解決する目的で考えた機能は、その課題以外の問題も同時に解決する効能があったり、別の課題を生み出してしまったりと副作用を内包しているからです。つまり課題と機能は多対多の関係です。なので原理的に、複数の課題を同時に解決するような機能が存在します。そしてリリースした機能の価値は、解決する意味のある課題の対応総量で決まるので、優先度の高い複数課題を解決する一石二鳥の打ち手はより効果的です。

このような複数課題を解決するようなアイデアは特定の1つの課題だけに集中して出てくるものでは無いので、打ち手を基準にして解決する課題を考えるプロセスが効果的なシーンはあると考えています。

時に最新技術やユニークなプロダクトからインスピレーションを得て機能企画に取り入れたり、複数課題を同時期に並列で行き来して共通する打ち手を見つけてみたり、柔軟に打ち手考える目線を持つのが良いと考えます。

おわりに

近年の疑問の中で重要度が高く、書きやすいものについてて、発散的に考えをまとめたものになりましたが、ここまで長文にお付き合いしていただきありがとうございました。