そろそろ手を動かし始めようかなあ、と思ったときに、まず最低限下記の条件が満たされているか確認しましょう。これらが満たされていない状況で手を動かし始めると、不適切なアーキテクチャを採用してしまったり、余計な機能を作ってしまったり、一度作った機能を修正する手戻りが発生しがちなので要注意。
ここらへんはデザイナの人がやることが多い（けど別にそれ以外のメンバーがやっても OK）。詳細な仕様ではなく、全体像が見えること、全体像を見ながらリリースのスコープを話し合える状態になっていることが重要。この時点でざっくりとした工数の見積りができるとすばらしい。
呼び名が定まっていないと後続のデータベース設計でコケます。あと適切なネーミングになっていないせいで、解決のアイデアの方向性が狭まったりずれていってしまうことも多々あるので注意。
特に新規サービスを立ち上げるタイミングでは、そもそもリリースして何を達成したいのだっけ？ という視点から作りものの範囲をなるべく小さくしていくことが重要。なんなら別に実際に作らなくてもよくない？（ペーパープロトタイピング等でよくない？）となることもある。
リリースのコアな価値を構成する重要なユーザ体験について、技術的な妥協を行うと著しくその価値が下がってしまう場合には、多少背伸びをして技術的なチャレンジをする。特に実現の技術的な見通しに見当がついていない場合は、その領域だけをアプリケーション本体から切り出して実際に作ってみる。逆に、「動けばよい」「最終的にユーザが○○できればよい」という形で妥協が可能であれば、仕様を自分たちの力量に合わせて単純化していく。リリースの全体像を見ながら「頑張りどころ」と「普通にやればできるところ」の当たりをつけていく。