ウェブサービスを作っています。
いろいろ試行錯誤中なので現時点での仮説です。
実証できてないので机上の空論の可能性も。

掛け算理論

プロダクト = 機能 * パフォーマンス * エラーの少なさ * UIのUsability

売上 = プロダクト * プライシング * マーケ * カスタマーサポート

これらのどれに投資するかを考えます。

分類

サイエンスしやすいもの

効果が客観的に計測しやすく。
客観的にPDCAできるもの。

• パフォーマンス
• エラーの少なさ
• マーケ(ウェブ広告)

少しサイエンスできるもの

やってみれば効果がわかるもの。
または、自分が良いと思えば他人も良いと思いやすいもの(UIのUsability)。

• 機能 (既存機能の改善)
• UIのUsability
• プライシング

サイエンスしづらいもの

やってみるまで(または、やってみても)効果がわからないもの。

• 機能 (新機能)
• マーケ(ウェブ広告以外)

プライオリティー

コスパ最大化

売上をなるべく速く増やすために、もっとも微分の大きいものからやっていくと良い。
微分の大きいものは、たいがいもっとも悪いものなので、もっとも悪いものからやっていくと良い。

例えば、総リソースがxだとして、売上yがn個の要素の掛け算でできまるとすると、yを最大化するのは均等配分した場合。

y = (x / n) ^ n

ある要素のリソースがzで、他を均等配分した場合、

y = ((x - z) / (n - 1)) ^ (n - 1) * z

x = 1, n = 5の場合のプロット。zが小さいほど微分が大きい。

また、サイエンスできるものは最適化しやすいので、サイエンスできるものからやっていくと良い。

リスク最小化

リスク(ボラティリティーの意味で)をなるべく速く減らすために、もっともリスクが大きいものからやっていくと良い。
サイエンスしづらいものはリスクが大きいので、サイエンスしづらいものからやっていくと良い。

サイエンスしやすいものとしづらいものどっちからやるか？

実際には、multi-armed banditみたいに選ぶ感じだと思います。
multi-armed banditのUCBアルゴリズムなどを参考にすると、以下のような式が最大のものからやっていくと良いと思います。

f = リスクの大きさ + コスパの大きさ

コスパの大きさ: 現在のクオリティーの低さ

大きい市場を狙うスタートアップみたいな場合は、リスクがものすごい大きいので、しょぼいMVP(minimum viable product)で検証して、リスク最小化をやるのが最適戦略なんだと思います。

ニーズ情報などを得て、ある程度リスクが減ってきたらコスパ最大化にシフトするのが良いと思います。

個別tips

プロダクトの非機能要件は二乗で効く

パフォーマンス、エラーの少なさ、UIのUsabilityは、プロダクトの習熟度合いに依らず影響するので、新規獲得とリテンションの両方に効きます。
掛け算理論的には、二乗で効くのでコスパが良いです。

一方、機能はプロダクトに習熟している人により強く影響します。

新機能や機能改善も二乗で効く

新機能や機能改善はニュースバリューを持ちやすいです。
それらを出すとマーケの効果もあります。
つまり、掛け算理論的に、二乗で効きます。
なので、マーケよりも新機能や機能改善のほうが優先順位が高いです。

マーケのコスパはプライシングよりも悪い

この資料によるとマーケのコスパはプライシング最適化よりも悪い一方で、プライシングよりもマーケに注目しがちみたいです。

リソースが無い場合、掛け算理論の指数が小さいものを狙う

領域によって掛け算理論の指数が変わります。
例えば、プラットフォームのようにネットワーク効果が効くものは、
指数が倍になります。
一方でブログやアフィリエイトのようなものは、指数が小さいです。
極論すれば記事だけ書けば良いので、指数1です。

指数が大きいと関数の形からリソースが大きい人が一人勝ちしやすいです。
行列の固有値をべき乗法で求めるようなイメージです。
べき乗法の正規化が市場規模によるキャップに相当します。

指数が小さいとかけたリソースに応じた結果が返ってきます。
個人でブロガー、アフィリエイター、YouTuberなど、コンテンツ一点集中型が多いのはこういうことだと思っています。
厳密には、Google経由の流入はコンテンツに比例しないのであれですが。

リソースが無い場合は、指数が小さいものを狙うと良いと思います。

依存関係に注目する

プログラミングでは依存関係が重要です。
安定依存の原則や、依存関係逆転の原則など原則にもなってます。
今回のケースを依存関係で考えると("A <- B"は"BがAに依存している"とする)、

ニーズ <- プロダクト
ニーズ <- プライシング
ニーズ <- マーケ
プロダクト <- プライシング
プロダクト <- マーケ
プライシング <- マーケ

簡略化すると

ニーズ <- プロダクト <- プライシング <- マーケ

のようになっています。
こういう場合、上流のニーズからやっていくのが、変更が少なくて効率が良いはずです。

名前

名前はマーケに効きます。
以下のような特性が良いと広まりやすいはずです。

プログラムであればあとでシリアライザや変換器を作ったりできますが、
名前の場合はそこはアンコントローラブルです(SEOで対応できるかもしれませんが)。
もともとそういう特性がある名前を選ぶのが大事だと思います。

英語ですが、名前考えるのにおすすめサービス
https://namelix.com/

概念

• 覚えやすい

シリアライズ

• 発音しやすい
• タイピングしやすい (今ならスマホ入力しやすい？)

パース

• 聞き取りやすい
• 視認しやすい

フォーマット変換

• 文字だけ見て読める
• 音だけ聞いて書ける

先人の知恵

自分が良いと思うものを作れ

良いデザインが出て来やすいのは、 対象とするユーザーがあなた自身を含んでいる時だ。 あなた自身を含まないグループに対して何かをデザインしていると、 対象ユーザー層は自分より上ではなく、下だと思ってしまいがちになる。
あなたがまぬけのために何かをデザインしているんだとしたら、 まぬけにとっても役に立たないものをデザインすることになるのが落ちだろう。

プログラミング原則の適用

プログラミング原則はビジネスにもあてはまることが多いと思います。

プログラミングの設計は組織構造を反映すると言われています( https://forza.cocolog-nifty.com/blog/2014/12/2-ed73.html )。
組織構造はビジネス構造を反映すると思います。
つまり、プログラミングの設計はビジネス構造を反映しています。

ということは、逆にプログラミング原則をビジネスに使えそうです。