[pmconf2021]受託開発に強い会社が、新規プロダクトをリリースし、短期間で撤退判断に至った失敗談、赤裸々に全部話します。

by funakoshi

Slide 1

Slide 1 text

受託開発に強い会社が、新規プロダクトをリリースし、短期間で撤退判断に至った失敗談、赤裸々に全部話します。 2021.10.26 株式会社Fusic 1

Slide 2

Slide 2 text

受託開発に強い会社が、新規プロダクトをβリリースし、短期間でほぼほぼ撤退判断に至った失敗談、赤裸々に全部話します。 2021.10.26 株式会社Fusic 2

Slide 3

Slide 3 text

Fusicについて 3 多角的な事業 × 働きやすい文化（福岡の会社です！）エンジニア7割約80名の組織受託とプロダクト

Slide 4

Slide 4 text

自己紹介 4 船越将一 Masakazu Funakoshi 株式会社 Fusic （フュージック）プロダクト部門 sigfy チームリーダープロジェクトマネージャー Twitter：@Funako_sikao 安河内舜 Shun Yasukochi 株式会社 Fusic （フュージック）プロダクト部門 360(さんろくまる) チームリーダーコンサルタント

Slide 5

Slide 5 text

【PMとして初歩の初歩のお話】受託開発に強い弊社が、プロダクトマネジメント１年生としてやっちゃった失敗談の共有です… 5 本日の内容 toB 初心者向け失敗談・教訓

Slide 6

Slide 6 text

撤退したサービスについて frAAAt(ふらっと）とは… オンライン展示会／学会が開催できるWebサービス 6

Slide 7

Slide 7 text

frAAAt開発のポイント • 「具体的に困っている」という顧客の声を中心にスタートした • ミニマムで開発し、素早く学会で活用された（MVP？） • コレまで使ったツールの中で一番使いやすかったと評価された（PSF？） 7 ※PSF：プロブレムソリューションフィットイケる！

Slide 8

Slide 8 text

残念ながら簡単には売れない… 8

Slide 9

Slide 9 text

今日、これだけ持ち帰ってくださいポイント１スピードは大事…、でもとにかく早く実装しろってことではない！ポイント２自社プロダクトは甘くない、だからこその必要なアレ！ 9

Slide 10

Slide 10 text

01 スピードは大事…

Slide 11

Slide 11 text

素早く世の中に出せるって正義だよね！！ 11 開発会社でありがちなこと…

Slide 12

Slide 12 text

３つの罠 ①顧客の口からでた必要な機能の罠 ②ミニマム開発はMVPじゃない罠 ③共同開発という無料提供の罠 12

Slide 13

Slide 13 text

①顧客の口からでた必要な機能の罠ちょうどよいオンライン学会用のツールがない機能が多くて使いこなせないから、アレ、コレ、ソレぐらいが入ったツールがあるとありがたい 13 ちょっとボリュームが大きいですね最初はアレ、コレくらいでどうでしょう？使いやすくできると思いますあー、ちょうどよさそうですね！

Slide 14

Slide 14 text

①顧客の口からでた必要な機能の罠（受託開発的に）目の前の顧客が欲する機能をただつくっていくのは超NGです。 14

Slide 15

Slide 15 text

①顧客の口からでた必要な機能の罠目の前の顧客が欲する機能＝世の中的にもある程度欲され、多くの場合何かしら作られている機能＝プロダクト独自の価値になりにくいもの 15

Slide 16

Slide 16 text

リーダーチャレンジャーニッチャーフォロワー ①顧客の口からでた必要な機能の罠 16 小規模な会社では特定の誰かにすごく刺さるニッチャーをまず狙いたい顧客の口からでた必要な機能は競合多数であり価格競争の世界へ陥ることが多い競争地位別戦略

Slide 17

Slide 17 text

課題発見を急ぎすぎていませんか？ 17

Slide 18

Slide 18 text

②ミニマム開発はMVPじゃない罠 18 ●月×日の学会でなんとか使いたいのですが…。そこに間に合うようにやりましょう。ミニマム開発でいきます。

Slide 19

Slide 19 text

②ミニマム開発はMVPじゃない罠 19 その開発、本当に必要ですか？

Slide 20

Slide 20 text

②ミニマム開発はMVPじゃない罠 • MVPは「コアとなる価値を提供できるか？」など仮説検証するために必要なもの • 「顧客による必要な機能」で構成されたツールの場合、検証すべきコアの価値がなく仮説検証の余地は少ない 20

Slide 21

Slide 21 text

②ミニマム開発はMVPじゃない罠その状況下でのミニマム開発は、品質を上げること＝差別化・優位性と考えやすく開発ボリュームも膨らむ傾向がある。（細部にこだわり、ミニマムはミニマムでなくなる） 21

Slide 22

Slide 22 text

②ミニマム開発はMVPじゃない罠顧客にとって品質は最終段階での比較であることが多い。まずは、潜在ニーズ・コアの価値を発見することに注力する。 22

Slide 23

Slide 23 text

作ることを急ぎすぎていませんか？ 23

Slide 24

Slide 24 text

③共同開発という無料提供の罠 24 たくさんのフィードバックが欲しいです。無料でよいので学会で使ってください。予算も少ないので助かります。共同開発の気持ちで全力で協力いたします。

Slide 25

Slide 25 text

③共同開発という無料提供の罠 25 無料提供で得られるフィードバックが今本当に必要ですか？

Slide 26

Slide 26 text

③共同開発という無料提供の罠 • 「無料で満足してくれたもの」と「高いお金で満足してくれたもの」は全く別 • 無料でしか使われない程度のニーズなら、そもそもPMFしない 26

Slide 27

Slide 27 text

③共同開発という無料提供の罠 27 共同開発でも希望する売値に近い費用はもらうべきです。でなければ、その後のプライシングや市場判断に遠回りすることになります。

Slide 28

Slide 28 text

使われることを急ぎすぎていませんか？ 28

Slide 29

Slide 29 text

前半のまとめ ①顧客の「コレください」を鵜呑みにするのNG ②仮説検証に必要なMVPですか？大事なのはコアとなる価値の検証。 ③安易な無料提供は、その後苦労する 29

Slide 30

Slide 30 text

前半のまとめ ①課題発見を急ぎすぎる ②作ることを急ぎすぎる ③使われることを急ぎすぎる 30

Slide 31

Slide 31 text

前半のまとめ 31 いいの作ればきっとに売れる課題発見してないのに企画書の期限が短い… 使う技術のみが先に決まってる ①課題発見を急ぎすぎる ②作ることを急ぎすぎる ③使われることを急ぎすぎる

Slide 32

Slide 32 text

なぜ？ビルドトラップ… 32

Slide 33

Slide 33 text

受託開発とプロダクト開発の世界 33 リリースプログラミング詳細設計基本設計要件定義要求定義＜よくある受託開発＞目の前に課題があり、課題解決のソリューションがわかりやすいことが多い。素早いアウトプットが収益につながる。オーダーメイドで目の前の人が求めた価値になればOK。

Slide 34

Slide 34 text

受託開発とプロダクト開発の世界 34 リリースプログラミング詳細設計基本設計要件定義要求定義＜プロダクト開発＞受託開発ではあまり意識しない部分に重要な要素が多く存在する潜在ニーズの発見世界観・ビジョンの設定挑戦と仮説検証の繰り返し販売チャネル確立改善と仮説検証の繰り返し真のユーザーの定義ポジショニング判断

Slide 35

Slide 35 text

受託開発とプロダクト開発の世界 35 すでに世の中にあるソリューションを素早く丁寧に作っても世の中に新たな価値を提供しづらい ≒ 価値のない開発（アウトプットの世界）実現したい世界観への到達課題解決にインパクトあるものを作り世の中に新たな価値を提供できる ≒ 価値のある開発（アウトカムの世界）

Slide 36

Slide 36 text

絶対に違うアクションの順番 frAAAtでは本当はこうありたい… 36 仮説検証インタビュー分析運用構築一つの課題仮説検証インタビュー分析課題の特定運用構築

Slide 37

Slide 37 text

02 プロダクト開発は甘くない…

Slide 38

Slide 38 text

事前にもっとやれたこと… 最低限リーンキャンバスくらいは作っておきたい… 38 ・顧客は本当に明確？・顧客のニーズにそうプロダクトならではの価値はある？・優位な販売チャネルある？

Slide 39

Slide 39 text

事前にもっとやれたこと… 最低限、競合把握しておきたい… 39 ・競合がある中でも、意味あるポジショニングできてる？・ビジョンと狙う場所って噛み合う？・競合がいない場合、本当に市場はある？

Slide 40

Slide 40 text

事前にできることはたくさんあります。一方で、調べたり、考えたりするだけではやはり足りません。 40

Slide 41

Slide 41 text

顧客や市場を知るまでヒアリングぶん回す… 41 とにかくアクションの連続です

Slide 42

Slide 42 text

仮説の確からしさをガンガン検証する • ユーザーインタビューで反応をみて、仮説内容を調整 • 未実装機能をLPでアピールし、問合せの反応をみて内容を再度調整する 42

Slide 43

Slide 43 text

徹底的なヒアリング！仮説検証の繰り返し！ 43

Slide 44

Slide 44 text

理論＜実行

Slide 45

Slide 45 text

仮説検証を繰り返して補正補正補正… インタビューや営業施策を通して顧客や市場を知り… 45 こういう繰り返しは、プロダクトマネジメントとしては重要な工程補正補正補正 CORE ビジョン Why 課題 What 解決策世界観誰をどの状態に何で

Slide 46

Slide 46 text

繰り返すことでみえてきたもの… 46 ・会社のビジョン含めて考えると…作るべきものが違う… （弊社ビジョン”人に多様な道を世の中に爪跡を”）・やっと決めたプロダクトビジョンを実現するならイチから構築をやりなおした方がいい… etc…

Slide 47

Slide 47 text

繰り返すことでみえてきたもの… 47 撤退… ・会社のビジョン含めて考えると…作るべきものが違う… （弊社ビジョン”人に多様な道を世の中に爪跡を”）・やっと決めたプロダクトビジョンを実現するならイチから構築をやりなおした方がいい… etc…

Slide 48

Slide 48 text

[再掲]絶対に違うアクションの順番 frAAAtでは本当はこうありたい… 48 仮説検証インタビュー分析運用構築一つの課題仮説検証インタビュー分析課題の特定運用構築ここで撤退判断できると低リスク

Slide 49

Slide 49 text

インタビューや仮説検証の繰り返し… いわゆる「産みの苦しみ」はなかなかにしんどい 49 仮説検証インタビュー分析

Slide 50

Slide 50 text

理論＜実行

Slide 51

Slide 51 text

理論＜実行＜覚悟

Slide 52

Slide 52 text

その領域の課題を全力で改善しつづけ、全力で進めるための覚悟はありますか？ 52

Slide 53

Slide 53 text

非連続な世界におけるプロダクトスピード感はめちゃくちゃ大事… ≠ 構築を急ぐことではありません。世界観設定・インサイトの発見など近道のない探索こそ覚悟とスピード感を持って行いたいものです。 53

Slide 54

Slide 54 text

今日、これだけ持ち帰ってくださいポイント１スピードは大事…、でもとにかく早く実装しろってことではない！ポイント２自社プロダクトは甘くない、だからこその必要な覚悟！～基本のプロダクトマネジメントの知識の習得・活用も忘れずに！～ 54

Slide 55

Slide 55 text

ご清聴いただきありがとうございました Thank You We are Hiring ! https://recruit.fusic.co.jp/ 自由で裁量のある組織で、一緒に働いてみませんか？？