編集者注: これは、シリーズ B から IPO までの製品管理の拡張に関するシリーズの XNUMX 番目のパートです。 前編と後編を読む こちら & こちら.
成功する組織は、製品であろうとそれ以外であろうと、顧客に焦点を当てています。 この焦点が失われると、次のような問題が忍び寄ってくることに気づきます。
- 一貫性のない製品エクスペリエンス
- NPSが低い
- UXの低下、そして
- ユーザーや顧客の維持率が低い。
シリーズ B から IPO までのスケールアップに関して言えば、顧客を重視することは、適切な問題やプロジェクトを追求することと同じように考えられます。 企業が成長し、リスクが高まるにつれて、間違いが許される余地は少なくなります。 研究開発時間をどこに投資するかが重要であり、最大の効果をもたらす投資を選択する必要があるでしょう。 顧客第一の組織を確立すると、正しい選択ができる可能性が高まります。
SendGrid の製品管理担当副社長および GitLab の CPO としての私自身の経験の中で、顧客とユーザーを重視し続けることが、どのようにして超成長の負担に耐えられる製品を生み出すのかを直接見てきました。 そして、実際に顧客を重視するのは次のとおりです。
a) 誰のために構築しているのかを知ること、そして
b) 問題を効果的に解決するものを構築する。
両方を正しく行うには、問題と解決策の検証フレームワークを確立し、顧客にインタビューし、組織図の出荷を回避し、検証結果を使用して自信を持って「ノー」と言う必要があります。
1. 問題と解決策の検証フレームワークを確立する
SendGrid と GitLab の両方で、私たちは何を構築し、何を構築しなかったかを示す、明確な問題と解決策の検証プロセスを確立しました。 提案されたソリューションが顧客の深刻な問題を効果的に解決すると確信して初めて、開発を開始できます。
その自信がない場合は、検証プロセスを続行するか、アイデアを破棄する必要がありました。
特に GitLab では、製品開発フローを検証とビルドの XNUMX つのトラックに分割しました。 これら XNUMX つのトラックは互いに独立して移動しますが、主要なプロジェクトまたは機能は検証を正常に通過するまでビルド トラックに入ることができません。 による GitLab ハンドブック、検証トラックの目標は次のとおりです。
- わかる 私たちが解決しようとしているユーザーの問題
- 識別する ビジネス目標と成功を決定するための重要な指標
- 生成する 仮説と調査/実験/ユーザーテスト
- 定義する Minimum Viable Change (MVC) 設計パターンと将来の可能性のある反復
- 最小限に抑える 定性的および定量的分析による価値、ユーザビリティ、実現可能性、事業の実行可能性に対するリスク
新しい問題領域、大規模な問題領域、またはよく理解されていない問題領域については、PM が UXer と協力して問題を深く理解します。 このフェーズは通常、対象ユーザーに対して少なくとも XNUMX 回の問題インタビューを実施し、プロジェクトの XNUMX ページの概要をレポートに取り込むことで構成されます。 機会キャンバス、製品および設計のリーダーシップによってレビューされます。 承認されたキャンバス レビューはソリューションの検証に進みます。
ソリューションの検証では、設計者が主導権を握り、正確なプロトタイプを作成して問題の解決策を構想します。 次に、デザイナーと PM は対象ユーザーとさらに少なくとも XNUMX 回のインタビューを実施し、プロトタイプのデザインがユーザーの問題を十分に解決していることを検証します。 そこから、プロジェクトはビルド トラックに入ります。
2. 顧客インタビューを最優先にする
SendGrid での最初の 18 か月間で、約 100 人の顧客と会いました。 GitLab での最初の XNUMX 四半期では、「PM ごとに完了した顧客インタビューの数」を製品組織の OKR の XNUMX つとしました。 これにより、私と製品組織は、顧客が誰であり、顧客が何を望んでいるのかについて、確かな基礎知識を得ることができました。 この調査により、組織レベルの開発の優先順位が決まり、貴重な洞察をチーム間で共有できるようになり、信頼性が高まりました。
何を学ぶ必要があるかを意図的に考えていない場合、または定性的な面接のベスト プラクティスに従っていない場合、顧客との会話に費やした時間が無駄になる可能性があることに留意してください。 質の高いインタビューを実施することは必須の PM スキルであるため、SendGrid ではチーム全体が Cooper Design による定性的なインタビュー トレーニングに参加し、GitLab ではチームのほとんどが 継続的なインタビュー テレサ・トーレスより。 チーム全体が顧客インタビューの熟練レベルに達することで、各チームメンバーが貴重な顧客インタビューの時間から質の高い洞察を最大限に引き出すことができ、多大な成果が得られました。
ベストプラクティスに関する提案をインタビューする
私は、各顧客に尋ねる質問のリストを作成して、これらのインタビューの準備をしました。 この一貫性により、インタビュー対象者全体で洞察をクロスチェックすることができました。 複数の人が全員同じことを持ち出す場合、それは彼らの感情がより大きな顧客セグメント全体で共有されている可能性があることを示しています。
その他のベスト プラクティスの提案は次のとおりです。
- 自由回答形式の質問をする はい/いいえや誘導的な質問は避けてください
- 実際に何をしたか説明してもらいます。 彼らが何をしようとしているかというよりも、
- 問題のあるインタビューについては、 最後まで問題の解決策を提案することは避けてください。 仮に
- ソリューション面談については、 インタラクティブなプロトタイプを持参する そして、指導や指示なしにプロトタイプを使用して意図した問題を解決するように依頼し、その経験に対する感情や反応について大声で話してもらいます。
- 否定的または厳しいフィードバックはOKであると面接対象者を安心させます あなたを侮辱することを心配する必要はありません
面接の手配とスケジュール設定からの煩雑さを取り除く
多くの PM が十分なインタビューを実施しない理由の XNUMX つは、顧客を特定し、調達し、スケジュールを設定し、インタビューを実施することがロジスティック上難しいためです。 チームメンバーのプロセスから摩擦を取り除くために、プロダクトリーダーとしてできる限りのことをしてください。 SendGrid と GitLab では、顧客の調達と面接のスケジュール調整を支援する UX コーディネーターを雇用することにしました。
サポートしてくれる専任担当者を雇用できない場合は、プロセスを自動化または簡素化する他の方法を検討してください。たとえば、インタビューに応じる顧客/見込み顧客のデータベースを維持する、顧客が製品内で直接インタビュー スロットにサインアップできるようにする、またはセールス/カスタマーサクセスに製品チームへのインタビューの準備をしてもらいます。
3. 組織図を配布しないでください
企業に反復可能な検証プロセスが欠けていると、重要でないものを構築することがはるかに簡単になります。 私がよく目にするのは、PM チームが組織図の作成を開始することです。 それは、顧客のユースケースを考慮せずに、自分が所有する分野に最適化された製品を構築する場合と同じです。
CA Technologies で製品管理のシニア ディレクターとして勤務していたとき、私は XNUMX つの製品分野を統合して形成された新しいビジネス ユニットの一員でした。 私たちの目標は、この事業部門が存在する理由をお客様に理解してもらうことであり、これら XNUMX つの製品ライン間の相乗効果を促進したいと心から考えていました。 私たちはすべての問題を解決できると考えたアイデアを考え出しました。
紙の上では素晴らしく見えました。 そのビジネスユニットが存在する理由が明確に説明されており、顧客にとって興味深いものであるように思えました。 次に、それらをすべてまとめた製品機能を思い描き、すぐにその構築に着手しました。
この統合は、私たちが意図したようにクロスセールスを促進しませんでした。 誰も使っていませんでした。 誰も気にしなかったからです。 彼らは、XNUMX つの製品がどのように連携して機能するのかについては決して尋ねませんでした。 それは彼らにとって本当の問題を解決したのでしょうか？ 答えはノーでした。
内部構造ではなくユースケースに焦点を当てる
各プロダクト マネージャーに製品の各自のスライスを見てもらうと、チーム間の継ぎ目が見え始めます。 PM またはデザイナーとして、自分が所有する領域で成果を推進することが奨励されていますが、必ずしも製品全体にわたる広範な成果を推進する必要はありません。 これが製品部門全体で発生すると、統一感のない製品エクスペリエンスが得られることになります。
GitLab では、主要な機能の XNUMX つがマージ リクエストと呼ばれており、複数のチームがそれに貢献していました。 ある時点で、この機能のパフォーマンスが低下し、UX が乱雑になっていることに気づきました。 私たちは UX リサーチ チームにマージ リクエスト機能を監査させ、チームの境界を無視してユースケースに焦点を当てるための具体的な指示を出しました。
チームは、ユーザー ジャーニー内の良いエクスペリエンスと悪いエクスペリエンスを正確に示すユーザー ジャーニー マップを構築しました。 その後、エクスペリエンスの問題を修正し、それを所有するチームに配布し、ユースケース レベルに焦点を当てることで、時間をかけてエンドツーエンドのエクスペリエンスを改善することができました。
4. 検証プロセスを使用して自信を持って「ノー」と言う
SendGrid では、厳しい船を運用しました。 ビジネスは超高速で拡大しており、製品には XNUMX 日に何十億通もの電子メールを配信する必要がありました。 システムのあらゆる側面を巨大なレベルに拡張する必要がある環境では、エンジニアリングは「二度測定して一度削減」のような考え方を持っていました。 このレベルの厳密さと精査は、開発プロセスに時間がかかり、エンジニアリングに構築を依頼したものを製品組織が非常に選択する必要があることを意味しました。そのため、そうでなければ開発チームの時間とエネルギーの多くを消費していた可能性のあるものを早期に破棄しました。 。 問題の面では、検証プロセスを通過したのは約半分だけでした。
一例として、ある幹部は、複数の通貨を受け入れるためにセルフサービスの購入フローをアップグレードするように私たちに求めました。 この人は以前の会社でも同様のプロジェクトを実行し、多くの成功を収めていました。 私たちはプロジェクトの検証に着手し、現地通貨を提供したいと考えたさまざまな国の潜在的な顧客にインタビューしました。 私たちが学んだのは、米ドルでの支払いは深刻な問題ではないということです。 私たちの顧客のほとんどは英語に堪能で、米ドルのクレジット カードで物を買うことに慣れていました。
確かに、追加の通貨に対応できれば便利な機能だったのですが、現在の設定では人々の購入決定に大きな影響を与えていないことがわかりました。 彼らはただ最高の製品を買うつもりだったのだ。 追加の通貨の提供による収益の増加は、高価な値札をかけて実装する価値がなかったため、私たちはノーと答えました。
プロダクトリーダーと初期段階の創業者向けの重要なポイント
- 顧客を知るために時間を割いてください。 プロダクト リーダーとして、誰のために開発しているのか、そしてその問題を深く理解することは、経営幹部レベルの優先順位を決めるのに役立つだけでなく、チーム全体での信頼を築くにも役立ちます。
- 明確な問題と解決策の検証プロセスを通じて大規模なプロジェクトを実行します。 特に大規模な場合、顧客が関心のないものを構築したり、顧客の問題に適切に対処できないソリューションを立ち上げたりする時間はありません。 検証フレームワークは、PM 組織の文化に顧客重視を定着させます。
- 組織図を配布しないでください。 チームが所有する分野に合わせて最適化された製品を構築するのではなく、たとえ複数のチームからの貢献が必要な場合でも、顧客のユースケースに焦点を当ててください。
- 検証プロセスを使用して、自信を持って「ノー」と言えます。 どのようなプロジェクトや機能を追求するかについて、より精査できるほど良い結果が得られます。 確立された検証プロセスを参照することで、意思決定を他のチームに伝えることができます。
Scaling Product Management シリーズの次回の記事にご注目ください。 購読する OpenView ニュースレター そして私とつながってください LinkedIn 最初に知るために！
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- プラトアイストリーム。 Web3 データ インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- 未来を鋳造する w エイドリエン・アシュリー。 こちらからアクセスしてください。
- PREIPO® を使用して PRE-IPO 企業の株式を売買します。 こちらからアクセスしてください。
- 情報源： https://openviewpartners.com/blog/scaling-product-management-part-3-establishing-a-customer-first-org/
