Backlogの大きさは顧客との対話頻度に反比例する

 (bitbytebit.substack.com)
13 ポイント 投稿者 GN⁺ 2024-01-24 | 1件のコメント | WhatsAppで共有
  • 顧客と頻繁に対話するほど、バックログの大きさは小さくなる
  • 計画に費やす時間を顧客との対話に置き換えることが重要
  • 開発者と顧客の間の仲介者が多いほど、製品は顧客の要求を満たせなくなる
  • 大きなバックログは、未検証の仮説が多く、顧客価値を生み出す可能性が低いことを意味する

UIデザインより技術コンポーネントの設計に集中すること

  • UIデザインに時間をかけすぎず、基本的なUIを素早くリリースし、顧客フィードバックを通じてUIを改善することが重要
  • 技術的負債を低く保ち、顧客が必要とする変更を迅速に行えるようにすべき

人々が考えるアプリの使い方と実際の使い方は異なる

  • 顧客がアプリを使っている様子を観察することが重要
  • ユーザーの行動を直接観察すれば、定量指標だけでは把握できないインサイトを得られる

アカウントスプーフィングの実装

  • 特定の顧客が実際にどの画面を見ているのかを理解するために、アカウントスプーフィング機能への投資が重要
    • アカウントスプーフィング(Account Spoofing): 管理者が特定の本番ユーザーになりきってアプリを利用できる機能
  • これにより、問題を効果的に診断し、テストデータへの依存を減らせる

最初のページの重要性

  • アプリに初めてアクセスした顧客に、最も関連性の高い情報を簡潔に提供する必要がある
  • 最初のページに情報を詰め込みすぎると、ユーザーの認知負荷が高まる

顧客は最も重要なマーケター

  • NPS(Net Promoter Score)は、顧客が製品を薦めたくなるほど強い好意を持っているかを示す良い指標
  • 広告費をかけることもできるが、満足した顧客から始めることが効果的なマーケティング戦略

MVPは反復改善なしでは意味がない

  • MVPは、単に納期のプレッシャーを理由に低品質な顧客体験を提供する言い訳になってはならない
  • MVPは、追加の反復が必要かどうか、必要ならどこを改善すべきかを判断する助けになる

GN⁺の意見

  • この記事で最も重要なのは、顧客との継続的な対話を通じて実際のユーザー要求を反映した製品開発の重要性である
  • 顧客のフィードバックを迅速に反映できる柔軟なUIデザインと技術コンポーネントの重要性を強調している
  • MVPを超えて継続的に製品を改善し、顧客満足度を高めることが長期的な成功につながることを示している
  • この記事は、スタートアップ生活で得た教訓を共有し、創業者や開発者に実践的なインサイトを提供する

関連記事

1件のコメント

 
GN⁺ 2024-01-24
Hacker Newsの意見

  • 機能/改善事項の整理方法に関する意見

    • 経験上、すべてのアイデアをチケット化する戦略は非効率です。そうすると、決して使われないアイデアでいっぱいの「アイスボックス」ができてしまいます。
    • 重要な取引のためにアイスボックス内のアイデアが必要になったときでさえ、そのアイデアの存在を思い出せず、新しいチケットを作ってしまいます。
    • 短期または中期で実現可能性のあるチケットを優先し、それ以外のアイデアは別に保管します。
    • エンジニアリングチームは解消したい技術的負債の一覧を、PMはプロジェクトごとの改善可能性の一覧を維持します。
    • 新機能/新製品についてはPRDを作成しますが、すぐにチケットへ変換はしません。
    • ほとんど処理されない巨大なバックログは、「ノー」と言うことを恐れる弱いPMのサインです。

  • バックログの大きさとPM交代率の関係

    • バックログの大きさはPM交代率と反比例します。
    • 長く在籍しているPMにとって、バックログは過去のプロダクトに関する対話の記憶補助装置です。
    • 新しいPMはバックログを見て混乱し、理解できないものを整理しようとします。

  • 顧客起点のバックログ維持に対する反対意見

    • バックログを維持するチームの多くは、顧客からバックログを得ています。
    • 「顧客の生活を改善する機能を見つけて次の機能として作れ」というのは、そう簡単ではありません。
    • 複数の顧客がいて、それぞれの生活を改善する機能が互いに無関係で複雑な場合、どうするのでしょうか。
    • 顧客の要望には常に耳を傾けるべきですが、彼らが要求したものをそのまま作るべきことはほとんどありません。
    • 顧客はUXの実装だけでなく、問題そのものや現在使っている業務プロセスを示唆する形で機能を要求します。
    • ビジネス上の問題を把握し、UX実装のアイデアやプロセス固有の事情は捨てるべきです。
    • ビジネス上の問題を解決する最小限の機能を、経済的に、優れたUXデザインと一貫性を持って構築すべきです。

  • 顧客要件を記録するためのPMの必要性

    • PMには顧客の要件を記録する場所が必要です。
    • 専用ツールがなければ、要件はたいていJiraチケットに行き着きます。
    • ProductBoardとJira Product Discoveryという2つのアプローチがあります。
    • ProductBoardはCRM的なアプローチで、すべての顧客とのやり取りを記録し、後でそれを要件や要望に分解します。
    • Jira Product Discoveryはアイデアから始まり、顧客から聞いたあらゆることをその場で長い要件・要望リストに分解しなければなりません。
    • Jira Product Discoveryの利点は、開発者向けバックログからアイデア一覧を分離できることですが、別の長いリストを作ってしまいます。
    • 顧客との対話に基づいてプロダクトの優先順位を分析するなら、ProductBoardのほうがより優れたプロダクトディスカバリーツールです。

  • 顧客フィードバックで磨かれたバックログの重要性

    • ほぼ毎日顧客と対話しているため、顧客フィードバックによって直接情報が与えられ、磨かれた機能や改善事項がバックログに入っています。
    • やることは常に多いですが、バックログが顧客フィードバックによって情報を得て磨かれているかどうかが違いを生みます。

  • 顧客との日常的な対話を通じたバックログ管理

    • 技術者として毎日顧客と話していますが、この理論は魅力的である一方、いくつか問題があります。
    • 新近性バイアスと機会費用: より高い優先順位のために意図的に取り組んでいない問題領域についても、フィードバックを継続的に収集する必要があります。
    • 反応的な開発: フィードバックの記録を省くと、直近で最もアクセスしやすい作業に集中し、古い問題を見落としがちになります。
    • チームの知識基盤: フィードバックを集めて解決策を提供する単一の責任者がいるなら、元記事投稿者の主張は有効かもしれません。
    • チームが関与しているなら、非同期にデータポイントを記録・検索できる共有データベースが必要です。
    • バックログはすぐに大きくなり得ますが、複雑なシステムと人を扱うことには難しさが伴います。
    • よく組織されたチームにはバックログの適切な管理が必要であり、それには無関係な作業の保管、重複作業の排除、定期的な優先順位付け、ツールの最大活用が含まれます。
    • バックログを管理することはツール自体より重要であり、必要なときにより深く掘り下げられる情報を表面化する、バックログ上の「ファサード」が必要になるかもしれません。

  • アプリ利用者の観察の重要性

    • 顧客がアプリを使う様子を観察することは重要です。
    • あらゆる指標を追跡することはできますが、ユーザーが何かを探してスクロールしたり、戻るボタンを押したり、クリックできないものをクリックしようとしたりする様子を見るのは、実感を伴う体験です。
    • AppleやGoogleなど、あらゆる企業が毎日何度もユーザーを観察してほしいものです。

  • 大きなバックログの無用さ

    • 大きなバックログには不確かな仮定が多く、顧客価値を生み出せる可能性は低いです。
    • 何かに価値があると仮定する誤りを何度も犯してきましたが、実際には誰も気にしないことがよくあります。
    • 大きなバックログは顧客との対話頻度が低いことを反映しているため、非常に懐疑的に見るべきです。

  • アカウントスプーフィング実装に関する警告

    • アカウントスプーフィングは本番環境の問題をテストする簡単な方法ですが、サポートチームや開発チームは本番データへの信頼を必要とします。
    • 一部の業界では、これは顧客にとって大きな問題になり得ます。
    • 最後に働いたスタートアップでは、開発者が本番データに一切アクセスできないようにしていました。
    • これはセキュリティの観点から最終手段と見なすべきであり、顧客データにアクセスできない前提で作業するほうが望ましいです。

  • プロダクト計画のツリー構造

    • プロダクト計画は常にツリー構造であるべきです。
    • 最上位ノードはビジネス目標で、その下にプロダクト、さらにその下に顧客課題、その下にバックログ項目があります。
    • バックログ項目が多すぎるということは、適切な構造が設定されておらず、優先順位付けされたビジネス目標の一覧が存在しないことを意味する可能性があります。
    • 「顧客と話すこと」は顧客課題を理解するうえで有用ですが、まずビジネス目標を知る必要があります。そうでなければ、どうせ取り組まない領域のフィードバック収集に時間を浪費することになります。