dogfooding

ドッグフーディング

集中的な社内利用の文化を築いてきた2人のプロダクトリーダーのフレームワークを使い、効果的なドッグフーディングの実践をユーザーが導入できるよう支援します。

支援方法

ユーザーがドッグフーディングについて支援を求めた場合は、次の手順で進めます。

1. 現状を評価する - チームが現在、自社プロダクトをどの程度利用しているかを把握します
2. ギャップを特定する - チームメンバーがユーザーの悩みを実体験できていない部分を見つけます
3. プログラムを設計する - ドッグフーディングを自然かつ必須にする仕組みづくりを支援します
4. 効果を測定する - ドッグフーディングがプロダクトの意思決定をどう改善するかを追跡します

基本原則

チームメンバーにユーザーになってもらう

Maya Prohovnik：「ポッドキャストを作っていないプロダクトチームにいつも怒鳴って、『正しいものを作れるとは思えない』と言っています。ユーザーと常に話し、データを見ていても、メンバー全員がポッドキャストを始めると、ようやく『なるほど、わかった』と言うんです。」チーム全員にクリエイター／ユーザーになってもらい、ユーザーの悩みを深く理解してもらいます。

毎日、集中的にツールを使う

Michael Truell：「最初から、私たちのプロダクト開発プロセスは、実際に使ってみること、そして毎日ツールを集中的に使うことが中心でした。自分たちにとって役立たないものは決してリリースしたくありませんでした。」毎日の「集中的な」利用により、役立つ機能を作るために必要な現実感が得られます。特にAIプロダクトでは重要です。

ユーザーを支援するための質問

• 「各チームメンバーは、実際のユーザーとしてどのくらいの頻度でプロダクトを使っていますか？」
• 「チームが自社プロダクトを熱心に使う妨げになっているのは何ですか？」
• 「社内利用を、強制ではなく自然なものにするには何が必要ですか？」
• 「ドッグフーディングと顧客からのフィードバックでは、得られる学びに違いがありますか？」
• 「自社プロダクトを使うとき、バグや使いづらさによる不満をどのくらい早く感じますか？」

よくある間違いとして指摘すること

• 表面的なテスト - 実際の業務では使わず、デモモードでしかプロダクトを使わない
• QAに任せきりにする - チームメンバーに実際のユーザーになることを求めず、テスターに頼る
• 見落としやすいユースケースを無視する - エッジケースではなく、想定どおりに進むケースだけをテストする
• 見つけた問題に対処しない - 発見した問題を修正するプロセスなしでドッグフーディングを行う
• プロダクト以外の役割を除外する - エンジニアだけにドッグフーディングをさせ、デザイナーやPMにはさせない

詳細

2人のゲストから得た2つの洞察については、references/guest-insights.md を参照してください。

関連スキル

• ノーススターメトリクスを書く
• プロダクトビジョンを定義する
• ロードマップの優先順位を決める
• OKRと目標を設定する