* プリファレンス管理は優れた通知インフラストラクチャの不可欠な部分であり、Courier では非常に重要なパズルのピースとなっています。これはまた、プロジェクトのインターンである Denis Tatar に多くの学習と経験を積む機会があったことを意味します。 Denis のインターンシップはわずか数か月でしたが、Courier の設定機能のプロダクト マネージャーとして大きな影響を与えることができました。

Denis の経験についてもっと知りたいと思ったので、私たちのために記事を書いてくれるかどうか尋ねました。それから彼が思いついたものがとても良かったので、皆さんと共有するのは良い考えだと思いました!この投稿では、Preferences プロジェクトの計画から実行までの Denis のワークフローと、Courier チームとの具体的な作業経験について説明します。ここからはデニスに任せましょう！

なにが問題だったの？

Courier で経験した問題は、Preferences (V3) を顧客に提供することでしたが、製品機能全体の戦略が完全に具体化されていませんでした。 V3 は V4 への大きな足がかりだったと思いますが、基本的にその戦略の特定の部分に欠陥がありました。グローバルなオプトイン/アウトのみを許可することは、この例です。もう 1 つの問題は、V3 があまり牽引力を獲得できなかったことです。これは、十分に考え抜かれた戦略の欠如を示していると思います。

5 月の設定 (V3) では、ユーザーが選択した設定をグローバルにオプトインおよびオプトアウトすることのみが許可されます。環境設定の V3 では、お客様 (およびそのお客様) は通知のオプトイン/オプトアウトのみを許可され、世界中のお客様は特定の通知が必要かどうかを決定することもできました。 V3 は、お客様が好みを持つというアイデアを試してみる能力を提供するのに役立ちました。ただし、エンド ユーザーの通知オプションが制限されるため、グローバルなオプトイン アウトは問題です。それはすべてか無かのどちらかであり、その中間ではありませんでした。理論的には、ポケモンが「1つを捕まえて、すべてを捕まえる」ということわざに似ています。ただし、これに関する問題は、受信トレイのフラッディングです。グローバルなオプトインにより、エンド ユーザーの受信トレイがすべての製品通知であふれてしまうという概念が可能になります。これは、ユーザーを製品から簡単に遠ざける可能性があるため、問題があります。

グローバルなオプトイン/アウトは、ユーザーが通知を受け取りたいコンテンツと好みのチャネルを選択できるようにすることで、すぐに解決されました.市場におけるこの全体的な傾向は、特にテクノロジー分野の何千もの企業 (B2B および B2C 製品) によって使用されています。

V3 では可視性が深刻な問題になりました。エンド ユーザーは、必要なコンテンツとチャネルの種類を選択するオプションがありませんでした。ユーザーは、一般的に通知を受け取ることに関心があるかどうかを尋ねられます。オプションを提供しないと、通知を通じて受け取る内容の可視性が制限されるため、問題があります。エンド ユーザーは、製品の通知に関しても驚きを嫌います。エンドユーザーが通知を制御できるようにするため、明確にすることが重要です。

V4 では、V3 の主な「失敗」であった可視性の問題を解決しました。お客様とそのエンド ユーザーは、受信したコンテンツと好みのチャネルを制御できるようになりました。

V4 は、エンド ユーザーに戦略的に通知するための優れた方法でした。

プラン

環境設定を構築する際、チームとして従った 3 つのフェーズがありました。

1. 調査フェーズ 1 では、プリファレンス センターに関して現在市場で入手可能なものを調べるのにかなりの時間を費やしました。私は常に次の 2 つの質問を自分自身に問いかけます。

   「[会社名を挿入] はどのように通知を管理していますか?彼らのプリファレンスセンターはどのように見えますか?」

   これらの質問が鍵でした。彼らは私が必要な調査に飛び込むのを助け、多くの重要な市場動向を理解するのに役立ちました.見つかったすべての傾向の中で、最も際立っていたものがありました。

2. トレンド:プリファレンス センターのトグル/グリッド スタイル レイアウトによるチャネルとコンテンツの選択は必須です。このトレンドは、私たちの夏のプロジェクトのバックボーンになりました。ユーザーの好みのオプションを提供することが重要でした。

このフェーズでは、多くのケース スタディを読みました。このトピックについて多くの人が存在することに驚きました。それぞれが、私たちが取り組んでいた問題の解決策を教えてくれました。私は他の人の過ちから学び、貴重な教訓を吸収しました。

この段階では、顧客と話すことが非常に役に立ちました。私はお客様と何度も電話をかけて、この問題についての彼らの見解を聞くことができました.私は質問をし、解決のために私たちが考えていたことの例を示しました。これは、POC の調整に役立ちました。お客様の視点を理解すればするほど、お客様が使用するものを簡単に設計できるようになります。

3. POC の設計このフェーズは本当に楽しかったです。研究が実際の POC になるのを見るのは素晴らしく、とても楽しかったです。集めたフィードバックをすべて取り入れて、何度かデザインを繰り返しました。

POC を作成したら、顧客に戻って、それがプリファレンスで思い描いていたものであることを確認することが不可欠でした。私たちの顧客はまた、一緒に仕事をするのに素敵な人々であり、切望されていたフィードバックを常に提供してくれました.

多くの場合、私は Ian とかなりの量のブレインストーミング セッションを行いました。私たちは調査とお客様の声を見て、これらの情報源を POC にまとめます。参加することは洞察に満ちたプロセスでした。

このフェーズは、2022 年 5 月以降に話をしたすべての顧客を満足させる POC に到達するまで、数週間続きました。

4. MVP の構築POC と完全に完成した設計が得られたら、製品機能の構築を開始しました。このフェーズは、2 つの重要な教訓を教えてくれました…

   
   

整理整頓は非常に重要です。

と...

プロダクト マネージャーとして、チームの 1 週間先を行く必要があります。

Courier で仕事をして仕事を委任しているときに、整理整頓ができるほど、他の人と一緒に仕事をするのが簡単になることに気付きました。私の組織力は、デザイナーとエンジニアが私たちの目標と個々に委任されたタスクをどれだけ明確に理解するかに影響を与えます。整理整頓すればするほど、作業はより速く効率的になりました。私たちのチームが完了する必要のあるタスクの概要を説明し、これらのタスクが必要な理由を説明することは、非常に役立ちました。それは私を含め、すべての人に明快さをもたらしました。

ここでの 2 番目の教訓は、当社の CEO である Troy から与えられました。彼は、現在と次の週について考えることがいかに重要かを教えてくれました。 Troy がこれを持ち出したのは、プロダクト マネージャーとして、パイプラインにあるプロジェクトやタスクについてチームに情報を提供し続けたいからです。この考え方を持たないプロダクト マネージャーは、すぐにチームの邪魔になる可能性があります。この考え方を取り入れることで明晰さがもたらされ、プロジェクトに対するストレスが軽減されました。私は毎週計画を立て、各週の終わり (サイクル) にチームがどこにいるべきかを見積もるのに時間を費やしていました。

これらの 2 つの教訓は、MVP を構築する際に役立ちました。私たちは、達成する必要のある毎週の目標とともに、毎週のタスクの概要を説明しながら、チームとして毎週進行しました。 Courier のチームとの仕事は素晴らしかったです。私が最も気に入ったのは、誰もが意見を持っているということでした。エンジニアとデザイナーは、特定のタスクを構築する前に優先事項があるかどうかを尋ねました。これにより、MVP を構築し、すぐに稼働させることができました。これらの質問は、優先順位と意思決定を導くのに役立ちました。

実行: 私が正確に行ったこと

このインターンシップを通して、毎日が違っていました。私の週には、顧客と話し、エンジニアとデザイナーにタスクを委任し、今週の 2 ～ 3 週間前に先を考える時間がありました。また、エンジニアとデザイナーの両方と緊密に連携して、両チーム間の大きな相乗効果を確保しました。

Courier でのプロダクト マネージャーのインターンシップを通じて具体化した 4 つの主要な責任がありました。

市場 (顧客と見込み客) が私の焦点の範囲内で何を望んでいるのかについて、社内の専門家になること。

私の製品機能がすでに提供しているものについて内部の専門家であること (したがって、上記の中心的な責任へのデルタ)。 Courier を現在の状態から望ましい状態にするパスに優先順位を付ける機能。

現在の製品、構築中の製品、および最終的な製品ビジョンについて会社の残りの部分を教育し、誰もが専門家でなくても同じページにいることができるようにする能力.

チームが適切な理由で適切なことに協力することを保証する接着剤として、チームの成功は最終的に 1 と 2 での私の有効性によって制限されます。自分が深く理解していないことについて、チームメイトに正確に教育することはできません。

Troy は、Courier での私の全期間を通じて素晴らしいメンターでした。彼はこれら 4 つの主要な責任に注意を向けさせてくれました。それは私のインターンシップの不可欠な部分となりました。私が最も共感したのは、すべてのチーム間の接着剤でした。最初、私はこの概念を見て、それに怯えました。しかし、私はチーム間のこの接着剤のような人物になることに非常に楽になりました.簡単に成功できるものではありませんでしたが、挑戦を楽しんでいました。途中でたくさんの素晴らしい友達もできました！

私はどのようなトレードオフを経験しましたか?

インターンシップ全体を通して、多くのトレードオフがありました。主に経験したことは、インターンシップでよく耳にする「うまくいく→うまくいく→速くする」という概念に関連するものでした。 UI/UX を際立たせる小さな機能が、実際にチームの作業を遅らせることが何度もありました。

このようなトレードオフが必要でした。彼らは、私たちが核心を突いた詳細に焦点を当てるのか、それとも機能を脇に置いて、機能し、仕事を成し遂げる製品を作ることに焦点を当てるのか、私に質問しました.その質問の後半部分は、私たちの戦略としてしばしば選ばれました。チームが驚異的な UI/UX コンポーネントを備えた優れた製品ビルドを開発できることを知っているため、これらの呼び出しを行うのは難しいですが、私たちのビルドはそもそも目的を達成する必要があります。

主な目標は、MVP をリリースし、顧客からのフィードバックを得て、コア機能を改善し、この製品の UI/UX に影響を与えるマイナーな優先事項に焦点を当てることでした。

チームとの仕事はどうでしたか？

Preferences で Lifecycle チームと一緒に仕事をするのはとても楽しかったです。みんなとても親切で、素晴らしいフィードバックをくれました。私はこのことを、オフィスで、また同僚との電話で何度も言及してきました。クーリエで働くことは、仕事のように感じられませんでした。親しい友人と一緒にサイドプロジェクトに取り組んでいるような気分でした。環境のおかげで、Courier での作品を制作できたのはこのためだと心から思います。 Courier は気さくで、とてもフレンドリーで、結果重視です。

チームについて私が本当に気に入ったもう 1 つのことは、彼らが常に私のことを考えていたことです。エンジニアやデザイナーが行う「当たり前」の仕事があると、「やってみませんか？」と聞かれます。これには 3 つの例があります。

環境設定プロジェクトの一部の特定のツールチップをデザインする際、Ian (シニア デザイナー) は、ある電話会議で、ツールチップのデザインを試してみたいかどうか尋ねました。これには、私が取り組んだことのない概念である Figma でのフレームの操作が含まれていました。そのツールチップを作成するのは本当に楽しかったです。それは私が含まれていると感じさせました。

チームは毎週、チームのライフサイクル計画会議を開催します。チケットについて話し、それらを書き留めます。インターンシップの早い段階で、Suhas (シニア エンジニア) から、Linear で複数のチケットを作成してみないかと尋ねられました。これはほとんどの PM が通常行うことであることは認識していましたが、これを取り上げてくれた Suhas に敬意を表し、Linear で適切にチケットを作成する方法を喜んで教えてくれました。

チームがPreferencesの内容を固めた後、私は自分のプロジェクトについて興味を持ってくれる企業があるかどうかを社内に尋ね始めました。 Nathan (アカウント エグゼクティブ) から連絡があり、この製品の機能に関心を持っている顧客について知らせてくれました。 Nathan は、この顧客とのコミュニケーションに関して、TON を勧めてくれました。ネイサンの励ましのおかげで、コンフォートゾーンの外に出ることができました。これまでのインターンシップでお客様と話す機会はありませんでしたが、お客様について、またお客様が Courier をどのように認識しているかについて多くのことを学びました。

これらは、私のインターンシップを通じて、このような多くの機会の 3 つの例に過ぎないことに注意してください。 Ian、Suhas、Nathan には大きな声援を送りたいと思います。皆さんが私に学び、成長する機会を与えてくださったことに感謝しています。それは私にとって世界を意味します。

どのようにデザイナーと仕事をしましたか?

Ian (シニア デザイナー) と一緒に仕事ができて楽しかったです。 Slack の「ハドル」機能を使って即席のミーティングを行っていました (これは、私が一度タイプミスをしてしまったため、内部で「ハグル」に名前が変更されました)。これらの会議は、ブレインストーミングと製品設計に非常に役立ちました。より創造的なアイデアを思いつくのが簡単だったので、Ian と私は夜遅くに電話をすることもありました。 .これは私が決して忘れないものです。

Ian と一緒に仕事をするときは、できるだけ簡単にできるようにします。私は Google ドキュメントや Slack を使ってやることリストを作成していたので、Ian と私は毎週何を完了する必要があるかを認識していました。

私たちの電話の間、Ian と私はまた、必ずしも仕事に直接関係しないさまざまなトピックについても話しました。これは私たちの友情を築くのに本当に役立ち、コラボレーションが非常に簡単になり、Preferences のクリーンな UI/UX を考え出すことができました。私は勤務時間外にかなりの量の製品設計を行うことが多く、Ian は常に製品設計と Figma について驚くべきアドバイスをくれました!

エンジニアとどのように仕事をしましたか?

簡単に触れましたが、エンジニアと一緒に仕事をするときは、チケットの作成を手伝ったり、毎週の様子を整理したりしていました。環境設定に関連してエンジニアが混乱するたびに、私が特定の名前を思いついた方法、イアンと私が製品の特定の部分を設計する理由、およびこれらの設計の背後にある目標を説明するのを助けました.これらの回答の多くは、Preferences に興味を持った顧客との広範な調査プロセスから得られたものです。

エンジニアと一緒に仕事をしているうちに、Linear 内でチケット (eipcs) を適切に分解する方法について多くのことを学びました。 Courier で働く前は、しっかりと理解していたと思っていましたが、ライフサイクル チームと一緒に働いてから、さらに多くのことを学びました。チケットを分解するための鍵は、エンジニアと一緒に細部まで考えられるようにすることです。これを行う際に小さなグループにいることは非常に重要でした.

インターンシップ中、Seth (最高技術責任者)、Suhas (シニア ソフトウェア エンジニア)、Christian (ソフトウェア エンジニア) は、Courier の Developer Experience チームと話をして、私たちのプロジェクトを見せるように勧めてくれました。この背後にある主な目標は、デザインが理にかなっているかどうか、環境設定の UI/UX が直感的であるかどうか、および開発者エクスペリエンス チームがこの製品機能の背後にある目標を理解しているかどうかをテストすることでした。プロジェクト全体を説明するスライド デッキを用意しました。これは、 Preferences を顧客に販売する方法を準備するのに役立ったので、素晴らしい経験でした。製品について洞察に満ちたプレゼンテーションを行い、製品を顧客に「販売」することは、製品マネージャーにとって非常に重要で見過ごされているスキルです。社内の人々と話すことも、このスキルを練習し、改善するのに役立ちました。

どのように問題を解決しましたか?

V4 設定の前は、顧客が聞きたいコンテンツと、それについてどのように聞きたいかを選択するオプションが与えられていませんでした。 V4 設定を使用すると、ユーザーはこれらの両方の問題について意見を表明できるようになりました。この新しい製品機能により、顧客は好きなもの、聞きたいものを選択できるようになります。具体的には、チャネル設定を通じて。

受信トレイが乱雑になり、顧客が受信する通知の数に不満を抱く時代は終わりました。プリファレンスは、エンド ユーザーが通知に対して経験するフラストレーションを最小限に抑えます。

クーリエでの役割に応募したいですか?採用情報ページをご覧ください。 Denis が実際にビルドを支援したものを確認するには、ここでデモをリクエストし、Preferences 機能を確認してください。