利害関係者の管理：ノーと言う芸術

優れた製品開発には、イノベーションが存在する、望ましさ、実現可能性、実行可能性の間の魔法の重複を特定し、それに焦点を当てる必要があります。 製品マネージャーは常にこれらのドメイン間のバランスを守らなければならない立場にあり、他のドメインを犠牲にして製品を一方向に引き離そうと競争する力に対抗します。 これは、製品開発の過程で、多くの場合、多くの人にノーと言うことを意味します。

キャリアの早い段階で、自動車分野のプロジェクトに取り組み、環境データとユーザーの行動に基づいた機械学習を使用して、ドライバーにスマートな提案を提供するアプリを開発しました。 私がチームに参加したとき、アプリはリリースの準備ができていて、経営陣はそれをリリースすることを熱望していましたが、すぐにそれが本番環境の準備ができていないことに気付きました。

アプリは視覚的に魅力的でしたが、「どのような問題を誰のために解決するのか」など、最も基本的な設計の質問のいくつかは無視されていました。 そして「人々はこの問題を解決するためにどれほど必死ですか？」

このアプリは、ドライバーの目的地の天気を表示する機能を備えていました。 ユーザーの習慣と交通データから、アルゴリズムはドライバーが向かう可能性のある場所とそこに到達するのにかかる時間を推測でき、単純な天気API統合により、到着時の目的地の天気予報が示されました。 これは良いユースケースのように見えましたが、実際には誰も気にしませんでした。 ヨーロッパのドライバーの有料調査を含む私自身のユーザー調査を行ったとき、その反応は響き渡る「メ」でした。 それは間違いなくあなたが得ることができる最悪のフィードバックです：それはあなたの製品が無関係な問題を解決したことを意味し、望ましさの次元が非常に低いことを示します。 その場合、実行可能性は失われた原因になります。誰も望まない製品で実行可能なビジネスを構築することは不可能です。 私たちは全部をスクラップしなければなりませんでした。

どうしてこれが起こったのでしょうか？ 答えは複雑ですが、それは、重要な単語が本来あるべきときに発声されなかったという事実に要約されます。

同社のコアコンピタンスと資産は、機械学習推論エンジンと高度にスケーラブルなアーキテクチャ設計でした。 データサイエンスの責任者は、彼の推論エンジンが顧客のアプリケーションでうまく利用されることを望んでいた強力な利害関係者でした。 彼の影響の一部は、完全に技術中心の製品を生み出しました。 開発は、顧客が望むものではなく、技術的に実現可能なものによって推進されていました。

誰もこの利害関係者にノーと言ったようには見えませんでした、そして彼らが試みたならば、それは効果的ではありませんでした。

製品戦略はノーと言うことを意味します

ノーと言うのは難しいです。 人々はいつもその言葉を聞くのが好きではなく、それを言うことは重要な関係を損なうのではないかという恐れがしばしばあります。 プロダクトマネージャーとしての関係は私たちの役割の中心ですが、私たちの製品が成功し、バランスが保たれるようにすることも重要です。

では、関係を維持しながら、どのようにして誰かの要求を拒否しますか？ 私はこれらの方法をお勧めします：

• 成功するための準備をしなさい。
• 急いでノーと言わないでください。
• リクエストをリフレームします。
• 貢献の風土を奨励します。

成功への準備

プロジェクトの開始時に、製品の成功に関する共通のビジョン（「なぜこれを行うのか」）と、進捗状況を測定するために使用される一連のメトリック（「どのように知るのか」）について全員が合意することが不可欠です。うまくやっているのなら？」）。 成功がどのように見えるかについて同意しない場合、対立が生じるのは時間の問題です。

フレームワークを使用して目標を文書化し、それらを測定可能なものにマッピングすると便利です。 私はGoogleのHEARTフレームワークのルーズバージョンを使用するのが好きです。これは、ユーザーエクスペリエンスを幸福、エンゲージメント、採用、保持、タスクの成功のカテゴリに整理し、それらの各カテゴリの目標、シグナル、指標を明確にします。 目標はあなたが達成しようとしていることに対処し、信号は各目標をユーザーアクションに分解し、メトリックはそれらのアクションを追跡して、定量化可能な方法であなたがどのように行っているかを測定します。

最近のある消費者向けアプリプロジェクトでは、限定的なパイロットを実施して、ユーザーが私たちのプロトタイプが有用であると感じ、それと対話し続けたいかどうかを判断したいと思いました。 私は主にHEARTフレームワークのエンゲージメントカテゴリに焦点を当てました。 次に、その目標に向けた進捗状況を追跡するためのシグナルとメトリックを特定する必要がありました。

• 目標：ユーザーはアプリを操作して使い続けたいと考えています。
• シグナル：ユーザーはアプリを頻繁に開きます。
• 指標：1日に2回以上アプリを開いたユーザーの割合。

目標を特定して調整するこのプロセスは単純に見えるかもしれませんが、簡単ではありません。 この場合、クライアントと営業チームとの電話、独立した調査、および複数のチームワークショップが含まれていました。 この発見から収集した情報に基づいて、クライアントとのキックオフミーティング中に完成したHEARTフレームワークを提示することができました。 私たちはすべての項目を調べ、必要に応じて適応させました。

すべての利害関係者が目標設定プロセスに関与していることを確認することが重要であり、追跡する必要のあるシグナルとメトリックについて全員が合意することで、プロジェクトの進行中に繰り返しノーと言う必要がなくなります。 また、誰かが計画のパラメーターの範囲外の要求であなたに近づいたかどうかを示すデータも提供します。

すぐにノーと言わないでください

主要な利害関係者が成功の様子に同意し、今後の道のりが明確に見える場合でも、確かなことが1つあります。それは、誰かが、どこかで、予期しない質問であなたに近づくことです。

それが起こったとき、あまりにも早くノーと言わないでください。 リクエストが不合理であると確信している場合でも、それを完全に拒否すると会話がシャットダウンされ、関係が損なわれる可能性があります。 また、製品の発見プロセスを損ないます。 プロダクトマネージャーとして、私たちは全体像を見る必要があり、私たちに同意しない人々の話を聞くことは私たちの死角を減らします。

もちろん、それでもノーと言うことはできますが、ひざまずく反応を避ける必要があります。 それらは、白黒、正しいか間違っているか、勝ち負けの思考の結果であるバイナリの議論につながります：あなたは何かを実装するかしないかのどちらかです。

より効果的で微妙な議論に移行するには、目標設定プロセスの一環として確立した合意された基準に従ってリクエストを整理する必要があります。

利害関係者に「この機能はあなたにとって価値がありますか？」と尋ねる代わりに。 「この機能はあなたにとってどれほど価値がありますか？」と尋ねます。 結果として得られる会話は、重要度の順に並べられた「希望」のリストで共同作業するために必要な情報を提供するはずです。 複数のアイテムが階層内の同じ場所を共有することを許可せずに、このランキングが1からnの範囲であることが重要です。 これにより、優先順位付けプロセスで全員に発言権が与えられ、一方的にリクエストを拒否する必要がなくなります。 一部のリクエストは、グループがより重要なリクエストを優先してダウングレードすると、途中で失敗します。

リクエストをリフレームする

最初は不合理に思われるリクエストは、微妙なリエンジニアリングで良い結果をもたらす可能性があります。 まず、言われていることに耳を傾けます。 本当に聞いてください。 あなたの仮定を脇に置き、他の人がどこから来ているのかを理解しようとし、それから共通点を見つけてください。 「なぜ」と尋ねてもう少し深く掘り下げると、必ずしも5回聞いたことがあるとは限りません。 通常は2〜3で十分です。つまり、共通の目標を示す要素を発掘する場合があります。

完全に賢明な要求でさえ、より深く掘り下げて少しリフレーミングすることで恩恵を受けることができます。 B2Bモビリティサービスのビジネスインテリジェンスツールに取り組んでいた状況を覚えています。 私のクライアントは、予期せぬことではありませんが、加入者数を増やすように私に頼みました。 有料加入者数を増やす動機は自明のように思えるかもしれませんが、全体像を把握したかったので、「なぜ？」と尋ねました。

問題の製品はライフサイクルの終わりに近づいていることが判明し、私のクライアントは、新しい製品と交換する前に、最後の利益の低下を絞り出したいと考えていました。 この情報を基に、「次の製品発売の基礎を築きながら、短期的に収益を大幅に増やすにはどうすればよいか」という要求を再構成しました。

結局のところ、最善の解決策は、加入者数をまったく気にせず、価格と価値をより適切に調整することでした。 顧客は、ライダーの取引にツールを使用する頻度に関係なく、固定の月額サブスクリプションを支払っていました。 ただし、処理するライダートランザクションが多いほど、ツールから得られる価値も高くなります。 顧客は、月間取引がほんの一握りの個々のタクシー運転手から、数十の子会社と数千台の車両を抱える多国籍の貨物運送業者まで、数十万の月間取引を行っていました。 同じ固定月額サブスクリプションは、小規模なクライアントには高すぎ、大規模なクライアントには低すぎました。

わずかな価格調整を行うことで、間もなくリリースされる製品の段階的な価格構造（トランザクション数に基づく）に向けてベビーステップを進めながら、収益を増やしました。 新しいモデルは、ほとんどの顧客の価格を下げ、不釣り合いに利益を上げていた最大の顧客の価格を上げました。

このようにリクエストをリフレーミングすることで、お互いに有利な状況を作り出すことができます。 リクエストを提出する人は、耳を傾け、尊敬されていると感じ、製品開発プロセスを損なうことなく付加価値をもたらす洞察を得ることができます。

貢献の風土を奨励する

ノーと言うことの最大のリスクの1つは、拒否すると、チームの内外で育成しようとしているオープン性とコラボレーションの精神が損なわれる可能性があることです。 アイデアは、関連性があるかどうかに関係なく刺激を受けます。最後にやりたいことは、創造性とコミュニケーションの流れを止めることです。

私はかつて、豊富なアイデアを持ったジュニアQAエンジニアと一緒に仕事をしました。 ほぼすべての会議で、彼は複数の質問をし、提案を志願しました。 彼の解決策はしばしば実行可能なものではなく、それらのいくつかは役に立たないか無関係であるとして却下された可能性があります。 しかし、彼の献身と熱意はかけがえのないものでした。 彼は可能な限り最高の製品を提供することに完全に投資し、彼の貢献は他の人々に活気を与え、刺激を与えました。 そのような態度は伝染性です。

あなたは、人々が考えやアイデアを共有することを奨励されていると感じ、そうすることで報われる環境を作りたいと思っています。 あなたのチームは、解雇されたり、無視されたり、嘲笑されたりするという考えに落胆するのではなく、物事を改善する可能性に動機付けられるべきです。 いくつかの簡単なプラクティスを実装すると、チームの心理的安全を確保するのに役立ちます。

アイデアや要望を公に認めます。 これは信頼を築き、あなたが提案を大切にし、それらを検討することにコミットしていることを示しています。 リクエストボックス、Confluenceページ、またはすべての利害関係者がアクセスできるその他の公開フォーラムを設定します。 リクエストが届いたら、それをログに記録し、リクエスターにメッセージを送信して、彼らの貢献に感謝します。

これは物議を醸すかもしれないことを私は知っています、しかし私は時々皆に製品バックログを開くことまで行きます。 これは、製品チームからのエンゲージメントを促進するのに特に役立ちます。また、QAテスターやデザイナーなどのチームメンバーが遭遇したことに気付くことができます。 ルールは単純です。誰でもバックログの最後に追加できます。改良（または他の毎週の会議）中に、チームメンバーは追加した内容を共有し、その理由を説明します。 プロダクトマネージャーのみが、問題の順序を変更したり、アイテムを削除したりできます。 多くの人は、このレベルのアクセスをすべての人に許可すると、混乱と無秩序につながると考えていますが、そうではありません。 私はさまざまな規模の組織でこれを試しましたが、人々が恥ずかしがりすぎてアイデアを提供できない場合にのみ失敗します。

これらのログに記録されたリクエストの1つに大まかに関連するソリューションを実装したり、機能をリリースしたりしたら、リクエスターを公にクレジットします。 これは、ソリューションが元の要求の明確な履行ではなく、より多くのリフレームされたバージョンである場合に特に重要です。 成功にかかわるすべての人に感謝の気持ちを示すことは、善意を生み出し、友情を築き、人々が参加し続けることを奨励します。

ノーと言うことの長所と短所を比較検討する

時間をかけて利害関係者がどこから来ているのかを実際に聞いて理解すれば、提案を完全に拒否する必要はほとんどありません。 積極的な聞き取り、透明性のあるコミュニケーション、相互尊重は、最初は問題があるように見えたり、範囲外に見えたりする可能性のある要求を処理する上で重要な要素です。 ほとんどの場合、「いいえ」と言う技術には、実際には「いいえ」と言うことは含まれません。

共通点を見つけることが不可能であることが判明する状況があり、製品とプロジェクトを保護するために直接の必要はありません。 他の場合には、あなたはあなたが同意しないことを続けることを余儀なくされるかもしれません。 あなたの仕事は、望ましさ、実現可能性、実行可能性のバランスを保護することですが、考慮すべき4番目の側面があります。それは実用主義です。 物事を前進させ続けるためには、妥協が鍵であり、時にはそれは完全にノーを回避することを意味します。

アジャイル製品開発の利点は、その反復的な性質がコース修正の多くの機会を提供することです。 結局のところ、目標は、討論-論争-延期ではなく、構築-測定-学習です。