toto_1212

技術のログをツラツラ書きます。自分用ですが参考にしていただけたら嬉しいです。間違ってたらドンドン突っ込んでください。

【勉強会】世界に羽ばたく!! Product Manager Night

6/4にスマートニュースさんで開催された「世界に羽ばたく!! Product Manager Night」の
メモです。smartnews.connpass.com

最前線で活躍されているプロダクトマネージャのテック話、思想論、考え方等のお話が
聞けて大変勉強になりました。

以下メモです。

SmartNews

Ads プロダクト担当ディレクター 渡部 拓也さん
NativeアプリにおけるProduct Management ~ 点・面・線 ~

www.slideshare.net

人生はゲームみたいなもの

・パーティにはいろいろなキャラが必要
  戦士とか僧侶とか、、、プロダクトマネージャは勇者キャラだと思ってる
・例えばInngressレベルはある程度のとこまでは簡単だけど、そこを越えると
 上げるの大変。
 プロダクトマネージャはそのメダル(プロダクト戦略、業績)を獲得して人

スマートニュースに置けるプロダクトマネージャ

エンジニアの上位職種の位置づけ
(決してエンジニアより偉いとかそういう事ではない)
より上に上がるための選択肢(ダーマの神殿的な)
 ・プロダクトマネージャになるか
 ・スーパーエンジニアなるか

SmartNewsのMAUは417万人(国内No.1)
月間総訪問時間は1,335時間(第1位)
全米ニュースアプリNo,1(1,200万DL突破)

メディアとしての見せ方も意識している。広告だけではない。
SmartNewsがどういうプロダクトで、どういうメディアで、どういうユーザーが
居るのか等を考えながら、広告も考える。
両局面を考えるのが非常に大変。
・メディアとしてはクリックされれば儲かる。
・配信事業者として考えると、広告主からすればクリックされてインストール
  してもらわないと困る。

点・線・面を意識している。
3つに分けた理由は??
問題の粒度に応じて意識するポイントを明確に分割。思考の統治分割。

広告の表示
・画像サイズ
  記事レイアウトで動的に決定。表示保証領域は守る
・文字
  長短2種類の文字データを入稿
  動的に使用する文字を選択
・クレジット
  広告主名を広告表示と併記

点の極意
一つのボタン、一つの文字列、魂は細部に宿る

点だけだとネイティブには足りない気がする。

点(view/矩形)のstackとしてのpage
pageとpageをつなぐLink

ネイティブにおける面
縦(上下)スクロール → 右にスワイプ → 左スワイプ → タップ

何が言いたいのかというと、、、
Transitionが大事

Transition
SmartNews全体を張り出す(スライド 31ページ参照)
実際に動かしてイメージする。閲覧領域を確認する。
でっかいスクリーンをスマホの穴で探索するイメージ
・広告が過大に見えすぎたりしてないか?
・想像する見た目になっているか。

記事の抽出/配信を行うシステム
記事のURLをインターネットで探索してきて見つけてきて、構造解析/構文解析をして
どのくらい重要な記事かを推定、Diverslfcationと呼ばれる処理をする。
例えば東京オリンピック決定の記事が出ると各メディアが一斉に書く。
それでスポーツ関連の記事を開くと東京オリンピック開催決定っていうだけの記事では
つまらないので、同じようなこが書いてある記事を並ばせないような選定をする。

広告の仕組みはユーザの行動ログと広告の配信実績を噛み合わせて特徴ベクトルを作る
フィルタリングにはさまざまな制限があり時間帯や1日あたりの配信量等、配信していいもの
以外をはじく。
利用ユーザーにとって何がよい広告なのかを独自のアルゴリズムを使って計算している。
配信結果のログから学習もする。

広告を含むコンテンツ編成 適切なユーザに適切なコンテンツ配信を行う
コンテンツへのアクセスを提供

ユーザから見える画面は平面。
奥行きがある面のイメージして作っている

GOALに続く面の進化

Executionとは
・ひたすらProductについて決断
・良質なlterationをまわし続ける
・Teamにwhy(背景、決断理由)を伝える

Product Managerをスタートアップでやる意味は?

時間という概念が加わる
 → いつまでに市場のどのポジションを取るのか
  

スピードが大事。では何にBetするのか?

例えばマージャン。最終回で1万点必要なのに5千点しか取れない手であがっても
仕方ない。
勝つためには1万点に鳴る可能性がある中で最も高い確率のもの選択する。
勝つ手の中で最大の可能性にあるものに賭ける。

そうはいってもツラくなる時もある。

起死回生のアイデア、一発で逆転できるようなアイデアは無いかと思う。
でも、それは無い。銀の弾丸は無い。
通常の玉をたくさん撃ちまくるしかない。(でも無駄打は注意)

エンジニア出身のProduct Managerが気をつけた方がいい事

・自分が無力である事をちゃんと認識する
・納期、品質を自分の経験を基準で考えない

Product Managerとして腕を磨くエクササイズ

・筋トレ(リアルな筋トレとは別)
 → センスは磨くもの。
・良質なサービスやProductに触れ続ける。
 → 続けないとダメ(筋肉が落ちる)
・街中Elevator Pitch
 → しゃべるチャンスがあったら「Do you know SmartNews?」
  (サンフランシスコでやった)
  いきなり話すので30秒くらいしか無い。
  短い時間でどのような説明をしたのか、すればいいのかを考える
  結果、Uber運転手がインストールしてくれた。

街中Elevator Pitchのコツ

話聞いて貰えないとダメ
フックになるようなネタを仕込んでおく(腕時計を左右2つ付けるとか)www.itmedia.co.jp

CyberZ

OPENREC事業部 開発局局長兼プロダクトマネージャー 中村 智武さん
ネイティブマーケティングカンパニーにおけるProduct Manager
プロダクトマネージャの心得の一例

www.slideshare.net

商売の基本サイクル

創って、作って、売る(V字回復の経営)
CyberZの共通言語になっている。

Product Manegerは「創って、作って、売る」をまわす責任を持つ事
ミッションは携わっているProductを市場でNo1にする

創って:ロードマップを引き、開発項目を決定する
     →ビジネスを分かってないと話にならない
作って:開発体制を組織し、マネージメントする
     →技術を知ってないと話に鳴らない
売る:価値を正しく市場や顧客に届ける
     →プロダクトの価値を分かってないと話にならない
求められる事の幅が広い。

創って → 作って → 売る これをしっかりと矢印を邁進させる

作る

・エンジニアの採用と育成には全責任を持つ
  →作る上でも人は大事
・技術セットは幅広く抑えておく
  →それぞれの技術セットがどう使われていて、どう活用されているかは
   把握する
・時間を見つけてコードを眺める、出来れば書く
  →Productの本質的に深く理解するのはコードを知るのが早い

売る

・売る=自分で営業もする、ではない
  →自分と同じ事をはなせる人間(営業)を作る
・機能説明をする人には決してならない
  →機能ではなく、顧客が何を求めて自分たちのプロダクトがどう活用できるか
・同じ話を社内の全員が出来る状態を目指して頑張る
  →覚えてもらうではなく理解してもらう

創って

・ハンズオン、ハンズオン、ヒアリング、ヒアリング
  →自分の足でクライアントのもとへ行き、自分で聞く
・自分だけでは限界があるので、情報が集まる組織に
  →全部出来る訳ではないので、情報があつまるようにする
・そして、市場が求めてるものだけを開発する
  →答えを誰も持ってない事が多い
・「これは今は創らない」という開発の断捨離をして開発スピードを上げる

創って、作って、売る会議

・プロダクトサイドとセールスの会議
  情報共有の場ではなく、Productの良さが市場に届けられているかの管理
  顧客からフィードバックを貰う。

結論

・プロダクトマネージャはプロダクトにおける「何でも屋さん」
・エンジニア出身がなるべきポジション
・やりがいは最高です

DeNA

取締役 最高技術責任者 川崎 修平さん
自分はプロダクトマネージャではないですがプロダクトよりの開発者として
思ったきたことなどを

www.slideshare.net

エンジニアのキャリアパス

スペシャリスト路線
・プロダクト路線
・マネージャ路線
・その他

プロダクトに関する要素

主な構成要素
事業戦略(ビジネスセンスがいいか)
・プロダクト(DeNAの場合は容れ物な事が多い)
  品質/出来映え、サービス清澄戦略、分析、、、
・コンテンツ(ゲーム等)
・マーケ
・営業(どういうトークをしたらいいか)
・マネタイズ

事業にとってのそれぞれの構成要素の重要度は異なる
出来るだけ広い分野の知識があるにこした事無いけどすべての理解の必要は無い
っていうか無理
しかし、プロフェッショナルが考えている事をやいってる事を理解できる事は重要

余談
分析の目的
 定性的な分析
  ユーザー心理の理解
  気づいていなかった需要への気づきのきっかけ

 定量的なもの
  仮説が正しかったのか検証
  成熟期におけるセサく効果最大化
定量的なもの関しては結果が理解できればいいが、定性的な部分は自分で
見た方がよい

プロダクトマネージャまで目指さなくても

当然ながらプロジェクトマネージャかそうでないかの2択ではなく、中間という
選択肢もある。
職人的な品質・保守性を追求する立ち位置と、サービス成功を追求する立ち
位置と、その中間と。
実際のところ、プロダクトの全責任を負いたいエンジニアは少数派だと思う。

エンジニア経験とプロダクト

エンジニアとしての経験がプロダクトにどう生きるか
プロトしながら現物見て品質改善できるので、凡人でも品質を高める事が用意
 →天才的な想像力が無くてもいける。
ともかく話が早い
 →こんな事したいって伝えるとその要求に対して最大公約数的なサービス設計が
  出来る

エンジニアであるが故の悪癖

・無意識に面倒な実装を避ける
・エンジニア目線で嫌な出来映えの部分はリリースしたくない時もある
 →ディスられるのとあった方がいいと思う機能の葛藤
・あとで対応できる事を後回しにしてしまう

以下、自分の立場やチームでサービスを立ち上げる時に大事にしている事

・チームは事業の目的に対して同じゴールを持っている
 → ここが出来ないとうまくいかない。成功したチームを見た事が無い
・ゴールが達成された世界のわくわく間を共有している。
・互いの専門性を尊重して、お互いの観点から率直な意見交換ができる
 → エンジニアだからプログラム書く、営業だから営業だけやります、とかあるが
  事業のゴールを目指す事が第一義である。本当は営業やりたいけど能力無いから
  営業は任せますみたいなスタンスで仕事できるとお互いハッピーになる。
  互いの意識を尊重し合える。
・プロダクトに一貫性を持たせポイントがずれないようにするために、最終決定は
 明確なオーナーが責任もって意思決定する。
 → 一貫性が無いと話が伝わらない。最終的には誰かが責任もって一貫性持った
  世界観できちんとやる。
・成功イメージが描けるまでは見切り発車してチームを動かすのはいけない。

魂感じるプロダクト

・魂の籠ったプロダクトは、何か伝えたい意思がユーザー側に肌感覚で伝わる
 → 納期ギリギリでやったんだなぁとか、こんなことしたかったんだろうなぁ
   みたいなのは伝わる
・細々としたテクニックはあると思うが、最重要なのは一貫した明確な製品ビジョンを
 持ってものつくりに取り組む事
 → どういうプロダクトを届けたいのか。一貫性。
・焦点がぼけるくらいならあった方がベターな仕様でも切った方がいい
 → 伝えたい事をユーザーにきちっと伝える。
・あと、寝る時間にどれだけ触ってるかとか。
 → 開発の時間を外れてる時に触ってると気づく事がたくさんある。
  開発者の立場で要件見ながらやってると気づかない事でも離れると気がつく事が
  ある。
・とりあえず一番伝えたい事は何か?
 → 人に伝えれているときをイメージする。

フェーズにあわせたプロダクトの変化

アーリーアダプターに刺さるフェーズ
 割り切って一番響くと事に特化した尖った設計
 おおらかにする事でシンプルな設計
  → まだ誰も使ってないのにセキュリティ・個人情報ガチガチに作っている。
    まだ流行っても居ない段階でガチガチにしないようにしている。
・マスに広げるフェーズ
 ローンチ時にアーリーアダプター特化した仕様のうち、この規模の規模になると
 有効に機能しない or 支障になる壁は切り離す。
・収益化のフェーズ
 → 手が離れるフェースなので分からない。

課題

個人がプロダクトを主体的に持ちながら計画的に仕事を進めるのは個人的には
まだまだ課題が多い

GREE

取締役執行役員 荒木 英士さん
Engineering出身Product Managerの強みと弱み

私なりのProduct Management

・Lead team
 → チームを成功に導く
・Drive project
 → プロジェクトを成功に導く
・Make Product
 → プロダクトを成功に導く(沢山のユーザー、沢山の収益)

Lead team

・プロジェクトマネージャの仕事
ビジョンを打ち出す
メンバーを集めチームを作る
メンバーのパフォーマンスを最大化する

・エンジニア出身だと、、、
テクノロジへの情熱、企画書ではなくプロトタイプ
エンジニアは技術がわかるリーダーを好む
課題への理解と対策の精度が高い
 

Drive project

・プロジェクトマネージャの仕事
プロジェクトマネジメント
チーム内外との協調・協同
問題発見、解決

エンジニア出身だと、、、
開発行程の理解、リスクやボトルネックをスケジュールか
オブジェクト指向とか役立つ(気がする)
何が起きてるのか理解しやすい。エンジニアを応援できる。

Make Product

プロジェクトマネージャの仕事
ユーザー理解と課題定義
プロダクトデザイン
実装、Growth、$$$

エンジニア出身だと、、、
テクノロジの歴史と展望に基づいた膾炙増を描ける(?)
Cutting Edgeな技術により実現可能なinnovativeなアイデア(が出るかも)
開発にもGrowthにもマネタイズにも技術理解は欠かせない

私が大事にしている事

誇りに思えるもの以外リリースしないこと

そんないいことばかりではない

エンジニア出身だからこそ失敗したこと

企画発想が自分の実装能力に縛られる
開発工数見積もりが自分ベース(過少・過大)
エンジニアが書いたコードを上書きしてキレられる

他社製品・サービスを買うより自分で作りたがる(Not Invented Here症候群)
NIH症候群 - Wikipedia