成功するプロダクトマネージャーの3つの重要な特性：アントンダニロフ

プロダクトマネージャーは、テクノロジー企業の重要な役割の1つです。 彼は、ビジネスメトリック、製品自体の成功、およびリリースと製品の改善に取り組んでいるクロスファンクショナルチームの管理を担当しています。

プロダクトマネージャーの地位は潜在的な候補者にとって深刻な課題であるという事実にもかかわらず、多くのIT市場の専門家は、それを成功したキャリアパスの重要なマイルストーンと考えています。 投稿をキャリアの次の段階と見なす候補者は、原則として2つの主要な問題に関心があります。

• どのような技術的専門知識が必要ですか？
• この役割で成功するには、どのようなスキル/資質が重要ですか？

一般的に、最初の質問に答えることは非常に問題です。なぜなら、技術的な専門知識の必要性は常に会社の詳細によって決定されるからです。 したがって、2番目の点に集中し、Wrikeのプロダクトマネージャーに、その役割で成功するためにプロダクトマネージャーが持つべき重要なスキルを尋ねることにしました。

当初は、Wrike PMの意見をダイジェストで収集する予定でしたが、同僚との対話に夢中になり、一連のインタビュー記事が作成されました。

それでは始めましょう。 最初のゲストはアントン・ダニロフです。 アントン-Wrikeのグループプロダクトマネージャーは、エンタープライズをリードしています。 過去に、AntonはKaspersky Labのオンライン販売インフラストラクチャを担当し、それ以前はMicrosoftとSun Microsystemsで働いていました。 製品管理の合計経験-10年以上。

-こんにちは、アントン。

-こんにちは、アルテム。 チャットに招待してくれてありがとう。

-最近、Wrikeのプロダクトマネージャーの地位に履歴書を送りたい多数の候補者と話をしました。彼らは常に2つの質問をしました。 まず、テクノロジーの専門知識はどうあるべきか。 次に、候補者が成功するプロダクトマネージャーであるとみなすために、候補者がどのような重要な資質を示す必要があるか。

-まあ、まず第一に、問題から判断すると、ある人が製品管理の道を歩み始めたと言っておく価値があります。

-はい、私も含め、この記事がある程度までそのような助けになることを望んでいます。 そして、ここで私があなたに尋ねたい質問があります。あなたの意見では、製品マネージャーにとって3つの重要な資質は何ですか？

「3つの重要な特性は非常に複雑な一般化です。」 3つだけを指定すると、実際には3つではないため、それぞれがさらにいくつかに分割されます。 それらを3つ挙げると、それを所有し始めて、人が製品マネージャーになるのは難しいでしょう。

-量に執着しないようにしましょうが、会話の最後に数えますか？

-いいね。 まず 、おそらく最も重要なこと-私はそれを「製品センス」と呼びます。 これから説明します。

製品の感触はどうですか？ 周りのすべてが製品として認識されるとき、それはプロの歪みと言えます。 それだけです。 それが自然の産物であっても、それは何らかの活動、何らかのプロセスの結果です。

そして、この意味で、人が理解しなければならないことが明らかになります-この現象が何であったかの結果、そしてなぜあなたはそのような結果を得たのですか？ そして、結果は何ですか-良いか悪いですか？ そして、「良い」または「悪い」によって測定されるものは何ですか？ そして、誰のためにそれは良く、誰のためにそれは悪いですか？ また、この製品をまったく異なる観点から見ることができる他の評価方法があるかもしれません。 また、「製品のフィーリング」には、製品が良いか悪いかを評価する方法の理解が必ず含まれます。

ここでは、グローバルなもの、特に良いものと悪いものを区別する能力について調べます。 概して、これは味覚と呼ばれます。

あなたがすべてを製品として見ているという事実について話したとき、私はそれらの違いを見ます。 これは、いくつかのスケールでより良いものもあれば、より悪いものもあります。 製品マネージャーは、製品が何かのために作られていることを理解しており、何らかの意味、目的を持っています。

そしてこれは、ある人が製品に取り組むとき、彼はそれを何のために考えているかを考え、ある程度の規模でそれを改善しようとすることを意味します。 製品は常にユーザーの問題について考える必要がありますが、ときどき歪みが発生します。ユーザーが見たいソリューションを考え始めます。 そして、これは大きな危険です。 ユーザーは通常、普遍的で効率的な製品ソリューションを考えていません。 もちろん、ユーザーの提案に耳を傾けるのは正しいことですが、問題に焦点を合わせて体系的に解決することがより重要です

-つまり、人々は製品ではなく、解決策を必要としますか？ 彼の本の中で古典的な経営者であるピーター・ドラッカーは、掘削に従事している人が実際に掘削設備を必要とせず、地面に穴を開ける必要があるという例を挙げたいと思った。

-そうです。

-したがって、彼に地面の穴の解決策を提供した場合、あなたは彼の問題を解決しますか？

「さらに、ピーター・ドラッカーの考え方では、さらに一歩前進することができます。」 優れたプロダクトマネージャーは、「地面に穴が必要なのはなぜですか」と尋ねるでしょう。 オイルが必要ですか？ そして、実際には、最終的には、オイルは必要ありません。 あなたはそれを売るときにあなたが得る利益を必要とします。」これはあなたが考えることができる方法の例です。 この例はとても良いです。 彼の議論の男は一歩を踏み出しました。 さらに2つ行うことができます。

そして、石油会社に来たプロダクトマネージャーはこう言います：「それで、これは石油生産からお金を稼ぐ会社です。 どうやってオイルを生産できますか？」 そして、オイルは実際には千通りの方法で生産することができます。 特定の場所の穴をほぼ地面に指で刺すと、そこから噴水が詰まります。 そして、例えば、石油が安くなる別の場所を見つけることができます。 そして、いくつかの地層のオフショア掘削、または水の助けを借りて圧力をかける技術は、すでにそこにあるものを突破します。 つまり、オイルを入手する方法はたくさんあります。 そして、それは常に穴ではありません。

誰かがあなたのところに来て、「私はドリルリグが必要です」と言ったら、これはすぐにユーザーが解決策を持ってあなたのところに来たことを意味します。 そして、あなたは彼に言います：「それで、ちょっと待って。 何をしたいのですか？」 そして、適切な会話は、プロダクトマネージャーが「ああ！ 私はあなたが石油生産のこの特定の場所でお金を稼ぎたいことを理解しています。 OK。」 そして、最終的には掘削リグに来るかもしれません（またはそうでないかもしれません）が、この掘削リグについてはすでに多くのことを知っているので、パワー、信頼性、信頼性の面で必要な非常に正しい掘削リグを提供します他のいくつかのパラメータ、およびおそらく解決策はインストールを購入することではなく、別のもので、しかしユーザーの問題は解決されます。 私は石油生産の専門家ではありませんが、明らかです。

食料品のセンスにより、製品が作られた理由とユーザーの問題を最速で解決する方法を理解することができますが、同時に、優れた製品マネージャーは会社の使命も考慮し、時にはそれを取り巻く世界をより良くする方法を考えます。

同時に、彼は、ユーザーの問題を解決して利益を上げることを主な目標とする会社で働いていることを忘れていません。 これで、適切な場所に汎用掘削リグを配置できます。 そして、それを複雑にし、それからそれを複雑にし、そしてタワーをセットアップします。 つまり、問題を解決するためにいくつかの連続した手順を実行できます。 会社は生産で徐々に稼ぎ始めますが、ますます増えます。

この食料品の味の感覚と、製品とは何か、製品の作り方、製品の助けを借りてユーザーの問題を解決する方法、そして製品を使いたいという欲求は、製品マネージャーの主要な特性の1つです。 簡単に言えば、彼は製品に夢中になり、製品について考えなければなりません。

2番目の重要な品質は、発達したコミュニケーションスキルです。

製品マネージャーとは、実際には何もしていない人のことです。 彼は一生コードを一行も書かないかもしれません。 実際、これは創造的な送信と接続リンク、翻訳者、翻訳者です。 彼が持っている最も価値のあるものは、彼を信頼し、彼と一緒に仕事をする人々は彼のチームです。 そしてこれには、リーダーシップの要素に関連する非常に重要な側面、インスピレーション、動機付けが含まれます。 製品マネージャーは、彼のチームが彼の話を聞きたいかどうか、どのような製品を開発するかを理解したいかどうかについて責任を負います。

-チームが仕事を始める前に、プロダクトマネージャーがプロダクトアイデアをそれに「販売」する必要があることを正しく理解していますか？

-これは単純化ですが、はい。 彼は、チームがやりたいようにチームと協力できなければなりません。 彼は、チームができる最善を尽くしてチームを動機付けるような方法で作業できなければなりません。

-なるほど

「それだけではありません。」 チームに働きかけるだけではありません。 また、葛藤、異議、動機付け、感情的燃え尽きなどに取り組む能力でもあります。

この能力は、たとえば、すべての責任を自分の手に集中するわけではなく、「今何をすべきかを教えます」とは言いませんが、チームの努力の相乗効果の効果を得るような方法でチームと協力します。 これは非常に重要なポイントです。1人のヘッドが優れていて、2人のヘッドが優れており、チームの目標の合計が何倍も優れているからです。

-もう一度明確にします。プロダクトマネージャーは、コードを座って書いている人ではないということです。

「絶対にそうではありません。」

-これは、理論的にはプロダクトマネージャーが技術的な背景を持っていない可能性があるということですか？ そして、例えば、販売から？

「はい、確かです。」 多くの場合、人々は技術的背景を持って製品管理に来ますが、開発者として、通常、構造的および論理的思考が技術的背景に浸透しているという意味で技術的アーキテクチャを理解しているという意味では役に立ちません。 これは後の作業に役立ちます。

製品マネージャーの範囲には、深い統合やその他の複雑なものが含まれる場合があります。 技術的に複雑なソリューションを設計しているときは、もちろん、言語開発者が何を話すのかを理解しないと難しいでしょう。 そのような場合、技術的背景は望ましいですが、それが重要なものの1つであるとは言いません。 技術的なコンポーネントについて何も理解しなくても、プロダクトマネージャーになることができると確信しています。 非常に頻繁に、私は応用数学の教育を受けているという事実にもかかわらず、私は自分のチームに次のように話します。「聞いて、これを理解していない。 仕組みを教えてください。」 チームは、「ここでコンポーネントを作成する必要があります。」と答えます。 「これはどういう意味ですか？」 などなど。

-それで、これらは通常の質問ですか？ それらを尋ねることによって、あなたは愚かに見えませんか？

-同様の質問は、多くの点でPM'aをチームに近づけることさえできます。なぜなら、あなたはこの方法でコミュニケーションを築くからです。「私はあなたの分野の専門家であり、あなたはあなたの分野の専門家です。 専門的なスキルを組み合わせて、共通の目標を達成しましょう。」 開発者は、自分の分野であるpiemの専門家のままです。 これはまさにリーダーシップのコンポーネントに関係するものです。 しかし、それだけではありません。

さらに、プロダクトマネージャーは、直接管理から始めて、トップマネージャーや近隣地域の責任者に至るまで、社内の利害関係者と多くの仕事をする人です。

人は異なる言語で、異なるレベルで話すことができなければなりません。 たとえば、彼のチームでは、彼はより詳細な言語を話します。 彼は彼らのために一つの方法で物語を描きます。 しかし同時に、彼がはるかに高いレベルの抽象化の人々、例えばトップマネジャーに同じ話をするとき、彼は簡潔に、簡潔に、そしてはっきりと話します。 彼は一般化し、ビジネスの言語を話すことができます。 つまり、誰にどの情報を通知する必要があるかを理解しています。

したがって、3つのレベルがあります。 水平にプロダクトマネージャーとの作業レベルがあります。 チームにはある程度の作業があります。 また、利害関係者との作業レベルがあります。 各レベルで、プロダクトマネージャーの同僚は、独自のモチベーションと世界観、現実に対する独自のアイデアを持っています。 成功は、明確で透明なコミュニケーションがどのように構築されるかにかかっています。 したがって、3つのレベルすべてで有能に働く能力は、製品マネージャーにとって非常に重要なコミュニケーションパッケージですが、このトピックについてはまったく別の議論を行うことができます。

おそらく、私が選出する3番目のスキルは、実行と呼ばれるものです。 製品がチームと連携して計画される場合、製品マネージャーはリリースが行われるように組織的な努力をする必要があります。 重要な要素は、製品をフラグメントに分解する方法を理解することです。 分解して2年間開発することができ、最終的には誰もそれを必要としません。 そして、それを分解して、すぐに価値をもたらし始めることができます。 PMは、製品がどこでどのようにリリースされるのか、どの顧客に対して、このシステムにどのようなリスクがあるのか​​、この開発をフラグメントに分割する方法を理解する必要があります。 そして最後に、分解がスクラム/アジャイルレベルでどのように見えるか。 ここでは、ご存知のように、製品組織の現実について話しています。

これは戦術的なことですが、本質的には、アイデアから結果の実現と測定に到達することを確認する能力、それを失うことなくこのパス全体を通してあなたに火をもたらす能力です。 これはスプリントではなく、これはマラソンであり、製品はこのマラソンを実行できる必要があります。

一方、意欲的なプロダクトマネージャーは、ソリューションを完全なものにし、「先に」リリースしないように努めることがよくあります。 結果が「それほどではない」という恐れがあり、大きな権限がなければ、製品はその活動の低い評価を受けることになります。 しかし、実際には、これはチームのレベルから見てより可能性が高いです。 利害関係者のレベルでは、迅速に提供される価値、テストされ、確認または反証された仮説、および思慮深い後続の反復は、多くの多くの多くの機能を備えた完全にリリースされた製品よりもはるかに価値がありますが、非常に長い時間がかかりました。

-たとえば、アドオンが準備されており、潜在的にこのアドオンは顧客にとって非常に大きな価値があるでしょう。 同時に、それはまだ湿っていますが、誰かが現在の反復ですでに購入する準備ができています。 あなたの意見では、結果をリリースしてから対処するか、何らかの種類のいわば決定を行う方が良いと言えますか？

-そのような決定の有能な採用は、製品の仕事です。 プロダクトマネージャーが非常に価値のあるアドオンに取り組んでいる場合、彼は、たとえば、何も提供しないと去る5人の顧客がいることを非常によく知っています。 彼はそれらをインタビューし、理解することができます：原則として、これら5つのうち4つはプレビューを含めることができます。 この開発はまったく利用できず、クローズドベータになります。 そして、機能を完成させた後、より多くの聴衆にリリースすることができます。

Wrikeには、主要な機能のリリースサイクルがあります。 内部ベータ版があります-これは、内部ユーザー専用の機能を開く準備ができているときです。 一部の選ばれた顧客を招待し、新しい機会を有効にするときに、ベータ版をクローズします。 顧客から最初のフィードバックが提供され、価値はすでに提供され始めています。

その後、フィードバックやフィードバックを提供することに同意する忠実な顧客向けの機能を有効にすると、Labsで開発をリリースします。 その後、パブリックリリースが行われます。 次は、改善と反復の段階です。 すべてのリリースが方法の各ステップを通過するわけではありませんが、完全なサイクルは次のようになります。 できる限り迅速に顧客に価値をもたらすことを目的としていますが、同時にこの価値を徐々に増やし、途中でフィードバックを収集することで、製品をより良くしています。 これは、迅速に提供される価値を提供するための反復的なアプローチです。

要約すると、成功したプロダクトマネージャーの3つの主な特質を選ぼうとすると、プロダクトの感覚と、ユーザーの問題を解決する能力、チーム、同僚、利害関係者、実行との3つのレベルでのコミュニケーション、仕事を完了して実行する能力を強調します反復的に、できるだけ早く価値を提供し、フィードバックを使用して方向を調整します。 これらの各品質は、実際にはコンピテンシー、スキル、および経験の複雑な組み合わせであり、それぞれをより詳細かつ詳細に議論できます。 おそらく、いつかこれらの問題に戻り、再び議論するでしょう。

4月15〜16日にモスクワで開催されるProductSense会議で、 Anton Danilovによるレポートをお見逃しなく。