「早くリリースして、早く改善しよう」の落とし穴―― 開発畑のプロダクトマネージャーの失敗から学べ

はじめに はじめまして。ゆずたそ（@yuzutas0）と申します。私はソフトウェア開発者からプロダクトマネージャーへ役割を変更した後、多くの失敗を経て「マインドセットを切り替えること」の重要性を痛感しました。 この連載では、私が学んだ「プロダクトマネージャーのマインドセット」を解説します。 想定する読者・提供価値については、2つのパターンを想定しています。1つ目は「同じように失敗した経験のある人」です。自分の経験を振り返りながら「こうすればよかったのか！」と考える機会になるはずです。2つ目は「これから失敗を経験するであろう人」です。これから起きる課題について「こうすればいいのか！」と考える機会になるはずです。 注意・免責 ①本連載の内容は、筆者の個人的な見解にもとづきます。適宜ご自身の立場に置き換えて、読み進めていただければと思います。万が一、誤りや不快な点がありましたら、どうぞ筆者個人宛

[gumiiinfohazero]

開発者の立場だととりあえずリリース時にモチベーションピークが来て、後の重箱の隅をつつく修正やテストが疎かになりがち。そして飽き性な人は、次の新しいおもちゃ見つけ手をだし、前のサービス放置状態みたいな..

[yuzutas0]

「顧客にデバッグさせるな！」という話を書きました

[paradisemaker]

「早くリリースして早く改善しよう」が流行った時代と今ではプロダクトの複雑性もユーザへのインパクトも全然違うので真に受けてはいけない

[matsumoto_r]

特に事業やプロダクトのオーナーシップを持たずに、簡単に妥協して他人事のようにただ「リリースして改善しろ」と言っている場合とかは本当にヤバい状況なのでぜひ読んでほしい

[rryu]

見切り発車ででテストを始めると複数のテスターから同じフィードバックが返ってきてグダグダになるやつを全利用者の規模でやるのだからうまく行くはずがない訳で。

[rck10]

巧遅より拙速、も拙さが過ぎると対応コストが馬鹿にならないよ、という話。金融系だとインパクト的に当然なんだけど。雑にリリースすると7Payみたいに大惨事になる。

[d4-1977]

問題を見極めるために何を試すか？を決めて、見極めるための何かは、さっさとリリースしましょう、ということなんだと思う…が、エンジニアのどうやって作るとは、切り替えて判断するのが必要で切り替えコストが高い

[tattyu]

「小さくリリースして、早く改善しよう」じゃなくて「早くリリース」しようか。たしかにダメそう。

[h_taiji]

共有

[for-my-internet-demo]

だってだってだってだってだってなんだもん…

[otihateten3510]

“結果はダメでした。「このボタンは何か？」という問い合わせが大量に寄せられました。問い合わせ対応とUI改善に時間を取られて、次の機能追加のスケジュールは大幅に遅延しました。”　ん？？効果あったのでは？？

[versatile]

開発者にも色々いて、既存の改善やリファクタが好きな人も多い。一から作るのよりそっちの方が好きって人。だって、一から作ってもリリースされないかもしれないじゃん