2018/09/08 Sales x PM Meetup @LINE

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、 #週末ハック、 #ソーシャル広告、#ナオハイダ

3. プロダクトマネージャー(PM)としての⾃分の経験・失敗談
• 2017年に、当時までエンジニアから唐突に事業を任された
• ビジネスのことが分からない / 広告業界なので⾃分よりマーケティングに詳しい⼈間が沢⼭いる
• リソースが⾜りない、成功している会社の組織構造を真似できない
こんな失敗ありました:
• プロダクトの製品管理責任者は誰?
• エンジニアがUI/UX決めた結果使いづらい
• セールスチームが仕様を決めた結果、特定顧客専⽤になってしまった
• ⾃分より業務に詳しい⼈の声を鵜呑みにしてしまう「こういうものがあれば..」「こういう⾵にして...」
→ 年を経るごとにちぐはぐなプロダクトに
← 製品責任者(プロダクトマネージャー)がいない OR 機能不全

4. 1年半ほどの経験・失敗を通して分かったこと
• 売れる製品を作るチームにはできる優秀なPM(プロダクトマネージャ)が必ず存在
• セールス > PMしか経験なし (というかPM組織がないところからスタート) いかに組織を横断した
形でのモノ作り⽂化を醸成するか?を勉強する必要があった
• ダメな製品が無駄に世に送り出される原因: 会社の中でプロダクトマネージャー(PM)の
役割が明確にされていないこと、プロダクトマネージャーとなる⼈に対する教育が不⼗
分なこと
• 製品の中⾝に関わるべきなのはPMだけでもエンジニアだけでもない:
• 「売れる」製品とは: しかるべきものを (PM)、いいクオリティで (Engineer)、しかるべきタイミ
ングで (Marketing)、沢⼭の⼈に (Sales)
• PMと製品開発に必要な役割をどう連動させて開発を動かしていくか? ← 今⽇ここ

5. PMのない組織にPMを作るまで (勉強材料)
• Inspired: 顧客の⼼を捉える製品の創り⽅
• ゼロ・トゥ・ワン
• リーンスタートアップ
• Startup way
• スクラムガイド

6. ありとあらゆるリソースが⾜りない! / 適材適所でない!
⼩さい会社にありがちなこと
• リソースが潤沢にない、適材適所にリソースを使えていない、アイディアはそれなりにある
起きる(起きた) こと:
• 得意領域を中⼼にしたリソース配分
• なんとなく「偉い」上司がいて全ての最終決定権を担う。
• エンジニアリング以外の分かりにくい部分は全て「偉い上司」 。なので実質PMもする。
• ただし、事業が⼤きくなると「偉い上司」は「製品を考える業務」(PM) にリソースが割けなくなってく
る
• エンジニアが製品設計をすることで、UX調査がなされていなかったり、業務知識に不⾜があるので「売れ
ない」製品になる、エンジニアがエンジニアリングに注⼒できない不幸
• セールスチームが製品設計をすると、特定顧客への課題解決となっており、カスタムコードが量産される

7. 製品開発には考
えなければなら
ないことが沢⼭
…
(分担しないと
無理…)
Product ManagerとProduct Ownerの役割の違いについて
https://www.slideshare.net/noritakashinohara/product-managerproduct-owner

8. 製品開発をするチームに必要な4つの役割
• よい開発 (エンジニア/UI)
• よいProduct Management
• 製品の市場性を評価、開発すべき製品の定義
• 製品要求とユーザーエクスペリエンスデザインを組み合わせて、製品のプロフィールを決める責任
• ここにUXチームを含める
• よいMarketing (製品の語り部)
• 製品を世界中に知らしめること製品の外装を決めること
• 販売チャネルから製品を売り込むためのツールを提供すること
• オンラインでのマーケティングや市場関係者に対する製品のマーケティング
• よいSales (売り⼿)
• どの顧客にアプローチするのか、どの顧客に当たるのか?
これらの役割それぞれが四権分⽴であること
どれもが⽋けることなく、どれもが互いに均衡を保つ (x可能な限り役割をオーバーラップさせない) ことが⼤事

9. なぜ役割をオーバーラップさせることがNGか?
例えば... PMが考えるべき課題 (by マーティケイガン.Inspired:顧客の⼼を捉える製品の創り⽅)
1. (市場性の評価)製品化によって具体的にどんな問題を解決 する のか？
2. (バリュー プロポジション) だれのためにこの問題を解決しようとしているのか？
3. (ターゲット市場)市場の⼤きさは？
4. (市場規模) 製品化の成功をどうやって評価するのか？
5. (指標、 収益 戦略) 現在、 他に競合する製品はあるか？
6. (競合の⾒通し) なぜ当社がこの製品化をやるのに最適なプレーヤーと⾔えるのか？
7. (差別化要因) なぜ今なのか？
8. (市場投⼊の時期)
→ それぞれの役割に応じて、セールスならば、「どの顧客にアプローチするのか」「その顧客の課題は何か?」「どの顧
客にアプローチして売上を達成するのか」「会社が存続するためのセールス⽬標と進捗は?」、エンジニアならば、、、
マーケティングならば、、、といった質問に答えていく必要がある
ある程度組織が⼤きくなってくるととても兼任はできない上に利益相反があるので、責任者を分担しないと組織としてベ
ストな解を出しづらくなってくる

10. 「PM」という役割を会社内に置く
• あらゆる製品には責任を持たされたプロダクトマネージャー1⼈が必要
• 各プロダクトマネージャーは、製品を定義する責任 (製品要求とユーザーエクスペリエン
スデザインを組み合わせて、製品のプロフィールを決める責任) を負っている
• 役割の設置と役割に対する組織の理解 がファーストステップ
cf. PMはセールスに従うべき? またはセールスはPMに従うべき? (⾃分の意⾒)
• 「四権分⽴」のなかの2つのファンクションであるべきでありどちらかが従属するべきも
のではない均衡を保つべき (という⽴場です)
• もの作りをいかに各チーム横断して進めていくか?、が鍵 (まずは意識から + ⽅法論)

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の視点から製品に落とす (優先度、
解決の仕⽅等含め⼀旦持ち帰る。そのまま実施する必要は本来はない)
• どうしても⼗分な議論をしても決着しない場合
• プロトタイピングでの検証
• ⻑期的な投資が必要な領域は仮説・検証プロセス
• 検証が必要な場合は検証に無駄な時間をかけない → リーンスタートアップなどの⽅法論

14. 組織醸成も⼩さく始めてスケールさせる
• ⽂化醸成は時間がかかり、かつ、既存組織をいきなり変えるのは相当難しい
• 可能であれば、細部までコントロール可能な組織作りそこでベストプラクティスを作っ
て既存組織にフィードバック
• 正しい⽅法論、必要な役割が揃った⼀体組織で結果を出す
• 正しいやり⽅をしていると割とすぐ結果は出てくる

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⽇で刺さらないものはこれ以上かけても刺さらない
• ハッカソン形式でアイディアを試すことも取り⼊れよう (もし社内に
エンジニアリングチームがあるなら)

20. まとめ
• 製品開発は関わるチーム全員が同じ⽅向を⾒るように整備していく。その整備の責任はPM
• どのような役割が組織に必要かをまず認識する (PM, Engineering, Sales, Marketing)
• 特に⼩さな会社では組織の⽴ち上げから始まるので何の役割が必要で、どうやってカバーする
かを検討する
• 役割をオーバーラップさせると専⾨性が育ちにくい & 利害も相反するので、可能な限り早い
段階でそれぞれに別の責任者を置く
• PMとセールスの橋渡しをする体系化された⽅法論が沢⼭あります、組織で学んでいく

21. ご清聴ありがとうございました!