プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか

81
株式会社ビズリーチ 丹野瑞紀 プロダクトマネージャーにたちはだかるを、 どう乗り越えるか Kaizen Platform × BizReach プロダクトマネジャーセミナー 2015/10/09

Transcript of プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか

株式会社ビズリーチ 丹野瑞紀

プロダクトマネージャーにたちはだかる壁を、 どう乗り越えるかKaizen Platform × BizReach プロダクトマネジャーセミナー 2015/10/09

プロダクトマネジメントとは

市場

プロダクト

プロダクトマネージャーの仕事とは

http://www.amazon.co.jp/gp/product/4883353389/

クリエイティブディレクションの4つのステップ

1.ミッションの発見

2.コアアイデアの確定

3.ゴールイメージの共有

4.アウトプットの クオリティ・コントロール

こんな製品開発プロジェクトは嫌だ

エンジニアは二人なのに優先度Sの要件が100個ある。

この機能とこの機能は次のリリースでMustです。

こんな製品開発プロジェクトは嫌だ #1

その機能、本当に必要ですか?

あるメーカーの製造現場の話

従業員が転びやすい階段がある。

「マッキンゼー流-入社1年目問題解決の教科書」p.50を元に作成

様々な対策

• 階段に滑り止めをつける。 • 「転倒注意」の張り紙を貼る。 • 階段の手前に警告灯をつける。 • 朝礼で注意を促す。

ある作業員の一言

焦って小走りになっている時に転ぶんだよなー

転倒の原因

生産の遅れを取り戻すために、 焦って小走りになると転ぶ。

対策

作業動線を見直し、階段を登らずに 次工程に部品を渡せるようにした。

その結果

移動によるロスがなくなり、生産性も向上。納期前に辻褄合わせもなくなった。

真因を探ることで、対策を4つから1つに

• 階段に滑り止めをつける。 • 転倒注意の張り紙を貼る。 • 階段の手前に警告灯をつける。 • 朝礼で注意を促す。

• 作業導線を変える。

その機能はなぜ必要?

その問題はなぜ発生する?

システム思考の「氷山モデル」

現象

時系列パターン

構造

メンタルモデル

参考:http://www.change-agent.jp/news/archives/000031.html

階段で転ぶ作業員が多い

納期近くなると転倒が増える。

納期直前は作業員が作業導線を走る。

「少しでも遅れを取り戻したい」

階段を登らないで済むように作業導線を変更する

様々な種類の開発要件

1. 売上やKPIへのインパクトが大きいもの

2. サービス継続上のリスクに関わるもの

3. 既存顧客の要望を満たすもの

4. オペレーションコストを下げるもの

既存顧客をないがしろにするとどうなる?

1. BtoBプロダクトでは、84%が紹介によって購買プロセスが開始される。

2. サブスクリプションモデルでは顧客満足度が契約継続のキーとなる。

3. サポートや営業など顧客接点となる部門のオペレーションコストを低減することが、サービス品質向上につながる。

http://www.slideshare.net/takaumada/startup-customer-success-support

フェーズに合わせたリソース配分を考える

2 6 2戦略的機能追加 ユーザー要望

への対応スケーラビリティ や不具合の改修

: :

フェーズに合わせたリソース配分を考える

1 1 8戦略的機能追加 ユーザー要望

への対応

: :スケーラビリティ や不具合の改修

フェーズに合わせたリソース配分を考える

6 3 1戦略的機能追加 ユーザー要望

への対応

: :スケーラビリティ や不具合の改修

限界まで考え抜いたら 最後は腹をくくって割り切るしかない

仮説検証サイクルの1イテレーションである

弊社のクレドの一つ

マッハGO!GO!

ベンチャー企業はスピードが命。 誰もが驚くような圧倒的なスピードを追求していこう。

走りながら考え、考えながら走り、どんどん改善を加えていくこと。

このプロセスを誰よりも早く繰り返していくことで、 世の中の期待を超える最高のサービスが生まれる。

迷ったときはまずは行動、GO!GO!精神でいこう

http://www.bizreach.co.jp/corporate_info/principles/

課題のレベルで優先度を判断できているか

課題A

課題B

課題C

機能1機能2機能3機能4機能5機能6機能7機能8機能9

部門X

部門Z

部門Y

優先順位を納得してもらえない時はどうするか

ロードマップ化して実現時期を約束する

課題B

機能4 機能5 機能6

課題C

機能7 機能8 機能9

課題A

機能1 機能2 機能3

t

はっきり言ってそのユーザー課題を解決するのは無理

東京から大阪まで30分で 移動したい!

こんな製品開発プロジェクトは嫌だ #2

課題解決の手段をロジックツリーで考えると

東京から大阪まで 30分で行きたい

新幹線を使う

タクシー

ヘリをチャーターする

バリューグラフで「そもそもなんで?」を考える

東京から大阪まで 30分で行きたい

新幹線を使う

タクシー

ヘリをチャーターする

30分後に大阪で会議がある

Skype会議をする

Why How

ユーザーが何を求めているのかわからない

特に不満はないです

こんな製品開発プロジェクトは嫌だ #3

使ってくれなかったユーザーの話を聞く。

サービス退会理由や カスタマーサポートのログは宝の山

自分がユーザーならどうするか。

あなた自身 本来のターゲット

あなた自身 本来のターゲット

あなたとターゲット顧客にはどのような違いがあるのか。 違いを踏まえるとサービス設計

はどうかわるか?

あなた自身 本来のターゲット

自分自身が製品のターゲットユーザーではなく、 ユーザーの気持ちがわからない時は?

私たちのサービスの特徴

• 「ハイクラス・エグゼクティブ向け転職サービス」というある意味ニッチな層がターゲットで、身近にターゲットとなる人間が少ない

• サービスの性質上、求職者の立場では「ドッグフーディング」しにくい。

構造が同じ他社サービスを使ってみる。

ぶっちゃけ競合の方が高機能

オレがユーザーならあっちの製品を使うけどね。

こんな製品開発プロジェクトは嫌だ #4

「もし自社の製品がなくなって、 競合他社の製品しか選択できなくなったら、

どんな人が困るだろうか」

丹野のチェックリスト

1. 自分がユーザーならどうするか。

2. 同じ構造の製品はないか。

3. もし自社の製品がなくなったら、誰が困るか。

偉い人が考えた機能がイマイチ

この機能があれば 絶対売れる!

こんな製品開発プロジェクトは嫌だ #5

「それはいいアイデアですね!」

「偉い人案件」の対応のコツ

1. やる前提でコミュニケーションする。

2. ユースケースや仕様を詳細化する。

3. 詳細化の過程で明らかになった課題を解決するためのアイデア出しを偉い人に協力してもらう。

4. 難易度の高さや効果が限定的であることがわかってくる。

5. 代案を出す。

これを繰り返すと信頼を得られる。

部下のイマイチな発案でも同じ対応が有効。

個社ごとにカスタマイズ対応が必要

お客さんがこの機能があれば絶対買うって言ってる!

こんな製品開発プロジェクトは嫌だ #6

短期的な売上が目的の機能ばかり優先せざるをえない。

2Qの売上目標を達成するために、この機能は必ず追

加してください

こんな製品開発プロジェクトは嫌だ #7

開発マネージャーと気が合わない

その機能は作る意味があるとは思えません。

こんな製品開発プロジェクトは嫌だ #8

信頼が欠如したチームでは、 良い製品は絶対に作れない。

エンジニアからの信頼を損なう 言動をしていませんか?

エンジニアを怒らせる5つのコツ

1. 「これくらいの機能なら1日で出来るでしょ。」

2. 「こうすれば簡単に実装できるんじゃない?」

3. 「他社はできているんだからうちも出来るはず。」

4. 要件の背景を説明しない。

5. テスト直前やリリース直前に追加仕様を詰め込む。

エネルギー保存の法則

顧客課題の解決にかけるエネルギー

チームコミュニケーション上の課題解決 にかけるエネルギー

あなたのエネルギー

必要な機能が実装できない。

開発工数が3倍かかります。それは作れません。

こんな製品開発プロジェクトは嫌だ #9

あるサービスの例

「メッセージの検索機能は作れません」

「作れない」のはなぜ?

「メッセージの本文はKVSに格納されているので、本文を全文検索することはできません。 (差出人と件名はRDBに格納されているので検

索可能です)」

「件名と差出人名で検索できれば十分です!」

暗黙の前提や誤解がないか確認しよう。

テクノロジーに興味を持ち、 食わず嫌いや苦手意識をなくそう。

要件通り、仕様通りに開発が進む

言われた通りに作りますよ

こんな製品開発プロジェクトは嫌だ #10

「この仕様だと矛盾が生じるけどまあいいか」

「3人のレンガ積み職人」の話

旅人が、ある町を通りかかりました。 汗を流してレンガを積んでいる職人に出会いました。

http://www.withsmiles21.com/761.html

「何をしているのですか?」

「親方の命令で、レンガを積んでいるんだよ!」

「レンガを1個積むと10セントもらえるのさ。 生活をするために、

レンガを積んで壁を作っているんだよ」

「私はレンガを積んで、 ここに大聖堂を作っているのです。 大聖堂で多くの人が祝福を受け、 多くの人が救われるのです」

顧客課題に共感してもらう。

デザイナーがユーザービリティを無視する

日本語のラベルがあるとダサいので、アイコンだけに

しました

こんな製品開発プロジェクトは嫌だ #11

PRや広告の内容が製品コンセプトと違う。

そのコンセプトでは売れないと思ったのでメッセージ

を変えました

こんな製品開発プロジェクトは嫌だ #12

4Pの整合性を取るのはPMの責任

Product / Price / Promotion / Place

製品はたくさんあるのに、 プロダクトマネージャーは自分一人

任せられる人がいない...

こんな製品開発プロジェクトは嫌だ #13

自分自身が一番のボトルネックになっている

もうオレには無理かもしれない

こんな製品開発プロジェクトは嫌だ #14

プロダクトマネージャーのコミュニティに 参加して、みんなで助け合いませんか?

https://product-managers-japan.herokuapp.com/

Product Managers Japan on Slack

ビズリーチではプロダクトマネージャーを募集しております

https://jp.stanby.com/ats/5dd6fcdb577d0ece63ca18c520e5ddc2b1f29c502dbc48a7aee5fc37faa19a08?order=1