- あるスタートアップでは、エンジニアが自ら営業コールに参加するようにしたことで、製品開発の進め方が根本から変わった
- 営業コールの中で、彼らは競合製品が非技術系ユーザーには複雑すぎること、そして顧客はログや指標よりも、監視が動作していることを示す**確認マーク（緑のチェック）を求めており、さらには「誰かが代わりにやってくれないのか」**という要望まで持っていることを知った
- これにより、バックエンド中心のチームはユーザー視点を理解するようになり、PMの介入がなくても新しいアーキテクチャを自ら構想し始めた
- わずか2週間でプラットフォームの機能を60%削減し、進捗を示すプログレスバーの追加、Slack連携、代行ワークフロー機能を構築し、結果としてサポートチケットが70%減少した
- この経験から得た教訓は、ユーザーは問題解決だけを望んでおり、エレガントなコードには関心がないこと、そして機能はコード量ではなくユーザーの混乱というコストを生むという点だった
背景と実験
- DevOpsのシニアエンジニアは営業コールへの参加に反対していたが、最低5件だけ試すという条件で同意した
- 創業者は、エンジニアが顧客の言葉と課題を直接聞いてこそ、製品設計が変わると判断していた
営業コールで得たインサイト
- 競合製品は非技術系ユーザーには複雑すぎると語られていた
- 顧客は複雑な指標よりも、単純な緑のチェックマークのような直感的な確認を求めていた
- 多くの顧客が**「代行サービス」**を求め、単に使うことよりも問題解決そのものを外注したがっていた
製品書き直しの結果
- チームは既存機能の60%を削除し、必須機能に集中した
- シンプルなプログレスバーを追加し、利用体験を改善した
- Slack統合によって問い合わせの流れを簡素化した
- Done-for-youワークフローを提供し、顧客の要求を直接反映した
- 最終的にサポートチケットが70%減少し、製品の使いやすさと満足度が大きく向上した
核心的な教訓
- ユーザーはエレガントな技術的解決策ではなく、問題解決そのものを求めている
- 技術的な正確さよりもユーザー理解のほうが重要である
- あらゆる機能には、コードではなくユーザーの混乱というコストが伴う
チーム文化の変化
- その後、会社ではすべてのエンジニアが四半期ごとに5回の営業コールに参加することを義務化した
- エンジニアが顧客の疲弊を直接聞き、「とにかくちゃんと動いてくれればいい」という要望に触れながら、製品に対する直感を養うことが文化として定着した
Redditコメントの主な要約
- PMの役割をめぐる議論
- 一部では、優れたProduct Managerの不在こそが問題であり、エンジニアが顧客との通話まで担うのは非効率だと指摘された
- その一方で、「PMは結局翻訳者の役割にとどまり、エンジニアが顧客課題を直接オーナーシップするときに最良の結果が出る」という反論もあった
- 顧客接点の価値
- 多くのコメントで、エンジニアが直接ユーザーの声を聞く経験が強力なインサイトを与えると強調された
- 初期段階のスタートアップや小規模チームでは、エンジニアがそのままPMの役割の一部を担うことも珍しくないという意見もあった
- 批判的な見方
- 「これは単にリーダーシップ／文化の失敗をエンジニアに押しつけただけだ」という批判
- 「機能を削って単純化することが本当に改善なのか」という反論もあり、長期的にはパワーユーザーや高度な機能要件を軽視するリスクがあると警告された
- 前向きな事例共有
- 銀行、医療機器など複数の業界で、同様に全社員が顧客サポート・営業を体験する制度があったという体験談が多く寄せられた
- Dogfoodingや自ら顧客の前に立つ経験が、製品品質と文化に役立つという共感もあった
- 総合的な示唆
- 顧客の問題を直接実感させることは強力な学習ツールだが、
- 同時に長期的には、専門的なPM・UX・デザイン能力と組み合わせてこそ、バランスの取れた製品戦略を作れるという点が議論の核心として浮かび上がった
まだコメントはありません。