久々に読書の時間が取れてリーンソフトウェア開発の本を読んだので思ったことをたらたらと書きます。
どんなリリースしたって批判的な意見はくるんですよ。
60点やミニマムでリリースすると何がいいかっていうと、批判に「知ってるよそれは後から作るつもりなんだ」で対応できます。
また、指摘分を実際にリリースすれば発言者も「ああ、言えばつけてくれるんだ」っていう信頼になります。
さらにいえば後出しジャンケンが可能なので、リリースの反応の大きさを見て、対応の優先順位を変えることができます。
また、予想外の「ここが足りない」「別にここは使わない」というgoogleアナリティクスやKPIの反応を見て、「見落としていたことに気づかなかったこと」も後日対応タスクに積むことができます。
知らないことを知らないことについては事前に手を打つことができません。
どんなに重厚な計画にも盛り込めないからです。綿密な調査をすればわかるかもしれませんが、粒度がある程度以下になるならリリースしてしまって直接調べたほうが早いです。
そこで後出しジャンケンで対応できることは効いてくるわけです。
逆に９０点で、大きなリリースをすると開発する中の人的には「完璧に作った」という自負があるので大きな批判や振るわない数字を見て心が折れます。
改善しても改善しても追いつかない、あるいは仮説が市場と大きく乖離していたりすると「負け戦」感の強さに心が折れそうになります。
60点リリースやミニマムなリリースの利点は「後出しジャンケン」が可能な点にあります。
ドリルダウンもロールアップもピボットも後出しジャンケンの手の出し方にすぎません。
信頼を失わないのであれば、後出しジャンケンできたほうが圧倒的にプレッシャーも敗北率も小さくなります。