編注
原文：「How to iterate on a product」。翻訳にあたり若干加筆修正を行っています。
新機能の開発 vs インクリメンタル型の開発
企業にとって最も楽しみなプロダクトの発表とは、普通は、注目を集めるような、新機能のビッグリリースに関するものです。ただ、それとはタイプが違うものの同じくらい重要な、すでにある機能のインクリメンタル（追加）型の改善については見落とされがちです。
また、プロダクト開発者は、この両タイプのリリースの価値を理解していても、どちらを重視するべきか迷うことがあります。いつ、どのように、どちらを優先すべきでしょうか。まったくの新機能のローンチと比較して、時間をかけて少しずつ機能を向上させる価値をどのように示せばよいでしょうか。
Mixpanelでは、このようなインクリメンタル型の改善を「ビルディングブロック・アップデート（積み立て型アップデート）」と呼んでいます。この記事では、長期的な成功を確実にするための実践的な方法をいくつかご紹介しながら、インクリメンタル型に関し、短期でサイクルを回していく、イテレーションに対する弊社のアプローチについてもご紹介します。
インクリメンタル型のプロダクトアップデートの優先順位を決めるポイント
まず初めに、さまざまなタイプのプロダクトアップデートに優先順位をつける方法を見ていきます。プロダクトで荒削りな部分を見つけたときは手を加えるべきですが、ただ修正するだけではいけません。
私たちが「パワーとユーザビリティのトレードオフ」と読んでいる問題に直面した場合、あるいは、華やかな新機能のローンチよりもインクリメンタル型のアップデートを優先する場合に、考慮すべき点を以下に挙げてみます。
- 顧客からのフィードバック：CSAT（顧客満足度）調査やサポートチームへの直接フィードバックから、ある機能がユーザーの不満の原因であると分かっているときは、大々的な新機能ローンチよりこの改善を優先するべきという良いサインです。
- データからの考察：ユーザーの利用行動分析などのデータを調べて、ユーザーが離脱している、または使いにくいと感じているエリアを特定します。さらに重要なことは、こうした問題がコンバージョン率など、ビジネスにとって非常に重要な指標に影響を及ぼしているかどうかを理解することです。さほど影響がない場合は、今回のインクリメンタル型改善はそれほど緊急に優先しなくてもよいかもしれません。特に、同じスプリントに別の大きな機能のローンチがある場合は、改善を優先する必要はないでしょう。
- リソースの制約：プロダクトチームとしては、できるだけユーザーのあらゆる課題を即座に解決したいものですが、時間がない、開発者が足りないなど、リソースが限られている場合がほとんどです。取り急ぎの解決策を遂行するリソースしかないのであれば、その対象の優先順位が低かったとしても、できる範囲の対応策を完了してしまうほうが良いかもしれません。
小さな機能改善より大きなリリースを優先すべき場合とは
プロダクトのインクリメンタル型改善が必ずしも重要な指標に直接結びつかないとしても、それがユーザー体験に大幅にプラスに働くと純粋に信じているからこそ、私たちは改善を推し進めます。しかしながら、すべてケースバイケースで、白黒つけられるような正解があることはめったにありません。プロダクトチームにとって、それらのちょうどいいバランスを見極めることはチャレンジです。
経験則として、大規模な機能リリースと何個かのインクリメンタル型のプロダクトアップデートを天秤にかけるときは、小さなアップデートがどのようにビジネスに大きく貢献するかを説明できるかどうか確認しましょう（理想はデータによる裏付けがほしい）。簡単に説明できない場合には、大規模なリリースを優先したほうが良いでしょう。
