プロダクトファーストマネジメント その1
マネジメントと言っても、色々なタイプのリーダーがいて、その数だけやり方も違います。
また、実際に作るもの、求められているものによっても手法は変えるべきだと思います。
今回は、私が新規プロダクトの開発リーダーを任された時に実践した手法を、回数を分けて説明しようと思います。
この記事では、実際に開発に入る前に決めるべきこと、やるべきことを紹介します。
プロダクトのコンセプトを決める
まず、何を作るのかを明確にします。
重要なことは、そのプロダクトで何を実現したいのか?ということです。
注意すべきことは、コンセプトとキャッチコピーは違う。 ということです。
コンセプトは何を実現したいのか。キャッチコピーは何ができるのかユーザーにわかりやすく表現した言葉です。
コンセプトからプロダクトが生まれ、プロダクトからキャッチコピーが生まれます。
コンセプトを決め、今後の開発の指針として利用します。
開発方針を決める
コンセプトを実現するために、開発メンバーで何をするべきか決めます。
メンバー全員が覚えやすく、短い言葉でシンプルにしましょう。
多すぎると混乱の元なので、3つ程度に留めておくことをオススメします。
例
- スピード
- シンプル
- モバイルファースト
- 拡張性
- 使い勝手
- etc
使い方
モバイルファーストを開発方針に選んだ場合、モバイルユーザーとPCユーザーを天秤にかけた際に、迷わずモバイルユーザーを優先できます。
このように何かを比較して選択する時の指標として使うことができ、チームが進む方向を明確にできます。
プロダクトファーストとプロジェクトファースト
「開発方針」が軸になると、「開発方針がこれだからこっちだと思う」という風に、チームメンバー共通の軸をベースに議論することができるようになります。
「個人の意見」が軸になると、「私はこう思う」「俺はこう思う」「じゃあ間をとってこれ」というように、「みんなの意見が反映された」プロダクトになります。
私は、開発方針が軸になることを「プロダクトファースト」、個人の意見が軸になることを「プロジェクトファースト」と呼ぶようにしています。
プロジェクトを円滑に進めることへの意識が強いチームだとプロジェクトファーストになることが多く、良いものを作る意識が強いチームだとプロダクトファーストになることが多いです。
どちらの考え方が今のプロジェクトに合っているか、よく考えて開発方針を運用するべきです。