プロダクトオーナー/マネージャーが「この機能[ユーザーからのリクエスト]は開発に長い時間を必要とするので、私たちがそれを行うことは決してない」と答えたらどうしますか？
より正確には、私はデザイン文化を持たない会社で働いています。一部の人々は、ユーザー中心の方法でもう少し考える傾向がありますが、重要なものではありません。プロダクトマネージャーは開発時間のみを考慮し、CEOは競合他社に対するビジネス戦略のみを考慮します。最終的に、予想される機能（ユーザーが要求する機能）をステート＆マーケット指向の機能（CEOが定義）の上に置くことはできません。/PM）。
例を挙げましょう。数か月前、ユーザーがメッセージを読んだり読んだりしないとすぐに見たいという報告がありました。提案された解決策は、「リスト内のメッセージの名前を太字で表示する必要があります。メッセージを読むと、メッセージは通常に戻りますが、あなたのためだけです」です。しかし、その後、主任開発者は、メッセージをいつ誰が読んだかは実際にはわからないので、それを行うには多くの時間が必要になると述べました。それ以来、プロダクトマネージャーは機能を何度も何度も延期し、必要な時間と比較して影響が低すぎると述べています。最終的には、「私たちはおそらくそれをまったくやらないだろう」とさえなりました。
したがって、UXデザイナーとして、これらの人々が決定を下しているときにユーザーを防御し、私が言っていることが役に立たないように見ているだけなのでしょうか。
tl; dr
ビジネス上の成果のコンテキストでユーザーのニーズを提示します。
それがうまくいかない場合、これが溶ける前に新しい仕事を見つける時が来ました。
ユーザーのニーズをビジネスの成果に合わせる
あなたの説明に基づいて、それはように聞こえます
- 機能強化に対するユーザーの要望をうまく表現できました。
- 組織の残りの部分は、ビジネスの成果をうまく表現しています。
2つを分離すると、ビジネスの成果は常に勝ちます。特に、現在の製品設計慣行に追いついていない組織では。
製品戦略の適切な構造を覚えておいてください。
製品ビジョン➝イニシアチブ➝エピック➝ストーリー➝タスク
ビジョンとその結果としてのイニシアチブは、すべてを下流に追いやります。そのレベルで物事に影響を与えることができない場合、失敗します。
健全な製品開発の役割
典型的な健全なソフトウェア組織では、
UXデザイナーは、ユーザーのニーズに焦点を当て、そのドメインの機会を発見します。
エグゼクティブチームは、市場と財務のニーズに焦点を当て、そのドメインのターゲットを定義します。
プロダクトマネージャーは、2つを結婚させ、リーダーシップに機会を伝え、それに応じてバックログに優先順位を付ける責任があります。
あなたの場合、プロダクトマネージャーは、ユーザーとビジネスがどのように結びつくかを理解する能力を持っていないか、変更せずに実行チームの注文を単純に受け入れるという過度のプレッシャーがあります。 それは失敗につながる非常に悪い状況です
ギャップを埋める
タオルを投入する前に、プロダクトマネージャーの仕事をしてください。市場でのポジションをどのように変化させ、真の利益をもたらすかに基づいて、優先順位を調整します。現在の機能をユーザーの期待と比較し、ユーザーの不満や使いやすさの欠如がユーザーにコストをかけ、製品の放棄を促進し、MRR（月次経常収益）に悪影響を与える方法を比較します。
製品の意思決定フレームワーク
私はこれをどこで見つけたのか覚えていませんが、私は何年もそれを使用してきました、そしてそれをみんなに優先順位を理解させる非常に役立つ方法です...
製品戦略を正しく定義できる場合（この場合は難しい場合があります）、収益の計算が次の最大の決定要素になります。それを見積もることは難しく、確かにチームの努力によるでしょう。市場調査を行ったり、他の部門の責任者と話したり（セールスとオペレーションを念頭に置いてください）、クライアント側の実際の意思決定者とチャットしたりするために、レッグワークを行う必要があります。それはあなたの仕事ではないかもしれませんが、それは結局のところ良い経験であり、あなたの会社の製品を差し迫ったドゥームから救うだけかもしれません。
ソフトウェアの状態に関するサイドバー
製品が「メッセージがいつ誰によって読まれたかを実際に知っている」場合、「実行するのに多くの時間」（書き換えの準備ができていると思います。また、その評価を行うために、新しいエンジニアリングチーム、または少なくとも新しいリーダーが必要になる可能性もあります。それらは厳しい要求ですが、多くの製品がその現実を受け入れることを恐れていたために失敗することを私は見ました。
Kanoモデルは適用されますか？
SPavelのリファレンス カノモデル 基本、パフォーマー、およびエキサイター/ディライターという3つの基本的な機能タイプの満足度向上に関するビュー。カノは、後者の2つはあなたに最大の満足感を与えると私たちに言います、それはしばしば本当です。あなたの組織は（故意かどうかにかかわらず）この理論を適用しています。 ただし、Kanoモデルは、最小要件がすでに満たされていることを前提としており、製品には基本的な使いやすさと機能に必要な機能が備わっています。 基本を回避するためにカノモデルを適用することは、大きな誤解です。
IOW、カノが申請しましたが、あなたの組織がそう思っているのとは異なります。
リアリティチェック???? ????
それはすべて素晴らしいことだと思います。努力するのは賢明なことです。一方、光を当てると組織が変わると考えるのは信じられないほど楽観的です。
あなたが世界を変えようとしている間に、新しい仕事も探し始めます。多くの場合、仕事の変更は困難で不快であり、ほとんどすべての問題を解決できません。しかし、沈没船でセーリングを続けるのも賢明ではありません（ （Joseph Conrad'sYouth いつかを読んでください）。
満足度に関して、「期待される機能」の収益率は非常に低い
これをPMの観点から検討してください。エンジニアリングに多くの時間を費やして、お金にならない機能を作成したいとします。それが行うことは、ユーザビリティをある程度向上させることです-原則として重要ですが、カノモデルによれば、ビジネスの結果には疑問があります。
おそらく、ソフトウェアはその緑の線に沿って右下の四分円のどこかにあるでしょう。使用可能ですが、受賞歴のあるNNグループレベルでは使用できません。これは担当者にとって十分なものであり、代わりに赤い線に沿ってさらに移動したいと考えています。これは、給与を支払うためにお金を稼ぐことができるからです。
ユーザーはステークホルダーの1つにすぎません
あなたの唯一の責任はユーザーにあると考えるのは間違いです。それはあなたの責任のoneです-そしてあなたはこの責任を持つ会社で唯一の人かもしれません-しかし、あなたがすべてで働く方法を学ばなければあなたの関係者、あなたが提案するすべての機能はあなたのハードドライブで苦しむ運命にあります。
内部の利害関係者にとって、メッセージを未読としてマークするためにエンジニアリング時間を費やすことは価値がありません...単独で。しかし、どのユーザーがどのメッセージを読んだかを知ることには多くの価値があります。アナリティクスは大きなものです。ユーザーセグメンテーションは別です。 「ユーザーが彼らが読んだものを見ることができるようにする」（会社にとって疑わしい利益）のではなく、「ユーザーを追跡できるようにする」（会社にとって大きな利益）とエンジニアリングの取り組みを売り込むと、Beanカウンターは次のようになります。はるかに優しくあなたに。
これはおそらく負けた戦いであり、あなたが何をしても結果は変わりませんが、PM）との会話を検討し、責任の範囲と彼/彼女の期待を尋ねる必要があると思います明らかに、すべて非常に敬意を表して、質問は会社の時間を最適化することであり、不要なことをしないようにすることであると説明しています。
そうすれば、彼/彼女はあなたに具体的な答えを与えることを強いられます。あなたの責任が可能な限り最高のユーザーエクスペリエンスを生み出すことであると彼/彼女が言った場合、あなたは何をしたいか、あなたの決定の賛否両論を説明し、この変更がどのようにエクスペリエンスの改善につながるかを文書化できます。それらのユーザー。会社の競争を考慮することは非常に重要です。競争がそれを行わない場合は、独占的で差別化された機能として「販売」できます。
さて、あなたが言及するユーザー事例は非常に些細なことのようであり、実際にはほとんどすべてのメッセージのアプリケーションでデフォルトであるため、説明にデータが不足しているか、問題が別です。そして、残念なことに、問題が対人関係、自我、嫉妬である場合、私はあなたが何でもできるとは思えません。
要するに
すべてを文書化し、費用対効果の違いを説明するために最善を尽くし、PMと話し、責任の範囲を設定します。本当にこれ以上のことはできませんが、これはあなたがするべき最低限のものです。
私は痛みを感じます、本当にそうしますが、現実の世界では、行われた決定に影響を与える多くの事柄があります。影響を与えることができるものも、影響を及ぼさないものもあります。
役立つことが2つあります。
同僚と話し、関係を築く。意思決定が彼らのやり方で行われる理由を理解してください。主要な開発者が実装する時間の長さについて正しいことを受け入れますが、関連する機能や同様の機能についてよりよく知ることができるように、理由（実際には、意味のある理由）を説明するかどうか尋ねます。 PMは、提供する必要があるすべての情報を考慮してこの機能を呼び出しますが、その情報の構成要素を確認します。防御的な姿勢ではなく、決定を理解しようとします両方のプロセスを効果的に処理できるようにします。
証拠の生成。機能の影響は、任意で低い、または努力に対して低いとマークされている可能性がありますが、反対の証拠はありますか。証拠を提示するだけで、誰かを正しく証明しようとしているとは考えないでください。機能を求めているユーザーの数。製品の使用にどのような影響がありますか？ユーザーはどのようにして欲求不満を解消していますか？ユーザーはどのような状況でこの機能を求めていますか。ユーザーが既読メッセージを見て無駄に費やしている時間。ビジネスやブランドの認識にどのような影響がありますか？これらの特定のユーザーを満足させる以外に、この機能の利点は何ですか？ （ユーザーに代わって）この機能を本当に信じる場合は、強力な証拠を収集して販売する必要があります。その証拠を調査して、信頼できる信頼できる情報源に戻ることを忘れないでください。
結局、あなたはあなたの戦いを選ぶ必要があります、しかしあなたがすべての会話を確かに戦いのように感じているなら、あなたはあなたが正しい場所にいるかどうかを考えなければなりません。
-
この種のものには別の方法があります-意思決定者に製品を自分で使用してもらいます。システムに優先順位のない弱点が本当にあり、ユーザーを苛立たせている場合、意思決定者自身がそれに不満を抱くようになると、すぐに優先順位が上がる可能性があります。
このような場合、シナジーを使用して機能の値を増やすを行うことができます。
要求された機能は、未読メッセージを強調表示することです。これは、どのメッセージが未読であるかを知る方法があれば、ささいなことです。そうではないので、この機能は高価です。
どのメッセージが誰がいつ読んだかを知ることでメリットを得る別の機能はありますか？社内分析ですか？ターゲット広告？スパム/ボットの検出？デバッグ？