作り過ぎ防止 / Preventing Overdevelopment
機能開発関連の施策を考えるときに
A : 本当に小さい仮説検証で良いものと
B : 一度リリースしてユーザーに見せてコケると不可逆性が高いもの
がある。
Aは、できるだけ作らず。の精神が良い。エンジニア・デザイナーだとどうしても機能を作ってリリース欲が出てきてしまうが作らない精神で行く。とりあえず仮説を検証できる範囲でプッシュ通知だけ送って開封率をベースにニーズを見るとか、管理画面から簡単にビューだけ変えるとか。
例えば、ランキングを見せてユーザーエンゲージメントを上げてサービスにRRを上げる。みたいなものだったら、とりあえず現在の順位なをサービス内でのポジションをプッシュ通知で送る。1人日でやる。
ユーザーの反応がよかったら、1人月かけてもっと具体的な順位表示を作ったり報酬を与えたり、ランキングをあげるため戦略をユーザーごとにレコメンドしてあげるとか。
楽天ポイントでいうとこういうLPでもいい。これで効果があったら機能として常にランキング機能として盛り込む。
Bは、一度ユーザーが絶望すると再度戻ってこないやつ。ゲームとかそうかな。
また、マーケティング戦略も込みで施策を打たないとスパイクして（ある種バズりを作る）いかないと意味がなく、リリースして少し立ってからマーケティング施策を打っても効果が薄かったりする。
この、いきなりBをやるべきなのか、AをやってBを作るべきなのかの勘所みたいなものは、市場分析をしたりカスタマーサクセスを考えたりしないと出てこないんだろうなと思う。工数でAとBを判断するのも少し違う
これはMVPをどこでスライスするかの議論にも似ている気がする
When considering measures related to feature development, there are: A: Things that can be validated with a very small hypothesis test. B: Things that, once released and if they fail in front of users, have a high irreversibility.
For A, the principle of “doing as little as possible” is ideal. Engineers and designers tend to want to create and release features, but it’s best to resist that urge. For instance, just send a push notification to gauge interest based on the open rate, or simply adjust a view from the management screen. For example, if the goal is to show rankings to increase user engagement and raise the retention rate in the service, just send the current ranking position in the service through a push notification. Implement it in one day. If the response is good, spend a month creating a more detailed ranking display, providing rewards, or recommending strategies to users to improve their rankings. A good analogy might be Rakuten Points — if it works, incorporate it consistently as a ranking feature.
For B, once users are disappointed, they often don’t return. This might be the case with games. Also, without integrating a marketing strategy into the initiative, releasing it won’t mean much unless it creates some kind of buzz. Releasing and then trying a marketing strategy after some time might not be very effective. Deciding whether to go with B straight away or starting with A and then building B requires insights from market analysis and thinking about customer success. Deciding between A and B based solely on work hours might not be accurate.
This is similar to discussions on where to slice an MVP.
