More Related Content Similar to プロダクトマネージャとセールスチームはどう連携すべきか 〜 失敗例と方針 (20) プロダクトマネージャとセールスチームはどう連携すべきか 〜 失敗例と方針1. 2018.09.08 PM (Product Manager) x Sales Meetup @LINE
プロダクトマネージャとセールスチームはどう連携すべきか
〜失敗例と⽅針
株式会社トーチライト
灰⽥ 直史
@naohaida
2. ⾃⼰紹介
• 灰⽥ 直史
• 2006年〜2010年 シリウステクノロジー社、「AdLocal」(地域広告) プロ
ダクトエンジニア、フロントエンドエンジニア (リーダー)
• 2011年〜 ピド株式会社 (iOS/Androidエンジニア)
• 2013年〜 株式会社トーチライト
• Facebook / Instagram / Twitter / LINE Ads Platformなど、ソー
シャル広告運⽤システム「Sherpa」の開発に従事 (ソフトウェアエン
ジニア)
• 2017年1⽉より同事業部⻑兼PM。トーチライト社として上記プラット
フォーム全てからAd Tech認定パートナーとして認定
• 主にオンラインで提供されるBtoBソフトウェア製品の開発に携わる。エン
ジニア出⾝のPM
#⼩さい会社、#スタートアップ、#製品開発、#⾃社製品、#Happy New
Hack、 #週末ハック、 #ソーシャル広告、#ナオハイダ
4. 1年半ほどの経験・失敗を通して分かったこと
• 売れる製品を作るチームにはできる優秀なPM(プロダクトマネージャ)が必ず存在
• セールス > PMしか経験なし (というかPM組織がないところからスタート) いかに組織を横断した
形でのモノ作り⽂化を醸成するか?を勉強する必要があった
• ダメな製品が無駄に世に送り出される原因: 会社の中でプロダクトマネージャー(PM)の
役割が明確にされていないこと、プロダクトマネージャーとなる⼈に対する教育が不⼗
分なこと
• 製品の中⾝に関わるべきなのはPMだけでもエンジニアだけでもない:
• 「売れる」製品とは: しかるべきものを (PM)、いいクオリティで (Engineer)、しかるべきタイミ
ングで (Marketing)、沢⼭の⼈に (Sales)
• PMと製品開発に必要な役割をどう連動させて開発を動かしていくか? ← 今⽇ここ
6. ありとあらゆるリソースが⾜りない! / 適材適所でない!
⼩さい会社にありがちなこと
• リソースが潤沢にない、適材適所にリソースを使えていない、アイディアはそれなりにある
起きる(起きた) こと:
• 得意領域を中⼼にしたリソース配分
• なんとなく「偉い」上司がいて全ての最終決定権を担う。
• エンジニアリング以外の分かりにくい部分は全て「偉い上司」 。なので実質PMもする。
• ただし、事業が⼤きくなると「偉い上司」は「製品を考える業務」(PM) にリソースが割けなくなってく
る
• エンジニアが製品設計をすることで、UX調査がなされていなかったり、業務知識に不⾜があるので「売れ
ない」製品になる、エンジニアがエンジニアリングに注⼒できない不幸
• セールスチームが製品設計をすると、特定顧客への課題解決となっており、カスタムコードが量産される
8. 製品開発をするチームに必要な4つの役割
• よい開発 (エンジニア/UI)
• よいProduct Management
• 製品の市場性を評価、開発すべき製品の定義
• 製品要求とユーザーエクスペリエンスデザインを組み合わせて、製品のプロフィールを決める責任
• ここにUXチームを含める
• よいMarketing (製品の語り部)
• 製品を世界中に知らしめること製品の外装を決めること
• 販売チャネルから製品を売り込むためのツールを提供すること
• オンラインでのマーケティングや市場関係者に対する製品のマーケティング
• よいSales (売り⼿)
• どの顧客にアプローチするのか、どの顧客に当たるのか?
これらの役割それぞれが四権分⽴であること
どれもが⽋けることなく、どれもが互いに均衡を保つ (x可能な限り役割をオーバーラップさせない) ことが⼤事
9. なぜ役割をオーバーラップさせることがNGか?
例えば... PMが考えるべき課題 (by マーティケイガン.Inspired:顧客の⼼を捉える製品の創り⽅)
1. (市場性の評価)製品化によって具体的にどんな問題を解決 する のか?
2. (バリュー プロポジション) だれのためにこの問題を解決しようとしているのか?
3. (ターゲット市場)市場の⼤きさは?
4. (市場規模) 製品化の成功をどうやって評価するのか?
5. (指標、 収益 戦略) 現在、 他に競合する製品はあるか?
6. (競合の⾒通し) なぜ当社がこの製品化をやるのに最適なプレーヤーと⾔えるのか?
7. (差別化要因) なぜ今なのか?
8. (市場投⼊の時期)
→ それぞれの役割に応じて、セールスならば、「どの顧客にアプローチするのか」「その顧客の課題は何か?」「どの顧
客にアプローチして売上を達成するのか」「会社が存続するためのセールス⽬標と進捗は?」、エンジニアならば、、、
マーケティングならば、、、といった質問に答えていく必要がある
ある程度組織が⼤きくなってくるととても兼任はできない上に利益相反があるので、責任者を分担しないと組織としてベ
ストな解を出しづらくなってくる
11. PMの頭を悩ますセールス起点の問題
Product Management and Marketing Survey (2017) (製品管理とマーケティングに関
する実⽤的なマーケティング調査 / 次ページに例) によると、PMの頭を悩ます問題の中に
はセールスが起因となる問題が多い
• PMの46%がアカウント単位でカスタマイズされた販売ツールを要求するセールス担当者
に悩む
• PMの42%が顧客が古い機能ばかり要求するのでイノベーティブな機能を追加することが
難しいと考える
• PMの30%はセールスが意識的に⾃社の特定製品販売を回避すると考える
• セールス主導になると、製品がチグハグ化しがち、PM主導になるとセールスが売りづらい、
⼀体感がなくなる
→ ある程度製品が⼤きくなって来てセールスチームがついたときにPMとセールスチーム
との関係の相互理解が⼤事になってくる
http://mediafiles.pragmaticmarketing.com/pdf/PragmaticMarkketingSurvey2017.pdf
13. Cf. PMに理解して欲しいセールスの悩み?
• 顧客の現場感にPMが追い付けてないことが多い
• 結果として悩みや作るべきものを理解しているのはSales側だけ、という意識になってしまう
← PMは可能な限り顧客との対話の場出ていくことにも時間を使うこと
• ⼀⼈では限界が来るので組織化していく
セールスからの意⾒にPMはどう対応するべきか
• 困っていることは確かなので受け⽌め、それをPMの視点から製品に落とす (優先度、
解決の仕⽅等含め⼀旦持ち帰る。そのまま実施する必要は本来はない)
• どうしても⼗分な議論をしても決着しない場合
• プロトタイピングでの検証
• ⻑期的な投資が必要な領域は仮説・検証プロセス
• 検証が必要な場合は検証に無駄な時間をかけない → リーンスタートアップなどの⽅法論
15. セールスとPMを橋渡しする⽅法論 (1/2)
• 製品開発の状況を「オープンに」、⽅法論は「オープンな」 (=世間で体系化されている)をベース
にすることで組織間で連携しやすく
• 製品開発のリーダーシップを属⼈化させない⽅が組織の進化が進みやすい (ボトムアップに可能に
なるので)
• xカリスマ性、x直感、x定義されないワークフロー
• 開発の優先度はPMだけの意⾒が反映されるべきではなく、Marketing / Sales / 開発 / PM 全ての
視点を踏まえた上で優先度が決定されるべき
• そもそも、それぞれの役割で利益は相反しやすい
• セールスは短期視点 (Q毎)、PMは⻑期視点、エンジニアは実装視点など
• 全ての懸念・事情を踏まえた上で最終的に組織の正義の元、優先度・ロードマップは決定され
るべき (全体の意⾒が反映されやすいような仕組み作り、かつ最終的に意⾒を取り纏めるのが
PM)
16. セールスとPMを橋渡しする⽅法論 (2/2)
• 製品開発の⽅法論の理解
• リーンスタートアップなどの顧客開発論、ゼロトゥワン、スタートアップウェイなど、前提となる話は理解者が多い⽅が
はかどる (製品開発に関わる関係者の多くがが理解しておくほど進めやすくなる), 共同での勉強会の実施など
• 北⽶の組織はこれらを当たり前に踏まえて企業内で進化させている (例: 次ページLinkedInのプロダクト開発の考え⽅。
LEAN Starupをベースにしている)
• 製品開発プロセスの理解
• 開発チームとして、スクラム開発などのアジャイル開発⼿法を学ぶことは役に⽴ちます
• プロトタイピング開発
• ハッカソン形式、UXD、User Research
• いつ何ができるの? (⻑期 / 直近)
• 進捗状況のメンテナンス、プロダクトバックログの共有・策定とメンテナンス
• オープンなロードマップの策定 (ロードマップを開発チームだけのものにしない)
• 全体のロードマップを可視化・共有・把握する (= オープンであれ)
• PM側からのセールス状況・顧客への歩み寄り
• セールスチームの意⾒をまずは受け⽌める、そこに重要な課題が隠れていないかを徹底的に洗いだす
• 仮説検証 (価値仮説と成⻑仮説) と⾰新会計
17. How to Build Lovable Products Using Data by LinkedIn Sr. PM
https://www.slideshare.net/productschool/how-to-build-lovable-products-using-data-by-linkedin-sr-pm
(参考): LinkedInのPMの考え⽅
18. PM x セールス橋渡しのために、、、プロトタイピング
• 100のアイディアより1の動くもの
• バッドなアイディアを早く捨てられる (=学び)
2つの⽅法論 (必要に応じて検証フローの取り⼊れ)
1. XD等利⽤したモックとフィードバック
2. ハッカソン形式でのプロトタイピング (次ページ)
19. cf. ハッカソン形式でのモノ作り ~ 2⽇でモノを作れ
• 世の中を変えるのは引き続きアイディアとエンジニアリング
• アイディアソン → チーム横断(セールスとエンジニアなど)で結託し
て2⽇でアイディアをプロトタイプ実装 → プレゼンテーション → 審
査
• 「2⽇でモノを作る」意義
• 本当にやりたかったことの根幹だけにフォーカスできる (焦点を
ボカす余計な機能が乗らない)
• 2⽇でなんとなくでも作れないものは、そもそも作れるか懐疑的
(技術者の現時点での能⼒を越えている)
• 2⽇で刺さらないものはこれ以上かけても刺さらない
• ハッカソン形式でアイディアを試すことも取り⼊れよう (もし社内に
エンジニアリングチームがあるなら)