大きいMVPとその弊害

「MVPは想像しているよりもずっと小さい」という言葉もあるが、基本的に人はMVPを大きく作り過ぎてしまうものである。

永遠に続くプロダクト開発においてどのタイミングでリリースするかの観点でしかなくMVPに盛り込まれない機能が金輪際開発されないわけではないのだが、どうしても各所から「この機能は入ってないのか」という声が大きくなってしまうからだ。

その思いつきやすい弊害としては、開発コストが大きくなりリリースコストが増えることが挙げられる。

不確実性の高い現代はフィードバックループを素早く回すことが大事であり、まずは顧客に刺さるプロダクトを素早く見つけるためにMVPはできる限り小さくした方が良い。

ただ実際に大きすぎるMVPを持つプロダクト開発をしてみて追加で思うことがあったので、まとめていく。

機能追加に対する検証が十分になされない

プロダクト開発において機能追加すれば確実にKPIが上がるわけではなく、むしろ悪化する場合もある。

日本のTVのリモコンは最たる例で、できることが増え煩雑になるとむしろ離脱率が上がっていくものだ。

たとえばユーザ登録時点で「あなたの年収」って項目を追加したら、ユーザ登録率が下がるかもしれない。

そのため機能追加した際はKPIの変化を注視するのが一般的であり、最悪の場合は元に戻すこともある。

しかしMVPに盛り込まれる機能は、基本的にそれがなされることはない。

その効果が検証されることなく、プロダクトに盛り込まれ続けることになる。

つまりMVPに過剰に機能が盛り込まれることは、それ自体がプロダクトの限界を決定づける要因になり得るのではないだろうか。

たとえばMVP時点でユーザ登録に何分もかかるような多数の項目を設けてしまった場合、ワンクリックでユーザ登録できるようなサービスにはなりづらいのだ。

もちろん後から削ることは可能ではある。

しかしどんな機能であれ使ってるユーザはいるわけで、「この機能を使ってるユーザがX%いる」を理由に機能を削る意思決定はされづらい。

また既存ユーザもそのUI/UXになれてしまうため、新規ユーザが定着しづらいUXであっても既存ユーザからすると使いやすいものとなってしまうのだ。

そのためどうしても一度追加した機能をなくすことは難しいのである。

営業主体組織と機能追加

若干話は変わるのだが、営業主体の組織だとあらゆる顧客の要望に応えられるプロダクトが正となる。

つまりなんでもできる自由度の高いプロダクトを目指して、カスタマイズ性の高い、人力のオペレーションに依存したサービスに育ちやすい。

営業成績の向上の観点において、UI/UXの悪さによる離脱率はそこまで関係がないのだ。

そのため経験則として営業主体の組織ほど、どんどん機能追加の方向に力学が向かいやすい。

特に目の前の巨大案件のための機能追加を繰り返すこととなり、「数%のユーザのための機能」が無数に増えていくこととなる。

そうなるとそもそもどんどんスケールさせていくプロダクトと根本的に進化のベクトルが変わっていくこととなる。

もちろんそれが悪ではなく、人力の営業でないとそもそもスケールさせづらい領域は存在する。

その場合はその戦略が最適になるのかもしれない。

しかし現代のプロダクト開発の教科書的な手法とは、根本的に考え方が変わってくる可能性はある。