製品マネージャーと製品デザイナー：類似点と相違点を見つける

私の名前はRostislavSalataです。e-sports組織で3年近く働いています。私はインターフェースデザイナーとして入社し、UXリードに成長し、現在は製品マネージャーを務めています。



製品マネージャーの仕事と私たちのために働くアプローチは、他社の製品マネージャーのそれとは大きく異なります。これは、製品マネージャーとデザイナーの機能とスキルセットに対する会社の理解が異なる可能性があることを意味します。たとえば、一部の企業では、製品マネージャーがインターフェースを設計していますが、私たちは設計していません。



なぜ私はこれを持ち出したのですか？製品設計者へのインタビューをたくさん行いました。私の経験と同僚の経験に基づいて、各申請者が委託条件について質問していると言っても過言ではありません。責任範囲についての異なる理解は、その後、製品に悪影響を与える競合につながる可能性があります。



以下に、管理に切り替える方法に関するチェックリストと100パーセントの指示はありません。この記事の最初の部分では、「私はすでに製品だと思う」という神話を払拭します。第2部では、製品マネージャーの実際のタスクについて説明します。より正確には、私が日常的に遭遇し、製品管理とは何かという理想的な考えを払拭する必要があるものについて。

パート1。私の製品マネージャーと私は同様のタスクを実行します。だから...私は製品マネージャーですか？

経験豊富な製品デザイナーと初心者を区別する資質があります。したがって、私は、設計を深く理解し、その有効性とビジネス上の問題の解決への影響を測定する専門家の特徴に​​ついて議論することを提案します。何らかの理由で、強力な設計者の責任はしばしば混乱したり、製品マネージャーのタスクに追加しようとしています。次の6つのポイントは、これらのスペシャリストのタスクを理解する上での一般的な「間違い」です。実際、これは強力な製品設計者の機能ですが、何らかの理由で、彼がこのように考えて行動すれば、彼は自動的に管理者になると多くの人が信じています。

1.「これは私の仕事ではありません」または「これは私の責任範囲ではありません」というフレーズがあなたの語彙から消えます

あなたがそれを解決または修正するのを助けることができると知っているなら、あなたは状況に目を閉じません。現在の負荷を損なうことなく、サードパーティのプロセスを引き継ぐ準備ができています。あなたは「責任」という言葉の意味を理解し、それを自分で引き受ける準備ができています。



あなたは自分が十分な能力を持っていないことをみんなに言うのをやめたと思っていることに気づきます。代わりに、建設的な批判をすべての人に巧みに伝える方法を見つけます。業界の多くの設計者やその他の人々は、これらが管理への第一歩であると考えるかもしれません。はいといいえ。



製品設計者は製品管理者よりも製品に対する責任が少ないと誰が言いますか？製品設計者を禁止する人は誰もいません（まったく逆です！）グリッチに気付くには、アドバイスを与え、チームプロセスの構築または補足を支援します。優れた製品設計者は、以下で説明する動作によって区別されます。

2.あなたは自分で洞察とその情報源を探し始めます

ほとんどの場合、これまたはその機能を実装するかどうかの決定は、製品マネージャーに委ねられます。多くの場合、製品デザイナーを含むデザイナーには、デザインの助けを借りて解決する必要のあるユーザーの問題と苦痛のリストが提示されます。あなた自身がこれらの問題、タスク、ニーズまたは苦痛を見つけた場合、考えが生じます：製品マネージャーはこれを行うべきではありませんか？要するに、はい。そしてこれだけではありません。

ユーザーの問題の定義は、設計プロセスの一部です。「フロントエンドの専門知識」は確かに非常に重要ですが、ユーザーとの継続的な作業を伴う必要があります。確かに、多くの場合、洞察のほとんどを見つけて製品に実装するのは、製品ではなく設計者であることがわかります。

3.導入される機能がユーザーだけでなく影響することを理解している

デザイナーは、調査、インタビュー、ソーシャルメディアへのコメント、サポートリクエストからのユーザーのフィードバックに基づいて提案を行うことが多く、ユーザーが私たちのすべてであると述べています。間違いありません。ユーザーから洞察を得ることができ、またそうすべきです。しかし、単一のユーザーではありません。



開発された機能Xをさまざまな通信チャネルで使用して、製品の財務モデル、その使用に関する法的規則とポリシー、製品と会社全体の戦略的目標に影響を与えることができると考え始めると、製品とチーム全体にとってはるかに価値があり、役立つようになります。これは、デザインのハードスキルの非常に優れたマーカーです。



多くの設計者は、オムニチャネルの概念に精通しています。製品に取り組むときは、この概念から始めて、提案されたユーザー機能を慎重に検討する価値があります。設計者は、ユーザーとのすべての接点で、実装されたソリューションが製品に与える影響について考えるべきではないのはなぜですか？あなたが製品デザイナーであるなら、これは単に持っている必要があります。すべてのレベルでの設計ソリューションの一貫性、詳細、および思慮深さは、設計者の最高のスキルです。

4.すべての人にとって通常の意味でのデザインから焦点を移す

設計者は主に製品インターフェースを操作します。彼の仕事の結果は、視覚的に心地よく、ユーザーフレンドリーなインターフェースになるはずです。焦点を詳細な分析に移すことは、良いことよりも害を及ぼす可能性があるため、これを忘れてはなりません。設計者は、調査、分析、その他の製品の問題に没頭し、ユーザーの製品に対する第一印象の重要性を忘れてしまうことがあります。



製品のインターフェースと視覚的コミュニケーションがあなたを最も興奮させ始めないことを理解しているなら、多分あなたはデザインや管理について考えるのではなく、研究者の立場について考えるべきですか？

5.提案された機能は製品に利益をもたらさないという感じがあります

この感覚は自己重要性（PSV）と関連している可能性があるため、注意する必要があります。機能の導入は、「そう思う」、「よく知っている」、「ユーザーにとって間違いなく便利になる」という理由だけで正当化されることがあります。



製品または会社のメリットの観点から機能を分析できるのは良いことです。どうやってするの？アイデアを検証し、議論します。これを行っているのは製品マネージャーだけですか？良い質問。



デザイナーであれマネージャーであれ、感情を事実や数字と比較し、決定を下す方がよいでしょう。

6.製品指標に対するあなたの態度は変化しています

多くの場合、メトリックはすでに設定されています。チーム全体がそれらを達成するために取り組んでおり、デザイナーも例外ではありません。現在の指標を修正したり、より正確な解釈のために改良したり、少なくとも新しい指標を作成または追加したりできると考えている場合は、すばらしいことです。



製品の指標を別の角度から見ることは良いスキルです。しかし、このスキルを持っているということは、あなたが製品管理に向かっていることを示していますか？はいよりもおそらくいいえ。製品設計者は、メトリックに対して決定をテストすることができます（すべきですか？）。そうすれば、パフォーマンスメトリックをより広く見ることを学ぶことができます。



新しい機能を追加したり、既存の機能を繰り返したりすることは、製品または会社の目標と一致している必要があります。製品設計者は、メトリックに基づいて構築し、より広いコンテキストでそれらを検討する必要があります。これは、スペシャリストが管理に​​移行する時期であることを示すものではありません。



実際、製品設計者と製品管理者の責任は多くの点で重複していることがわかりました。では、製品マネージャーは実際に何をしているのでしょうか。

パート2。製品マネージャーは実際にどのようなタスクを解決しますか？

正直に言うと、多くの場合、製品マネージャーは直接のタスク以外のことを行います。あなたが製品マネージャーでこのセクションを読んでいるなら、マーケター、デザイナー（特にグラフィック）、営業担当者、開発者、プロジェクトマネージャー、PRマネージャーなどとして自分自身を思い出すと、間違いなく笑顔になります。はい、私もこれらすべての役割を果たしましたが、本当にそこにあるのは、私のデザイナーは機能せず、機能しないでしょう。



以下に、製品マネージャーが「目に見えない」タスクを実行して「目に見えない」結果をもたらす主なベクトルをまとめました。

1.焦点、統合、コミュニケーション。

フォーカス。製品マネージャーは、自分の製品から利益を上げることに集中する必要があります。言い換えれば、会社のためにお金を稼ぐことです。プロジェクトを収益性の高いものにするための意欲は、熱狂的ではなく、正気でなければなりません。



新製品を市場に投入する例についての狂信を考えてみてください。マネージャーは理解する必要があります。彼の製品が不安定で、市場の基本的なニーズをカバーしていない場合、収益化の話はありません。どうして？基本的なニーズをカバーせずに、独自の価値に対してのみ支払うようにユーザーに請求することは、最も重要な瞬間に失敗する可能性があります。



統合。製品マネージャーは、チームの真実の源でなければなりません。製品はふるいのようなものです。大量の情報を収集し、ふるいにかけ、理解できる技術的タスクの形でチームに転送します。



例として、仮説の実装または検証の段階でセールスマネージャーまたはマーケターと協力することを検討してください。仮説を他の部門で作業するために転送する前に、情報を確認する必要があります。一方では、主要な質問に答える必要はありません。一方、掘り下げる必要のある戦略的ベクトルを設定します。



コミュニケーション。私の理想的な世界では、製品マネージャーの仕事は次のように分割する必要があります。

• 30％：彼らの仕事;
• 40％：チームとのコミュニケーション。
• 30％：従業員との1対1の会議。

ご覧のとおり、時間の70％は通信ですが、タスクの最初の30％も何らかの形で通信に関連しています。



コミュニケーションとは、プロセスの設定、チーム内の内部問題の解決、マーケティングなどの他の部門の代表者とのミーティングです。初心者の製品であっても、優れたソフトスキルが製品開発に役立つことがよくあります。



製品マネージャーの仕事の最も重要な結果の1つは、十分に構築されたコミュニケーションです。あなたが「感じる」ことができる結果がないので、これは仕事の最も難しい部分の1つです。

2.営業部との連携（事業展開）

ほとんどの製品は遅かれ早かれ収益化の段階に入ります。製品マネージャーの主な仕事は利益を生み出すことであるため、営業チームとのコミュニケーションは、製品と市場全体をよりよく理解するのに役立ちます。一部の企業は、ビジネス開発部門と連絡を取る機会を常に提供しているわけではありませんが、私は幸運でした。



ビジネス開発マネージャーとのコラボレーションは、製品のより良い販売のための条件を作成します。セールスマネージャーは、製品、長所、短所、およびユーザーの問題点を理解する必要があります。その後、適切なタイミングでアップセルします。

3.チーム間のプロセスの編成

問題を解決するために複数のチームを展開するのに十分なリソースが会社にある場合は、アクションを調整するためのコミュニケーションを確立する必要があります。このプロセスは日常的なものですが、それなしでは実行できません。担当し、異なるチーム間のコミュニケーションのための定期的なイベントを作成します。



はい、速くはありません。はい、これは難しいコミュニケーションです。はい、無視される可能性は高いです。しかし、同僚の態度とタイムリーな情報へのアクセスは有効です。このケースは、チーム間の相互作用のタスクをよく説明しています。

4.チームの目標と目的の正しい設定

目的。製品チームの各メンバーは、なぜ「それを行う」のか、そしてどこに向かっているのかを理解する必要があります。現在の機能の更新、新しいシナリオの開発、別の市場への参入など、それが何であるかは関係ありません。非公式な設定で、チームの製品目標のビジョンに関心を持つことをお勧めします。



タスク。製品マネージャーとして、あなたは自分自身を理解するだけでなく、自分自身も理解していることを確認する必要があります。自分の期待がチームにとって必ずしも明白であるとは限らないという事実に出くわすことがよくあります。したがって、タスクを設定する前に、最終的に何が出てくるのか、なぜこれが機能するのかを全員が理解していることを確認する価値があります。完了のそのような定義は、「何？」という質問に答えます。製品側から。チームは「どうやって？」という質問に答えます。

5.議論と面付け

私たちのチームでは、改善は議論の段階を経ます。決定が「上から」行われたとしても、チームはそれを理解して共有する必要があります。一般的なタスクを理解し、詳細に飛び込むことは、すべての参加者のための製品思考の開発への投資です。この時間に投資すると、「ゲーム」をユーザーに渡さない、非常に堅牢な内部検証者グループが得られます。それ以外の場合、チームは単なる実行者になります。



一部の人には適していますが、他の人には適していません。私の会社では、チームメンバーは誰でも製品開発に完全に参加しており、提案されたアプローチを批判したり、独自のアプローチを提案したりできます。

6.製品チームの管理

重要なのは、開発プロセスの理論的理解、Courseraからのアジャイル証明書の存在ではなく、チームを編成し、その作業の有効性と結果に責任を負う準備ができているかどうかです。



チームメンバーをサポートする必要がある瞬間を感じ、助けを求め、いつ-彼らの意見を求めることが重要です。これは完全にナンセンスに聞こえるかもしれません。しかし、同僚の気分を理解し、彼らの儀式を知ることで、クールなチームを構築するための多くの洞察を得ることができます。



製品マネージャーは、新しい機能を追加したり、機能するものを改善したりする前に、提案された仮説を最後まで「揺り動かし」ます。製品はまた、仮説が受け入れられた場合、提案された変更の結果を測定するKPIと、それがテストされる目的を把握しています。



6.1チームと実装されたソリューションのコスト

今、ロマンスについてではありません。標準的な見積もりに加えて、製品マネージャーとして、使用する予定のリソースの財務効率を計算する必要があります。チームの1時間のコストを理解すると、提案や仮説で財務効率のプリズムを調べ始めます。



開発コストと機能の変更による期待利益は、意思決定において重要な役割を果たします。チームの仕事の財務面を知ることは、製品マネージャーの主なスキルであるノーと言う能力を強化すると思います。



6.2。人的資源のパフォーマンス

一部の企業では、製品マネージャーがチームメンバーの定期的なレビューに参加しています。客観的な理由から、レビューレベルでの技術スキルの議論は、マネージャーの影響範囲外です（もちろん、技術製品ではない場合を除く）。しかし、個人の有効性とそれがチームワークに与える影響の評価はまさに重要です。



製品マネージャーは、チーム内の従業員のパフォーマンスの評価に影響を与えることができ、また影響を与える必要があります。少し利己的に聞こえますが、チームは製品の利益のために献身的かつ効果的に機能しなければならないリソースです。



次のアプローチを使用して、従業員のパフォーマンスに影響を与える要因を評価および議論できます。

• 定期的な1対1の会議。
• 物議を醸す問題を解決する際の監督。
• プレリリース反応;
• 他のチームの同僚とのコミュニケーション。

「振動を起こさないでください。価値を創造する」©



6.3。スタッフの

採用、チームの拡大製品マネージャーは、チームの従業員の選択にも影響を与えます。技術的なスキルと仕事の経験に加えて、チームとの互換性と会社の価値観との整合性が重要です。インタビューの実施は別のスキルです。



リクルーターを知り、彼らの秘訣やコツを学ぶ方が良いでしょう。学ぶ人がいない場合、あなたは自分の過ちからしか学ぶことができません。人を雇うことはプロセスです：オンボーディング、適応、試用。責任は誰にあるので、2〜3か月間、これが適切な人物であることを確認する必要があります。



6.4。解任

一部の企業では、マネージャーがチームメンバーを削除でき、一部の企業では、解雇にのみ影響を与えます。本質は変わりません。人を解雇することは、おそらくコミュニケーションにおけるマネージャーの最も難しいタスクの1つです（少なくとも私にとっては）。主なことは、理由を確認し、議論を身に付け、立ち去る必要につながった状況を数回分析し、同僚に解雇されたことを知らせることです。

7.トップマネジメント（レベルC、エグゼクティブ、創設者、投資家）とのコミュニケーション

私自身、このアイテムは製品マネージャーの仕事の中で最も難しいものであり、今でも最も難しいと判断しました。難しさは、非常に異なるレベルの抽象化で考え、決定を下すことにあります。機敏な言葉で言えば、これはテーマ（テーマ）またはイニシアチブ（イニシアチブ）のレベルでのコミュニケーションです。



これは戦術的な行動よりも戦略に関するものです。トップマネジメントとの相互作用-多くの未知の変数に関する問題を解決します。これにより、快適ゾーンから大きく外れ、製品と会社の多くの視野が広がります。



要するに、すべての作業は市場またはニッチな調査、洞察の検索、ビジネスレポートの校正などに帰着します。これらすべてのアクションは、数字と事実で特定のレベルの抽象化をバックアップするために必要です。将来的にそれを戦術的なタスクに変換するために。

結論

製品設計者と製品管理者の両方のタスクは重複しており、大きく異なります。



製品マネージャーの能力の範囲内でタスクを実行するデザイナーは、2つのことを行い

ます。彼は不足している可能性のあるスキルに夢中になっています。

製品マネージャーから負荷の一部を取り除き、タスクをより効率的に実行できるようにします。



製品管理のロマンスについて考えている場合は、上記のベクトルの1つで問題を解決することを想像してください。発表しましたか？製品マネージャーはこれらのベクトルを1日を通して頻繁に切り替えるため、今は忘れてください。



切り替えずに特定の期間に1つのタスクを実行する場合は贅沢です。それは良いですか悪いですか？答えるのが難しい。ほとんどの場合、これらはさまざまなタイプのタスクです。すぐに記事を下にスクロールした場合は、少なくとも2番目の部分に戻りたいように、ここにシードを作成します。



デザイナーやその他のスペシャリストとして、1日に何度かコンテキストを変更する準備はできていますか？あなたの時間の70-80％がコミュニケーションであるという事実の準備ができていますか？作業の結果がすぐに表示されて「感じられる」とは限らないという事実に備える準備はできていますか？



そして、目標があれば、努力する価値があります。主なことは、すべてのニュアンスを考慮に入れることです。