プロダクトの基礎 · 入門

作らないものを選ぶ

一行でいうと: 「ノー」と言える力こそが、出荷されたプロダクトと永遠に開発中のプロダクトを分ける。

なぜこれほど難しいのか

個々のリクエストは単独では合理的に聞こえる。問題は単一の機能ではなく積み重ねだ。追加のたびに、保守すべきコード、学ぶべき画面、そして半年後に他の何かを壊すエッジケースが生まれる。機能のコストは開発の一週間ではなく、その後の全ての年月である。

三つのフィルター問い

誰が要求したか。声の大きな一人の顧客は市場ではない。一週間で何人のユーザーがこれに触るかを聞け。

なくてどうなるか。答えが「少し不便」なら、最初のバージョンには入れない。

何を置き換えるか。タスクリストの長さが固定なら、何かを入れるには何かを出す必要がある。「これも追加しよう」より健全な会話だ。

断り方

「ノー」は理由と場所を伴う。「このバージョンではやらない。追っている指標はハンドリング時間であり、これはそれに影響しない。最初の計測の後で再検討する。」優先順位を理解した人は議論をやめる。

却下リストを見える場所に置け。繰り返しの質問を防ぎ、時間が空いたときの最初の参照先になる。

さらに深く

完璧に動く十の機能を持って出荷されたプロダクトは、四十の凡庸な機能を持つプロダクトに勝る。コードでも同じだ:論理の分岐はテストすべきパスを増やす。スコープを削ることはビジネスの決断だけでなく、最も安いアーキテクチャの決断でもある。