プロダクト志向のチームを目指して！今日から始める「7つの習慣」
「プロダクト志向のチーム」とは、チームメンバー全員がプロダクトのことを愛し、プロダクトの成功に向けて、組織の垣根を超えて、全力でチャレンジできるチームのことです。この記事では、そんなチームを作り、そうあり続けるために、今日から始められる方法を「7つの習慣」として紹介します。
なお、この記事ではプロダクトの開発・運用に必要な機能型の部署に、横串を通すようにして構成されたチームを「プロダクトチーム」と呼びます。
プロダクト志向のチームになる
こんにちは。株式会社Mobility Technologies（以下、MoT）で、タクシーアプリ『GO』の法人向けサービス『GO BUSINESS』のプロダクトマネージャー（以下、PdM）を担当しております。Tannyです。
みなさんは、自分が担当しているプロダクトについてどう思っているでしょうか？「これが自分の担当しているプロダクトです！」といって、周囲の人にその魅力を宣伝して回りたくなるでしょうか？また、他の部署の人との関係性はどうでしょうか。プロダクトを通じて実現したいことがあるとき、他部署のメンバーと協力して、全力で取り組むことができるでしょうか？
「プロダクト志向のチーム」とは、これらが実践できるチームです。プロダクトを成功させるために、全てのチームが目指すべき姿ですね。プロダクトマネジメントについて書かれた『プロダクトマネジメントのすべて』では、以下のように紹介されています。
プロダクトを成功させるチームは、プロダクト志向のチームである。（中略）電車の中で見ず知らずの人が自分たちの手がけるプロダクトを使っていると喜び、知人が競合のプロダクトを使っていると悲しむ。日々の生活の中で、自社のプロダクトを使ってもらうためにはどうすれば良いか考え、その考えをチーム内で議論してプロダクトに反映することができる。
しかしながら、全てのチームが必ずしもプロダクト志向の状態ではないと思います。
……それは、なぜでしょうか？
私たちは毎日、山ほどの仕事に追われており、目の前の仕事を片付けるのに手一杯です。それを続けていると、個々の仕事の「成果物（アウトプット）」に注力するようになってしまい、仕事がもたらす「結果（アウトカム）」を気にしなくなってしまいます。ひたすら仕事をしているだけで、自然と「プロダクト志向でないチーム」になっていきます。
今の職場で業務を進める中で、このサイクルを抜け出し、チームがプロダクト志向であり続けるための「習慣」があると考えるようになりました。この記事では、その習慣から特に重要なものを選び、「7つの習慣」として紹介します。（あの有名な書籍の「7つの習慣」とは特に関連性はないです🙏 単に７つだとカッコいいというだけです。）
どのような職場でも具体的な行動に移せるように、MoTで実践している具体例と、今日からでも始められる小さな活動も記載しています。この記事を読んだ皆さまが、自分のチームを少しでも良くする方法を見つけられると幸いです。
プロダクト志向のチームになるための7つの習慣
ビジョンを描く
課題にフォーカスする
KPIを頻繁に測定する
ユーザーの声を聴く
情報を可視化する
失敗を許容する
記念日をお祝いする
1. ビジョンを描く
今日から始める習慣
プロダクトを通じて達成したいビジョンを描き、チームメンバー全員で共有しましょう。
ビジョンとは
ビジョンとは、「プロダクトを通じて誰をどのような状態にしたいのか」という世界観のことです。ビジョンを実現するために、プロダクトは存在しています。優れたプロダクトは優れたビジョンを掲げており、ビジョンの達成を目指すことでプロダクトを成長させています。
例えば、noteは以下のようなビジョンを掲げています。noteを使っていると、このビジョンを実現するための機能構成になっていることに気づきます。
noteがあることで、人々は本当に伝えたいことに専念できるようになる。
まずは、自分が運用を担当しているプロダクト、またはこれから開発するプロダクトが目指すビジョンを描きましょう。すでにビジョンがある場合は、それをもう一度読み直してみます。明確なビジョンがなく、メンバーの認識もバラバラな場合は、ビジョンを整理し直してみましょう。
ビジョンステートメント
ビジョンというと、noteの例のように、短い文章で研ぎ澄まされた、洗練されたものを考えなければいけないと思うかもしれません。外部の人に端的に訴えかけるように伝えるためには、そのような方法も効果的です。しかし、チーム内でビジョンを整理し、共有する場合は、もう少し簡単な方法でも大丈夫です。
ビジョンの重要性について書かれた書籍『ラディカル・プロダクト・シンキング』では、以下のような「ビジョンステートメント」のフォーマットが紹介されています。まずはチームの担当プロダクトのビジョンについて、このフォーマットに当てはめて考えてみましょう。
ビジョンステートメントのフォーマット
現在 [特定のグループ] が [望ましい結果] を望むとき、
彼・彼女らは [現状の解決策] しなければならない。
この状況は [現行解決策の欠点] のため、受け入れられない。
我々は [欠点の克服された] 世界を夢見ている。
我々は [テクノロジー/アプローチ] を通じて、
そのような世界を実現するつもりである。
このフォーマットでは、対象とするユーザー層、解決すべき課題、目指すべき未来像、それを実現するための方法、について整理します。長めの文章ですが、ビジョンに必要な要素をもれなく整理できます。
ビジョンを共有する
整理したビジョンはチームメンバー全員で共有します。メンバーはビジョンの達成を目指して日々の仕事を行います。これにより、部署の壁を越えて、プロダクトの成長に向かって活動できるようになります。なぜならこの時、部署は役割の違いであって、目指すビジョンは1つだからです。
また、チームを拡大するために、ビジョンを外部に発信し、ビジョンに共感した新メンバーを集めるということも重要です。MoTでは、採用面接の各フェーズにおいて、ミッション・ビジョンを繰り返し伝えています。そして、そのビジョンに共感し、ビジョンの実現に寄与したいと考えるメンバーに参画してもらっています。
私も途中までは「MoT = タクシーアプリ『GO』の会社」というイメージを持っていましたが、最終面接で社長の中島さんとお話させてもらった後は、社名そのままに「モビリティをテクノロジーで変えていく会社」であり、ミッション・ビジョンを本気で目指しているんだなと思えました。
より引用
チームが発足して間もない場合や、チームメンバーが少ない場合は、あえてビジョンステートメントの形にして共有しなくても、暗黙の了解としてビジョンが浸透していることが多いです。しかし、事業が拡大して、チームの規模も大きくなってくると、ビジョンが浸透しづらくなってきます。その時が、ビジョンステートメントとして書き出して、ビジョンを共有し直すタイミングです。
まずはしっかりとしたビジョンを描き、適切な方法でチームメンバー全員に共有しましょう。ビジョンを共有できていれば、困難が生じても、目指すべき方向を見失わずにチームで活動することができます。
2. 課題にフォーカスする
今日から始める習慣
「何を作るか」ではなく「どんな課題を解決するか」ということにフォーカスしましょう。
私たちは、課題を解決してビジョンを達成することを目指しています。なので、「これから何を作るか」とか「今日はどんな作業をするか」ではなく、「どんな課題を解決するか」ということをいつも考えましょう。
課題にフォーカスするメリット
ユーザーからの要望は通常、「〇〇という機能が欲しい」といった形で受け取ります。しかし、ユーザーはプロダクト開発のプロではなく、本当に必要な機能をうまく言語化できるわけではありません。そのため、言われた機能をそのまま作っても、ユーザーの課題を解決できないことがよくあります。なので、この要望をそのまま受け取るのではなく、その裏にはどんな課題があるのか、深堀りしましょう。
課題にフォーカスすることで、具体的な「困っているユーザー像」をイメージできます。また、その課題の緊急度や発生頻度にも目を向けることになります。これらの情報をチームメンバー内で共有することで、課題を解決しなければならないという使命感が生まれ、一致団結して課題解決に取り組むことができます。
なぜなぜを繰り返す
ユーザーの要望から課題を特定するために、「なぜなぜ分析」（Wikipedia）という方法が使えます。これはもともと、発生した問題に対して「なぜ」という問いを繰り返し、問題の真因を究明する方法です。これを、解決したい課題を特定する方法として応用します。
ユーザーからの要望に対して、課題が明確でないと感じた場合は、課題を特定できるまで「なぜ」を繰り返してみましょう。ユーザーに直接聞くのが理想ですが、要望を受け取った営業チームやCSチームに聞いてみるのもOKです。
例えば、何らかのプロダクトで「CSV出力機能が欲しい」という要望を受け取った時のやりとりは以下のようになります。
なぜなぜを繰り返したことにより、「アプリの利用状況を（外部システムで）可視化したい」という課題が明らかになりました。この場合、CSV出力以外にも、外部システム連携や、可視化の機能自体をプロダクトに実装するなど、色々な対応が考えられます。
また、「どんな利用状況を可視化したいのか」とか「同じような課題を持っているユーザーはどれだけ居るのか」といった問いにもつなげることができます。このケースだと、結果的にCSV出力機能を開発する場合もあります。しかし、課題を明確にしたことで、機能開発の必要性や、その機能がもたらすべき結果が明確になりました。
チーム内でも課題にフォーカスする
課題にフォーカスするということは、チームの部署内外で仕事をやりとりする際も重要です。
チーム内で仕事を依頼するときは、必要な成果物だけでなく、その背景や解決したい課題も合わせて伝えるようにします。逆に、仕事を受けるときにその課題が明確でない場合は、聞き返すようにします。アウトプットのイメージがずれるのも防げますし、そもそも仕事自体が必要なかった、ということに気づけることもあります。そうすることで、ビジョンの実現に向けて、ムダなく仕事を進められます。
これを習慣化するためには、仕事依頼用のフォームなどを作り、解決したい課題の記載を必須化することも有効です。
その課題も記載してもらうようにする。
成果物ではなく解決したい課題にフォーカスすることで、程よい使命感が生まれます。その結果、部署の連帯感をより強くして、課題の解決に取り組むことができるようになります。
3. KPIを頻繁に測定する
今日から始める習慣
KPIを毎週・毎日といった細かい頻度で測定し、チーム内でKPIの変動について議論しましょう。
KPI（Key Performance Indicator）は、ビジョンの達成度（=プロダクトの成功度）を把握するための指標です。どんなチームでも何らかのKPIを定義していると思いますが、これをどんな頻度で測定し、閲覧しているでしょうか。毎月や四半期ごとの集計結果の報告資料を作っている、または報告を受けているだけでしょうか？
KPI測定のメリット
KPIは長くとも毎週、できれば毎日（場合によっては1時間単位で）確認するようにします。BIツールの集計結果がSlackに毎日投稿されているようなら、それをチェックすることを習慣付けます。そういった仕組みがない場合は、データベースから取得した値を手動でSlackにコメント投稿することから始めても良いです。
1日単位の頻度でKPIをチェックすることで、どのような要因でKPIが変化するのかを予測することができるようになります。「雨が降ったので利用が減った」「広告を打ったので利用が増えた」「新機能を出したので問い合わせ件数が増えた」といった具合です。
こうすることで、自分達の活動の成果が、ユーザーにどのように影響しているかをイメージできるようになります。プロダクトがユーザーの課題を解決できているかどうかもわかります。
思うようにKPIが変化しない部分は新たな課題の種として、どんな原因があるのか議論するきっかけとなります。機能のリリースによって、思った通りにKPIが伸びた場合は、チームの成果としてお祝いしましょう。
KPI測定の仕組みづくり
このように、KPIはプロダクトが成功に向かっているかを検証するための重要な情報となります。MoTでは、データ分析の専門部署があり、KPIの分析をサポートしています。開発の初期段階からチームに参加し、測定すべきKPIの検討や、測定機能の実装を行なっています。
MoTにおけるデータ分析の取り組みは、以下の記事で紹介しています。
専門のデータ分析部署がない場合でも、まずはどんなKPIを測定すべきかの議論から始めてみましょう。それが分かれば、DBからデータを抽出して可視化するようなシンプルな方法でもKPIを測定できます。
なお、適切なKPIを選定する方法については、以下の記事がとても参考になりますので、ぜひご覧ください。
KPIを測定していないと、プロダクトがもたらす効果から目を背けて、「どんな成果物を納品したか」「予定通りにリリースできたか」といったアウトプットばかりに注目してしまうようになってしまいます。また、KPIをたまにしか測定しない場合、効果の確認が遅れてしまうことになります。適切なKPIを設定し、頻繁に測定することで、プロダクトがユーザーの課題を解決しているかどうかをタイムリーに把握しましょう。
4. ユーザーの声を聴く
今日から始める習慣
ユーザーひとりひとりの声を聴き、ときには自分自身がユーザーとなって、プロダクトの現状を具体的に理解しましょう。
KPIを頻繁に測定することで、プロダクトの現状をある程度理解できるようになります。ただし、KPIを見ているだけではその因果関係や個々のユーザーへの影響までを理解することはできません。KPIは「平均値」「合計値」などの統計的な指標であり、ユーザー個人の行動を直接反映しているわけではないからです。
なぜ、いまのKPIが得られているのか、いま具体的にはどんな課題が存在しているのかを正しく理解するためには、ユーザーヒアリング等を実施し、現地現物で具体的なユーザー像を理解することが重要です。
ユーザーの声を聴く方法
ユーザーの声を聴くためには、以下のような方法があります。方法によって、得られるフィードバックの傾向が変わるので、いろいろな方法を試してみましょう。
ユーザーインタビューを実施する。
ユーザーアンケートを実施する。
Twitterでエゴサする。
アプリストアのレビューを収集する。
お問い合わせ窓口の対応履歴を収集する。
営業チームの商談結果を聴く。
MoTにおいても、いろいろな方法でユーザーの声を聴いています。例えば、専門のリサーチャーが定期的なユーザーインタビューやアンケートを実施しています。その結果はチームメンバーに随時共有され、今後の開発施策の検討に活かしています。
ユーザーインタビューでは、個々のユーザーがプロダクトを認知し、使い続けるようになるまでの過程を詳細に把握できるため、ユーザーへの理解度が格段に高まります。
また、アプリ開発チームの発案により、アプリストアのレビューを収集し、内容を分析することも行なっています。アプリストアには不具合報告や改善要望が投稿されるケースが多く、潜在的な課題を幅広く集められます。
さらに、お問い合わせ窓口へのお電話を生で聴くことができる「CX体験会」も開催されています。不具合に遭遇してしまい、非常にお困りされている様子を直接聴くため、課題に対する温度感の高さを深く理解することができます。
自分たちがユーザーになる
「これらの方法をいますぐ始めるのは難しい」という場合は、まずはチームのメンバーでプロダクトを触ることから始めましょう。自らがユーザーとなってプロダクトを利用し、感じたことを書き出してみます。仕事で毎日向き合っているはずのプロダクトであっても、実際にユーザー目線で使ってみることは意外と少ないのではないでしょうか。社内で使うインナーツールなども含めて、チームで扱っているすべてのプロダクトを触ってみると、非常に多くの発見があるはずです。
MoTでは「トライアルタクシー制度」があり、月額1万円までのタクシー利用料が補助されます。これにより、タクシーの利用体験に関する社員からの声が、たくさん集まっています。
あらゆる方法を通じてユーザーの声を聴き、プロダクトが置かれている現状や、課題感を正しく理解しましょう。これにより、ビジョンを達成するために、誰の、どのような課題を解決していくべきかをチームで議論できるようになります。また、ユーザーからの感謝の声を聴くことで、チームメンバーがプロダクトを愛せるようになっていきます。
補足
ここまでの習慣を正しく実施していると、プロダクトが「解決しなければならない課題で溢れている」という状態になる可能性が高いです。とはいえ、開発できるリソースには限りがあります。ここでPdMが課題の優先順位付けを実施して、どこから着手すべきか、何を実施しないかを決断することになります。
5. 情報を共有する
今日から始める習慣
プロダクトに関する情報を後から見直せる形で保存し、チームメンバー全員で共有しましょう。
ここまでの活動により、ビジョン・課題・KPI・ユーザーボイスなどの、プロダクトに関するたくさんの情報が集まってきました。これらの情報は、ドキュメント・画像・動画・音声ファイルなどの形式で保存し、チームメンバー全員で閲覧できるように公開しましょう。
部署の壁をなくす
通常のチームにおいては、「情報は自部署内で保持していて、許可された一部の情報を他部署に共有する」という運用も見られます。これでは、課題を解決するためのスピードが落ちてしまいます。そうではなくて、ごく一部の非公開情報（個人情報や機密情報など）を除いて、「すべての情報を共有する」ということを基本としましょう。
現在はビジネスの場でクラウドサービスを利用することが一般化しているため、情報の共有は非常に簡単です。情報はクラウドサービスに保存して、公開範囲を全社に設定するだけです。
上記の例のように、他のプロダクトチームの情報も閲覧できるようにしておくことが理想です。他プロダクトの課題を知り、自分のプロダクトでサポートすることもできるためです。
すべての部署が同じビジョンと同じ情報を共有している状態であれば、いわゆる「部署の壁」を感じることなく、仕事ができるようになります。各メンバーは、必要な情報をスムーズに取得しながら、自部署の役割を果たしてビジョンを実現することに集中できます。
同期コミュニケーションで情報を共有する
このような形で情報を共有すると、各メンバーがアクセスできる情報が倍増することになります。そのため各メンバーの情報の理解度に差が出てしまう可能性があります。この課題に対しては、同期コミュニケーション（リアルタイムで行われるコミュニケーション）を活用しましょう。例えば、KPIの振り返り会を定期的に実施することで、どのKPIを見ておくべきか、チーム内での認識が一致します。
MoTでは、週次のオンライン全社ミーティングで、経営情報や各プロダクトのKPIなどの情報が、全社員に向けて共有されています。「全員が確実に知っている情報」が増えることで、プロダクトチームや部署の枠を超えて、同じ目線で仕事をすることができます。
また、「日帰りワーケーション」の施策では、普段の業務では直接関わりのないメンバーと直接対話できるため、他のプロダクトや部署が持っているビジョンや課題感への理解が深まります。
私たちは、今持っている情報の範囲内でしか仕事ができません。情報を共有し、より多くの視点を持つことで、それぞれの仕事の範囲を広げることができます。自分だけ、または自分の部署だけが持っている情報があるなら、まずはそれをチーム内で共有することから始めましょう。
6. 失敗を許容する
今日から始める習慣
新しいことを始めると、必ず失敗が発生します。失敗を受け入れ、検証し、次の改善につなげましょう。
ここまでの活動を通じて、解決すべき課題を特定できたら、新機能を開発してリリースします。しかし、思ったようにユーザーの課題を解決できていなかった、というケースも多いです。開発からリリースまでのプロセスにおいて、いくつかの作業ミスも発生します。これは、誰か特定の人が悪いからではありません。プロダクトチームは世の中の複雑な課題を解こうとしていますし、世にない新しい機能をリリースしていくことになるので、いろいろな失敗が発生するのは自然なことです。（逆に、何も失敗していないと、何か見逃しがないか不安になりますよね）
失敗に対処する心構え
プロダクト志向のチームにおいては、失敗が発生しても誰か特定の個人や部署が非難されることはありません。そのため、ユーザーに影響を与えるような失敗が発生した場合は、まずチームメンバー全員に共有し、メンバーはそれぞれの役割の中で、全力で失敗に対処します。対応が完了した後で、なぜ失敗が発生したのかを検証し、それぞれの部署が実施できる改善対策を行います。
失敗のメカニズムについて科学的に分析した『失敗の科学』においては、失敗から学習できる組織文化について以下のように説明しています。
何かミスが起こった時に、「担当者の不注意だ！」「怠慢だ！」と真っ先に非難が始まる環境では、誰でも失敗を隠したくなる。しかし、もし「失敗は学習のチャンス」ととらえる組織文化が根付いていれば、避難よりもまず、何が起こったのかを詳しく調査しようという意思が働くだろう。
プロダクトに新しい機能を追加したり、チームの業務プロセスを変更したりすると、同時に失敗の可能性が生まれます。なので、「この新機能リリースで新しい問題が発生したらどうしよう」と不安になることもあります。しかし、自分達のチームは過去の失敗から学んで成長してきており、もし新たに失敗しても非難されることがないという状況下であれば、安心して業務を進められます。
失敗に向き合うための方法
失敗に向き合うためのお手軽な方法としては、「KPTによる振り返り」があります。スクラム開発の振り返りでよく使われるフレームワークで、「Keep： 良かったこと、Problem： 悪かったこと、Try：次に実施する改善」の観点で振り返り結果を書き出します。
この中の「Problem」が「小さな失敗の可視化」です。振り返りにおいては、Problemをチームメンバー全員で共有して、なぜ発生したか、解決するにはどうすべきかを話し合い、改善できるものはTryとして次に取り組みます。日々の業務で発生している小さな失敗を定期的に可視化して対処することで、大きな失敗が発生することを防いでいます。
どれだけ理想的なチームであっても、必ず失敗は発生します。大切なことは、その失敗への対象方法です。積極的にチャレンジしてビジョンの達成に貢献できるチームになるために、まずは失敗を許容する意識づけから始めましょう。
7. 記念日をお祝いする
今日から始める習慣
プロダクトの周年記念や、目標の達成記念などの記念日をお祝いし、これまでの歩みと、ビジョンの達成状況を振り返りましょう。
みなさんが担当しているプロダクトがxx周年を迎えた時、どのように感じたでしょうか？「こんなにたくさんのことを達成できたぞ🥳」という達成感でしょうか？それとも、「バタバタしているうちに、もう1年も経ったのか…😞」という徒労感でしょうか？
継続性をお祝いする
現代の、変化が激しい状況においては、プロダクトや会社や部署を1年間存続させるだけでも大変なことです。また、これだけの期間があれば、たくさんのことを達成できているはずです。
なので、このような節目においては、プロダクトの継続をお祝いしましょう。この中では、プロダクトチームがこの1年間でどのような機能をリリースし、ビジョンに近づけてきたかを振り返ります。また、最終的なビジョンを達成するために、次の1年間で何を実施すべきかを改めて整理し、チームメンバー全員で共有しましょう。
お祝いは懇親会として大々的に実施しても良いですし、ちょっとした振り返りミーティングを設定しても良いと思います。チームで実施しやすい形式を検討するのをおすすめします。大切なことは、チームの一部のメンバーや部署だけを中心として実施するのではなく、チーム全員が主体となって実施することです。
引用元：https://note.com/nogmot/n/n64fd0bb0dd2f
MoTでは、主力のGO事業の周年記念や、半期に1度の全社会を実施しています。これらの会は、さまざまな部署から集まった有志のスタッフで運営されていて、私もスタッフとして何度か参加しています。部署の垣根を超えて、同じビジョンを目指して活動しているということを改めて実感することができました。
前回の全社会の様子は、以下の記事にまとめてあります。ぜひご覧ください！
案件の振り返り会を行う
周年記念はもう少し先、という場合は、今日から実践できる方法として、「リリースした案件の振り返り会」をおすすめします。新規案件や改善案件のリリース後に、測定したKPIをチームのみんなで振り返りましょう。
比較的短期間で成果が出る案件であれば1週間ごと、そうでなければ1ヶ月ごと、というように振り返りの機会を設けておきます。思った通りの成果が出ているようであれば、ビジョンに近づけたことをメンバーみんなでお祝いしましょう。Slackで「いいね👍」リアクションを押すだけでも良いです。もしそうでなければ、ビジョンの達成に向けて、次に何ができるかみんなで考えます。
私が所属している開発チームでは、過去にリリースした案件のKPIを、Slackのチャンネルに自動投稿しています。このKPIを長くとも1ヶ月ごとに振り返るようにしています。こうすることで、自分達の仕事の結果がどのようにユーザーに影響しているかを意識しながら、日々の業務を進めることができるようになります。
プロダクトの開発から年月がたち、事業が加速すればするほど、目の前の業務に没頭するようになり、ビジョンの達成という重要な目的を忘れやすくなります。そうならないために、定期的に記念日をお祝いする習慣を設けて、自分達の成果を振り返りましょう。そうすれば、ずっとプロダクト志向のチームであり続けられるはずです。
おわりに
この記事では、自らのプロダクトを愛し、ビジョンの達成に向けて尽力できるチームを「プロダクト志向のチーム」と定義し、そのようなチームになるための方法についてまとめました。
自分が仕事をするなら、プロダクト志向のチームの方が絶対に良いはずです。しかしながら、必ずしも全てのチームがそうなってはいないと思っています。
……その違いはどこにあるのでしょうか？
企業の規模の違いなのか？スタートアップならできるのか？従業員の能力の差なのか？プロダクトの開発手法の違いなのか？だとすると今すぐに変わるのは難しいのか？
いろいろと考えられる要因はあります。しかし、今回挙げたように、プロダクトへの向き合い方を少し変えるだけで、どんな状況下のチームでも、プロダクト志向のチームになれると考えています。
今回は、どんなチームでも今すぐに実践できる方法をまとめ、「7つの習慣」として紹介しました。私が所属したMoTは、これらの習慣が徹底され、組織文化として浸透している、「超プロダクト志向のチーム」であると感じています。だからこそ、プロダクトを通じて、世の中の課題をタイムリーに、強力に、継続的に、解決していけるのだと思います。
補足
プロダクトを成功させるためには、そのプロダクトをユーザーに気に入ってもらい、かつ事業収支も成立させる必要があります。ですので、ここに書いたことを実践してプロダクト志向のチームになれても、プロダクトを簡単に成功に導ける訳ではありません。でもプロダクト志向のチームであれば、その困難さをやりがいに変えながら、成功に向かって突き進むことができるのです。