スタートアップの成功の鍵は、プロダクトとエンジニアリング間の密接な連携です。これは簡単そうに聞こえますが、非常に難しい場合があります。両グループには、調整が必要な相反する目標や、成功の定義が異なる場合があります。エンジニアリングは、最高の開発者エクスペリエンスを備えた、将来のために完璧にスケーラブルな製品を構築したいと思うかもしれません。プロダクトは、アイデアを迅速に検証し、顧客が製品にお金を払うように促す機能を出したいと思うかもしれません。よく見られる別の例は、エンジニアリング主導の「エンジニアリングロードマップ」と、プロダクト主導の「プロダクトロードマップ」があり、この2つが完全に独立しており、製品エンジニアリングに混乱をもたらすことです。これらの2つの考え方が、組織の2つの部分を対立させています。簡単な道は、困難な会話をスキップし、サイロ内で運用し、リリースを行うために頻繁に集まることです。私たちは、これらの異なる2つの組織を結束力のあるチームユニットに統合することで、組織の摩擦を取り除き、価値実現までの時間を改善すると考えています。
ボトルネックにどのように陥ったのか？
スタートアップの初期段階では、連携は自然に行われます。なぜなら、少人数のチームが緊密に連携して作業しており、おそらく製品と技術のリーダーは会社設立前から親密な関係にあったからです。最初のスタートアップのアイデアは非常に強力であり、急速に勢いを増すにつれて、次に何に取り組むべきかがすべてのグループにとって明確になります。しかし、会社が成長するにつれて、より多くの管理層を持つスキルベースの垂直構造が現れ始め、これらの管理者は常に同僚との効果的な協力関係を築く努力をするとは限りません。代わりに、アプリケーションの実行を維持したり、資金調達ラウンドの準備をしたりするなど、緊急のタスクに焦点を当てます。同時に、スタートアップは、製品にどのように投資するのが最善かを決定する必要があり、そのためには全体的な戦略が必要です。
うまく運営されているスタートアップは、すでにクロスファンクショナルな製品チームで作業しています。一部の機能は、同じ垂直階層に属しているため、自然にうまく連携します。例としては、開発とテストが挙げられます。スタートアップではうまく統合されていますが、従来のエンタープライズITではサイロ化されていることがよくあります。ただし、私たちが協力しているスケールアップでは、製品チームと技術チームがかなり分離していることがわかります。これは、従業員が活動指向の組織で機能に重点を置くようになり、成果指向のチームではなくなったときに発生します。これはあらゆるレベルで発生します。製品マネージャーは技術リードやエンジニアリングマネージャーと連携していません。ディレクターはディレクターと連携していません。VPはVPと連携していません。CTOはCPOと連携していません。
最終的に、ボトルネックは、顧客とビジネスの価値の創出を妨げるため、組織のパフォーマンスの低下として感じられるでしょう。スタートアップでは、組織の緊張、破壊的な例外、チェックされない技術的負債、速度の低下として現れるでしょう。幸いなことに、製品とエンジニアリング組織間の摩擦を示すいくつかの重要な兆候があります。この記事では、これらの兆候と、コミュニケーションの障壁を下げ、バランスの取れた投資ポートフォリオを構築し、長期的に投資収益率を最大化し、リスクを最小限に抑えるためのソリューションについて説明します。
スケーリングのボトルネックに近づいている兆候
部門間の責任のなすりつけ
チームメンバーは、ビジネスや顧客のバリューストリームの代わりに、管理構造や機能リーダーシップを第一のアイデンティティとして捉えるため、チームが「私たち」対「彼ら」という姿勢をとりやすくなります。
最悪の場合、「私たち対彼ら」の姿勢は、お互いにほとんど敬意を払わない、本当に有害なものになる可能性があります。製品リーダーが要件を丸投げし、エンジニアリングチームをフィーチャーファクトリーとして扱うときに、これが現れているのを見てきました。プロジェクトがKPIを満たしていないという事前の兆候なしに、プロジェクトが結果を出せない場合に、プロジェクトを突然キャンセルする可能性があります。または逆に、エンジニアリングチームは、これが起こる可能性があるという警告なしに、納期を守らずに製品チームを常に失望させます。最終的な結果として、両サイドがお互いへの信頼を失います。
プロダクトの背景知識不足によるエンジニアの停滞
製品マネージャーが、エンジニア（通常はJiraのようなツールの構造内）とレビューせずに機能と要件を渡すと、重要なビジネスと顧客のコンテキストが失われる可能性があります。エンジニアがコンテキストなしで運用する場合、設計や開発の決定を下す必要がある場合、自ら情報に基づいた決定を下すのではなく、一時停止して製品マネージャーを追跡する必要があります。あるいは、さらに悪いことに、とにかく決定を下し、製品ビジョンの誤った理解に基づいてソフトウェアを構築し、遅延や未使用のソフトウェアを引き起こします。この摩擦は、フローを中断し、デリバリーバリューストリームに不必要な無駄をもたらします。
見過ごされた依存関係
エンジニアとアーキテクトが最小限のコンテキストで運用する場合、変更の全範囲が見落とされたり、誤解されたりする可能性があります。要件やユーザーストーリーは、コンテキストがないと深みがありません。顧客ペルソナが無視されたり、ビジネスルールが考慮されなかったり、技術的な統合ポイントやクロスファンクショナルな要件が見過ごされたりする可能性があります。これにより、ビジネスまたは顧客エクスペリエンスに対する土壇場での追加や意図しない中断につながることがよくあります。
責任の所在が曖昧な作業
タスクが曖昧になる、チームメンバーが他の誰かがアクティビティを担当すると考える、チームメンバーが他のチームメンバーが自分の領域で作業していると考えてお互いを押し退ける、あるいはさらに悪いことに、チームメンバーが「それは私の仕事ではない」と言う、これらはすべて、役割と責任が不明確であり、コミュニケーションとコラボレーションが不十分で、摩擦があることを示しています。
技術的負債の交渉決裂
技術的負債は、以前に議論した多くの根本原因を持つ、最新のソフトウェア開発の一般的な副産物です。製品計画中に製品組織とエンジニアリング組織が効果的にコミュニケーションやコラボレーションを行っていない場合、投資ミックスが偏っている傾向が見られます。これは、製品バックログが新機能の開発に偏っており、技術的負債の返済に十分な注意が払われていないことを意味する可能性があります。
例としては、
- インシデントの発生頻度が高く、本番環境のサポートコストが高い
- 摩擦を回避しながら機能を次々と生み出そうとする開発者の燃え尽き症候群
- 顧客がすぐに放棄する、品質の低い機能の広範な機能リスト
コミュニケーションはするが協調しないチーム
自分たちの仕事について定期的に話し合うチームは、コミュニケーションをとっています。作業中に積極的に意見を求めたり、提供したりするチームは、協調しています。チームがさまざまなコンポーネントに関する最新情報を伝える定期的な状況会議を開催することは、チームが協調的であることを意味するものではありません。協調は、チームがお互いを積極的に理解しようとし、作業中に積極的に意見を求めたり、提供したりするときに発生します。
ボトルネックからどのように脱出するか？
製品チームが十分に機能するためには、製品とエンジニアリングの間の壁を取り除くことが不可欠です。クロスファンクショナルチームは、効果的にコミュニケーションとコラボレーションを行い、目標を達成するための最善の方法について互いに交渉できる必要があります。これらは、Thoughtworksがスケールアップクライアントと協力する際にこのボトルネックを克服するために適用してきた戦略です。
「ファーストチーム」を特定し強化する
最も基本的な点で、製品チームは、ビジネスと顧客の価値を生み出すという共通の目標を中心に共同行動するために集まった個人のグループです。各チームは、独自のやり方、または独自の範囲で、その価値創造に貢献します。リーダーとして、組織の報告構造ではなく、価値創造を中心としたチームダイナミクスを特定し、強化することが重要です。このクロスファンクショナルな製品チームは、チームメンバーの「ファーストチーム」になります。リーダーとして、自分のチームを直接の部下のグループとして定義すると、「私たち対彼ら」のダイナミクスに貢献する部族的な概念を有効にしていることになります。
ファーストチームの考え方はパトリック・レンシオーニによって定義され、彼の多くの著作で言及されています。The AdvantageやThe Five Dysfunctions Of A Team: A Leadership Fableを含む彼の多くの著作で言及されています。これは通常、組織レポートではなく、主要な説明責任チームとしてクロスファンクショナルなリーダーシップチームの確立に関連して使用されますが、同じ概念が製品チームにも適用できます。
組織の行動を変えずに、組織の言葉遣いを単純に変えるだけでは、スケーリングの苦境に測定可能な影響を与えることはありません。それでも、それは始めるための簡単な場所であり、パフォーマンスの問題の根底にある組織の摩擦と、より大きな文化的な問題に対処します。
言葉遣いの変更
組織がサイロを解消するために積極的に関与するほど、組織がこれまで抱えていた暗黙の「対立」状態を効果的に解消できる可能性が高まります。
-- デュエナ・ブロムストロム
組織内で使用される言葉を積極的に見直すことは、障壁を打ち破り、摩擦を減らすための簡単な第一歩です。
- 組織の実務担当者グループを「チーム」以外の言葉（例えば、スクワッド、ポッド、または組織の文化に合った用語）で呼ぶことは、小さな変更ですが、大きな影響を与える可能性があります。
- 機能横断的な製品デリバリーチームに、理想的には製品名やバリューストリームの名前を付けることも、これらの多様な専門性を持つ人々が、組織の報告体制とは別の新しいチームとしてのアイデンティティを採用するのに役立つ簡単な変更です。
- プロフェッショナルな語彙から「私たち」と「彼ら」を削除しましょう。「あちらのグループ（このグループではない）」という同じ文脈を保ちながら、代替用語を考えることは、ごまかしです。私たちはプロフェッショナルな環境で、自分自身と言葉を常に吟味しており、この言葉は「使用禁止」リストに追加する必要があります。
行動を変える
組織の文化を変えようとしている私たちは、何をしたいのか、どのように行動したいのか、お互いにどのように行動してほしいのかを定義し、トレーニングを提供し、それらの行動を強化するために必要なことを行う必要があります。結果として文化は変わるでしょう。
-- ジョン・シュック
望ましい結果を生み出していない組織の文化を変えるのは難しいことです。このテーマについて多くの本が書かれています。チームとそのチームメンバーに期待される行動を事前に定義して伝えることで、あなたが創造しようとしている文化の根底にあるトーンを設定します。
- リーダーは、非難しない文化の原則と期待を設定する必要があります。何か問題が発生した場合、それは学習の絶好の機会であり、研究して継続的な改善に利用する必要があります。この例が、非難のないポストモーテムの概念です。
- 期待を設定し、望ましい行動の採用を定期的に検査します。チームメンバーにこれらの行動に対する責任を持たせ、例外を容認しないでください。
- 機能を軸とするのではなく、バリューストリームを中心に「チーム」を構成します。共通の価値を提供するグループとしての「チーム」と、製品管理や品質保証などの特定の能力を深めたり提供したりするために形成されることが多いコミュニティオブプラクティスまたはセンターオブエクセレンスを区別します。
- 性格タイプによっては相性の悪い人がいることを認識します。才能のある人々を配置転換して、最適なチームの相乗効果を見つけます。
スケールアップがどのように価値を提供するかを定義し、伝達する
会社は、多くの場合、組織の成功という1つの共有目標を持つ、1つの大きなチームに過ぎません。製品部門とエンジニアリング部門がその目標を共有していない場合、それを達成する方法について協力的な合意に達するのは困難です。この摩擦の発生源を回避するために、幹部は、組織が顧客、投資家、社会に提供する全体的な価値を明確に説明し、広める必要があります。リーダーは、ポートフォリオ内の各製品およびサービスが、その価値の提供にどのように貢献しているかを説明する責任があります。経営陣は、すべてのチームメンバーが、日々行っている仕事が組織とその顧客に価値を生み出していることを理解していることを保証する必要があります。
目標は、ビジネスがどのように価値を生み出すかという共有のメンタルモデルを作成することです。これを行うための最善の方法は、ビジネスの性質に大きく依存します。私たちは、特定の種類の資産が、スケールアップクライアント全体で一般的かつ有用であると考えています。
顧客とユーザーの価値を説明する資産
これらは、製品とサービスが作成する価値、誰のために作成するのか、およびその価値を測定する方法を説明する必要があります。例としては、以下のようなものがあります。
- ビジネスモデルキャンバス/リーンキャンバス
- ユーザーの旅
- サービスブループリント
- ペルソナ
- 共感マップ
- ストーリーボード
- ジョブフォースダイアグラム
- 製品概要（1ページものなど）
経済モデルを説明する資産
これらは、会社が顧客から受け取る価値、その価値を生み出すためのコスト、およびその価値を測定する方法を説明する必要があります。例としては、以下のようなものがあります。
- ビジネスフライホイール
- バリューストリームマップ
- ウォードリーマップ
- リテンション/チャーンモデル
- 顧客獲得モデル
- 顧客生涯価値モデル
- 予測貸借対照表および損益計算書
戦略を説明する資産
これらは、なぜこのような方法でこれらの顧客にサービスを提供することを選択したのか、その決定を下すために使用した証拠、そして作成する価値と見返りに受け取る価値を最大化するための最も効果的な方法を説明する必要があります。
- ターゲット顧客プロファイル
- イシューツリー
- インパクトマップ
- 機会/解決策ツリー
- 階層図
- 因果ループ図
- その他のオーダーメイドのフレームワークとモデル
これらの資産を入手したら、プレゼンテーション、会議、意思決定、そして最も重要なこととして、対立が発生したときに常に参照することが重要です。変更を加えた場合は、それらの変更を加えた理由を伝えます。組織からの更新を求めます。要するに、それらを通常の業務の一部にし、壁紙や別のオフィスの飾りにならないようにしてください。
このコミュニケーションがどれほど成功したかを理解するための簡単なヒューリスティックは、ランダムな個人貢献者を選び、これらの資産によって回答される質問に答えてもらうことです。彼らが資産を参照せずにこれを行うことができればできるほど、この考え方を自分の仕事に取り入れることができるようになります。彼らが資産の存在すら知らない場合は、まだ多くの作業を行う必要があります。
これらの資産がもたらす整合性と集中により、組織のリソースをより適切に展開でき、スケーリングが可能になります。さらに、製品部門とエンジニアリング部門間の自然な緊張を転換します。非生産的な対人関係の摩擦の代わりに、これらの資産の作成と更新を、真のコラボレーションと、会社を強化するアイデアについての健全な意見の相違の場として利用できます。
学際的なストリームアラインドチームを作る
会社が設立されたばかりの頃は、多くの場合、1つのバリューストリームしかありません。しかし、成長すると、製品とサービスを複数のバリューストリームに分割して、個々のチームがさまざまな製品または製品の一部を完全に所有できるようにする必要があります。この分解を行うための最善の方法は、この記事の範囲を超えています（個人的には、Team Topologiesをその方法を考える上で大変気に入っています）。ただし、考慮すべき重要な点は次のとおりです。
- このバリューストリームとその構成要素である製品とサービスは、別の会社として存在できるか（たとえそれが非常に成功する会社でなくても）？
- バリューストリームを、会社が価値を生み出す特定の方法、または会社が価値を生み出す特定の顧客またはユーザーに合わせることができますか？
- 異なるバリューストリームは互いにどのように相互作用しますか？
バリューストリームを定義したら、それらの周りに多様な専門知識を持つチームメンバーを集める時です。なぜなら、価値創造はチームスポーツだからです。これらのバリューストリームのリーダーに、上記で説明した資産の同様でありながらより詳細なバージョンを作成するように依頼し、バリューストリーム内の製品および/またはサービスの価値を最初から最後まで提供し、進化させるために日常的に必要なスキルと能力を決定します。
機能チームや活動指向チーム間で作業を調整するのではなく、これらの個人を成果指向のチームにまとめます。Sriram Narayamは、『Agile IT Organization Design』の中で、「プロセスと間接性が増えるほど、効果的なコラボレーションの摩擦が大きくなります。対照的に、チーム内の人々は、お互いにコラボレーションするための会議をスケジュールする必要はありません。彼らは継続的にコラボレーションし、オンデマンドで（非公式の、その場限りの会議—仮想または対面）集まります。」と述べています。このモデルは、成果指向のチーム内のレイテンシを削減するのに役立ちますが、多分野にわたるチームメンバー間の摩擦も軽減します。
会社の成長に伴い、1つのバリューストリームを中心に複数のチームが配置され、そのバリューストリームを担当する機能横断的なリーダーのチームも必要になる可能性があることに留意してください。価値創造の複雑さが増すにつれて、製品デリバリーチーム全体で共通の目的を維持することの重要性も高まります。
プロダクトマネージャーとソフトウェアエンジニアは、顧客のニーズを理解し、作業を定義して優先順位を付けるという共通の責任を負っています。製品担当者とエンジニアの理想的な組み合わせはありません。製品によって割合は異なります。重要なのは、両方が価値の理解、優先順位付け、作成を担当していることを知ることです。
製品が進化するにつれて、チームのニーズも進化します。チームの能力を定期的に棚卸しし、ストリームに沿ったチームが独自のニーズを主張できるようにします。チームが、外部リソースへの不必要な依存なしに効率的に提供するためのスタッフ、スキル、情報、および権限を十分に備えていることを確認します。完全にリソースが提供され、権限が与えられ、自律的な製品チームが、各個人の報告体制に関係なく、単一のエンティティとして運用することで、分野間の摩擦を劇的に削減します。
すべてのレベルでチームの作業合意を確立する
すべてのチームメンバーが自分の役割を理解していることを確認します。
最高のチームは、自分たちにとって最適な働き方を交渉したチームです。組織が、チームとして効果的に働く方法について、経験の浅いチームを導くための賢明なデフォルトを確立することが重要です。確立されたデフォルトがある場合でも、どのメンバーがどの責任を負うかを決定するチームの自律性が重要です。この自律性の尺度は、説明責任の向上とより高いレベルの内発的動機につながります。新しいチームが形成されたら、この作業合意をチームの共通の知識リポジトリに体系化します。振り返りの際に、チームが各チームメンバーの強みと弱みについて詳しく学び、それに応じて責任を再割り当てする際に、このチームの作業合意を見直します。このチームの作業合意は、チームの社会契約であるとともに、他のチームにはない独自の「責任の指紋」にもなります。新しいチームメンバーがチームに参加したり、チームをローテーションしたりする場合、参照可能なチームの作業合意を持つことで、統合が加速され、オンボーディング中の価値実現までの時間が短縮されます。
チームの作業合意には、以下が含まれることがよくあります。
- チーム名：チームの一意の識別子は何ですか？
- チームミッション：この特定のチームが存在する理由は？どのような価値を提供することが期待されていますか？
- チームメトリクス：チームはどのように成功を測定しますか？活動メトリクスだけでなく、価値創造メトリクスを含めます。
- チームの責任：成功を確実にするためにどのような作業を行う必要があり、どのチームメンバーがそれらの作業項目を所有することに同意していますか？組織は、チームの責任配分の一般的な活動と推奨事項でこの作業を開始できますが、チームメンバーは自由に相互に再交渉できます。
- チームスキル：成功を確実にするために、この特定のチームに必要なスキルは何ですか？
- チーム規範：チームメンバーがどのように行動し、交流し、意思決定することが期待されているかについて、チームメンバーが合意するためのガイドライン、原則、儀式、および/または賢明なデフォルト。
バランスの取れた製品投資ミックスを交渉する
上の図は、技術投資と製品投資のバランスが取れた最適点を示しています。製品機能に偏ったバックログに過剰に投資すると、技術的負債やランウェイへの投資不足を示唆している可能性があり、エンジニアリングが不十分なソリューションにつながります。一方、技術に偏ったバックログに過剰に投資すると、顧客価値のある機能への投資不足と過剰なエンジニアリングソリューションを示す可能性があります。バランスが完璧な状態を把握するのは非常に困難です。企業の成長やピボットに伴い、そのバランスは時とともに変化する可能性があります。
よく見られるエンジニアリング不足の例としては、製品の可用性に問題がある場合です。この問題が発生すると、開発チームは問題解決に時間を費やさなければならず、集中力が低下し、生産性に影響が出ます。小規模なうちは耐えられても、顧客の使用量が急増した場合（ハイパーグロース時）、チームは過負荷になり、顧客体験に影響が出ます。この負債の返済は、ビジネスが最も余裕のない時に必ずやってきます。
技術チームが早期の最適化をやりすぎると、過剰なエンジニアリングになるという別の不均衡も生じます。その例としては、会社に10人しかユーザーがいないのに、何十万人ものユーザーに対応できるように構築された、過度に適合されたアーキテクチャなどがあります。スタートアップがピボットした場合、その作業の多くは無駄になります。将来の拡張性を考慮して製品を構築することと、生き残るために今必要なものを構築することの間には、常にバランスが必要です。
重要なのは、この配分の不均衡に気づき、それを修正できることです。継続的な改善プロセスは非常に重要です。チーム（製品チームレベルまたは管理チーム）が共有目標を認識していれば、部門横断的なグループが定期的にバランスを評価し、データを指針として活用することができます。データには定量的なものと、より主観的なものがあります。指針として利用できる情報には、以下のようなものがあります。
- 個人の意見の収集 - エンジニアは生産的で意欲的だと感じているか？ プロダクトマネージャーはチームが効率的だと考えているか？
- 生産性指標 - 新しい機能をテストして構築するのにどれくらいの速さが必要か？
- 現状と近い将来の状況の把握 - 将来のスケーラビリティのために、構築を複雑にしすぎていないか？
- 製品の成長 - 製品の目標に向かってどのように進捗しているかを把握しているか？ 製品への投資が成果を上げていることを確認するために、十分な分析、ユーザーテスト、顧客フィードバックがあるか？
- トレンド - 機能を追加したり、ユーザーを増やしたりするにつれて、指標はどのように推移しているか？ たとえば、ビルド時間、本番環境へのデプロイまでのリードタイム、インシデントの量などの指標を見てください。複雑さが増すにつれて、技術投資によってそれらを制御下に置き、開発者の苦労を軽減する必要があります。
技術プラットフォームを拡張した経験豊富な技術者は非常に貴重です。彼らはデータに基づいて、直感を働かせて将来起こりうる問題を特定し、実用的な観点から問題を捉えることができます。
部門横断的な要件を考慮する
優れた製品とは、最新の機能を備えた製品だけではありません。
- パフォーマンスが高く、信頼性があり、安定しているように構築する必要があります。
- コスト効率がよくなければなりません。製品の運営コストが、製品が生み出す収益を超えてはなりません。
- 製品の基礎となるアーキテクチャは、将来の機能開発が迅速かつ効率的に行われるようにする必要があります。
- クライアントの拡大を念頭に置き、あまり手直しすることなく拡張できる必要があります。
- 顧客やビジネスの機密データを危険にさらしてはなりません。
製品のこれらの品質やその他の多くの品質は、部門横断的な要件の範疇に入ります。新しい機能をリリースすることに関心を寄せ、これらの要件を考慮しないと、複合的な問題が発生します。
顧客が不満を言ったときに気づくことができるため、より明白な問題もあります。長期的にしか気づかない問題もあります。マーティン・ファウラーは、内部品質を高く保つことの重要性について語っています。リファクタリングを行い、自動テストを作成し、アーキテクチャを分離することです。初期段階の企業は、短期的な生産性向上のためにこれを省略する傾向があります。これは正しい決断かもしれませんが、チームを増やすことを考えるようになったら、内部品質に対処する必要があり、そうしなければ長期的な価値創造が失われてしまいます。
バックログのバランス調整
バランスの取れたバックログの作成は、信頼から始まります。それは、本質的に製品とエンジニアリング間の交渉だからです。私たちは、すべてのプロダクトリーダーが、技術面の対応者と緊密で協力的な関係を築くことを推奨します。バランスを見つけようとする中で、多くの困難な議論が行われるはずです。スタートアップは非常に限られたリソースしか持っておらず、開発者のエクスペリエンスの向上と新しい機能の構築の間で、しばしば難しいトレードオフを強いられます。
生産的な交渉は、透明性、詳細な情報を共有する能力、そして相手の視点から状況を理解したいという欲求に左右されます。プロダクトマネージャーが技術アーキテクチャと戦略を理解していれば、構築しやすいアイデアを提案できます。技術者が製品戦略の背後にある理由と調査を理解していれば、プロダクト担当者が思いつかなかった別のソリューションを提案できます。たとえば、ML/AI を活用して問題を解決することなどです。
バックログを交渉する際、スタートアップは潜在的な投資間の相対的な影響を理解するのが難しいことがよくあります。そして、使用量と収益の指標は取得しやすく、よく理解されているため、それらに影響を与える作業が優先されがちで、投資配分のバランスが崩れます。この影響を打ち消すために、技術投資の影響を測定できる指標を見つけることを推奨します。状況はそれぞれ異なりますが、長期的な生産性を向上させることが示されている、数多くの研究に裏付けられた事実上の標準を、開始点として利用できます。
成長に伴うプロダクトとエンジニアリングのコラボレーションアプローチ
フェーズ1
実験
スタートアップ自体が1つのチームです。
ミッションステートメントを記述するための暫定的なワーキングアグリーメントとアセット。
投資配分は、製品投資に大きく偏っています。多くの場合、実際に使える製品ではなく、知識を向上させるために（使い捨てのプロトタイプなど）構築します。
さまざまな経済モデルを実験します。
フェーズ2
牽引力の獲得
会社はサブチームに分かれ始めますが、依然として「1つの大きなチーム」とみなしています。
ワーキングアグリーメントがより具体的になります。
顧客価値アセットが洗練され、オンボーディングとオリエンテーションで使用されます。経済モデルは明確になりますが、依然として柔軟性があります。
最初の非創業者プロダクトおよびエンジニアリングリーダーを雇います。
投資配分は依然として製品志向が強く、耐久性のある製品の作成に重点を置いています。スケーリングをサポートするための主要な基盤投資。
フェーズ3
（ハイパー）グロース
「1つの大きなチーム」として運営するには大きすぎるため、ストリーム指向チームに分解されます。
中間管理職向けに、部門横断的なリーダーチームが作成されます。最初のプラットフォームエンジニアリングチームが作成されます。
新しい市場を探すのをやめます。投資配分は、製品が生み出す価値に重点を置きます。
顧客価値、ビジネス戦略、経済モデルのアセットは非常に具体的になり、変更は非常に遅く、配布用に設計されています。
各製品およびサブ製品は、必要に応じて独自の価値ステートメントとアセットを作成します。
フェーズ4
最適化
リーダーは、機能ラインに沿ってサイロ化しないように積極的に取り組む必要があります。
最大限の自律性と自主性を最適化するために、チーム構造が変化し始めます。
スキル開発と機能グループ間の一貫性をサポートする構造が出現します。
ストリーム指向チームでの作業をより効率的にするために、複数のチーム（プラットフォームエンジニアリング、製品運用、設計運用など）が作成されます。
コア製品への投資配分は、開発者のエクスペリエンスへの投資を含め、技術投資に重点を置くようになります。
