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

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

弊社テックブログ
https://tech.fusic.co.jp/posts/2021-10-26-pmconf2021/
にて補足説明などもアップしています。

Transcript

1. 受託開発に強い会社が、新規プロ ダクトをリリースし、短期間で撤 退判断に至った失敗談、赤裸々に 全部話します。 2021.10.26 株式会社Fusic 1
2. 受託開発に強い会社が、新規プロ ダクトをβリリースし、短期間で ほぼほぼ撤退判断に至った失敗談、 赤裸々に全部話します。 2021.10.26 株式会社Fusic 2
3. Fusicについて 3 多角的な事業 × 働きやすい文化 （福岡の会社です！） エンジニア7割 約80名の組織 受託とプロダクト
4. 自己紹介 4 船越 将一 Masakazu Funakoshi 株式会社 Fusic （フュージック） プロダクト部門 sigfy チームリーダー プロジェクトマネージャー Twitter：@Funako_sikao 安河内 舜 Shun Yasukochi 株式会社 Fusic （フュージック） プロダクト部門 360(さんろくまる) チームリーダー コンサルタント
5. 【PMとして初歩の初歩のお話】 受託開発に強い弊社が、 プロダクトマネジメント１年生として やっちゃった失敗談の共有です… 5 本日の内容 toB 初心者向け 失敗談・教訓
6. 撤退したサービスについて frAAAt(ふらっと）とは… オンライン展示会／学会が開催できるWebサービス 6
7. frAAAt開発のポイント • 「具体的に困っている」という顧客の声を中心にスタートした • ミニマムで開発し、素早く学会で活用された（MVP？） • コレまで使ったツールの中で一番使いやすかったと評価された（PSF？） 7 ※PSF：プロブレムソリューションフィット イケる！
8. 残念ながら簡単には売れない… 8
9. 今日、これだけ持ち帰ってください ポイント１ スピードは大事…、でもとにかく早く実装しろってことではない！ ポイント２ 自社プロダクトは甘くない、だからこその必要なアレ！ 9
10. 01 スピードは大事…
11. 素早く世の中に出せるって正義だよね！！ 11 開発会社でありがちなこと…
12. ３つの罠 ①顧客の口からでた必要な機能の罠 ②ミニマム開発はMVPじゃない罠 ③共同開発という無料提供の罠 12
13. ①顧客の口からでた必要な機能の罠 ちょうどよいオンライン学会用のツールがない 機能が多くて使いこなせないから、 アレ、コレ、ソレぐらいが入ったツールがあるとありがたい 13 ちょっとボリュームが大きいですね 最初はアレ、コレくらいでどうでしょう？ 使いやすくできると思います あー、ちょうどよさそうですね！
14. ①顧客の口からでた必要な機能の罠 （受託開発的に） 目の前の顧客が欲する機能をただつくっていくのは超NGです。 14
15. ①顧客の口からでた必要な機能の罠 目の前の顧客が欲する機能 ＝ 世の中的にもある程度欲され、多くの場合何かしら作られている機能 ＝ プロダクト独自の価値になりにくいもの 15
16. リーダー チャレンジャー ニッチャー フォロワー ①顧客の口からでた必要な機能の罠 16 小規模な会社では 特定の誰かにすごく刺さる ニッチャーをまず狙いたい 顧客の口からでた必要な機能は 競合多数であり 価格競争の世界へ陥ることが多い 競争地位別戦略
17. 課題発見を急ぎすぎていませんか？ 17
18. ②ミニマム開発はMVPじゃない罠 18 •月×日の学会でなんとか使いたいのですが…。 そこに間に合うようにやりましょう。 ミニマム開発でいきます。
19. ②ミニマム開発はMVPじゃない罠 19 その開発、本当に必要ですか？
20. ②ミニマム開発はMVPじゃない罠 • MVPは「コアとなる価値を提供できるか？」など仮説検証するために必要なもの • 「顧客による必要な機能」で構成されたツールの場合、 検証すべきコアの価値がなく仮説検証の余地は少ない 20
21. ②ミニマム開発はMVPじゃない罠 その状況下でのミニマム開発は、 品質を上げること＝差別化・優位性と考えやすく 開発ボリュームも膨らむ傾向がある。 （細部にこだわり、ミニマムはミニマムでなくなる） 21
22. ②ミニマム開発はMVPじゃない罠 顧客にとって品質は最終段階での比較であることが多い。 まずは、潜在ニーズ・コアの価値を発見することに注力する。 22
23. 作ることを急ぎすぎていませんか？ 23
24. ③共同開発という無料提供の罠 24 たくさんのフィードバックが欲しいです。 無料でよいので学会で使ってください。 予算も少ないので助かります。 共同開発の気持ちで全力で協力いたします。
25. ③共同開発という無料提供の罠 25 無料提供で得られるフィードバックが今本当に必要ですか？
26. ③共同開発という無料提供の罠 • 「無料で満足してくれたもの」と「高いお金で満足してくれたもの」は全く別 • 無料でしか使われない程度のニーズなら、そもそもPMFしない 26
27. ③共同開発という無料提供の罠 27 共同開発でも希望する売値に近い費用はもらうべきです。 でなければ、その後のプライシングや市場判断に遠回りすることになります。
28. 使われることを急ぎすぎていませんか？ 28
29. 前半のまとめ ①顧客の「コレください」を鵜呑みにするのNG ②仮説検証に必要なMVPですか？大事なのはコアとなる価値の検証。 ③安易な無料提供は、その後苦労する 29
30. 前半のまとめ ①課題発見を急ぎすぎる ②作ることを急ぎすぎる ③使われることを急ぎすぎる 30
31. 前半のまとめ 31 いいの作れば きっとに売れる 課題発見してな いのに企画書の 期限が短い… 使う技術のみが 先に決まってる ①課題発見を急ぎすぎる ②作ることを急ぎすぎる ③使われることを急ぎすぎる
32. なぜ？ビルドトラップ… 32
33. 受託開発とプロダクト開発の世界 33 リリース プログラミング 詳細設計 基本設計 要件定義 要求定義 ＜よくある受託開発＞ 目の前に課題があり、課題解決のソリューションがわかりやすいことが多い。 素早いアウトプットが収益につながる。 オーダーメイドで目の前の人が求めた価値になればOK。
34. 受託開発とプロダクト開発の世界 34 リリース プログラミング 詳細設計 基本設計 要件定義 要求定義 ＜プロダクト開発＞ 受託開発ではあまり意識しない部分に重要な要素が多く存在する 潜在ニーズの発見 世界観・ビジョン の設定 挑戦と仮説検証の 繰り返し 販売チャネル確立 改善と仮説検証の 繰り返し 真のユーザーの定義 ポジショニング判断
35. 受託開発とプロダクト開発の世界 35 すでに世の中にあるソリューションを 素早く丁寧に作っても 世の中に新たな価値を提供しづらい ≒ 価値のない開発（アウトプットの世界） 実現したい世界観への到達 課題解決にインパクトあるものを作り 世の中に新たな価値を提供できる ≒ 価値のある開発（アウトカムの世界）
36. 絶対に違うアクションの順番 frAAAtでは 本当はこうありたい… 36 仮説検証 インタビュー 分析 運用 構築 一つの課題 仮説検証 インタビュー 分析 課題の特定 運用 構築
37. 02 プロダクト開発は甘くない…
38. 事前にもっとやれたこと… 最低限リーンキャンバスくらいは作っておきたい… 38 ・顧客は本当に明確？ ・顧客のニーズにそう プロダクトならではの価値はある？ ・優位な販売チャネルある？
39. 事前にもっとやれたこと… 最低限、競合把握しておきたい… 39 ・競合がある中でも、意味あるポ ジショニングできてる？ ・ビジョンと狙う場所って噛み合 う？ ・競合がいない場合、本当に市場 はある？
40. 事前にできることはたくさんあります。 一方で、調べたり、考えたりするだけではやはり足りません。 40
41. 顧客や市場を知るまでヒアリングぶん回す… 41 とにかくアクションの連続です
42. 仮説の確からしさをガンガン検証する • ユーザーインタビューで反応をみて、仮説内容を調整 • 未実装機能をLPでアピールし、問合せの反応をみて内容を再度調整する 42
43. 徹底的なヒアリング！ 仮説検証の繰り返し！ 43
44. 理論＜実行
45. 仮説検証を繰り返して補正補正補正… インタビューや営業施策を通して顧客や市場を知り… 45 こういう繰り返しは、プロダクトマネジメントとしては重要な工程 補正 補正 補正 CORE ビジョン Why 課題 What 解決策 世界観 誰を どの 状態に 何で
46. 繰り返すことでみえてきたもの… 46 ・会社のビジョン含めて考えると…作るべきものが違う… （弊社ビジョン”人に多様な道を 世の中に爪跡を”） ・やっと決めたプロダクトビジョンを実現するなら イチから構築をやりなおした方がいい… etc…
47. 繰り返すことでみえてきたもの… 47 撤退… ・会社のビジョン含めて考えると…作るべきものが違う… （弊社ビジョン”人に多様な道を 世の中に爪跡を”） ・やっと決めたプロダクトビジョンを実現するなら イチから構築をやりなおした方がいい… etc…
48. [再掲]絶対に違うアクションの順番 frAAAtでは 本当はこうありたい… 48 仮説検証 インタビュー 分析 運用 構築 一つの課題 仮説検証 インタビュー 分析 課題の特定 運用 構築 ここで撤退判断できると 低リスク
49. インタビューや仮説検証の繰り返し… いわゆる「産みの苦しみ」はなかなかにしんどい 49 仮説検証 インタビュー 分析
50. 理論＜実行
51. 理論＜実行＜覚悟
52. その領域の課題を全力で改善しつづけ、 全力で進めるための覚悟はありますか？ 52
53. 非連続な世界におけるプロダクト スピード感はめちゃくちゃ大事… ≠ 構築を急ぐことではありません。 世界観設定・インサイトの発見など 近道のない探索こそ 覚悟とスピード感を持って行いたいものです。 53
54. 今日、これだけ持ち帰ってください ポイント１ スピードは大事…、でもとにかく早く実装しろってことではない！ ポイント２ 自社プロダクトは甘くない、だからこその必要な覚悟！ ～基本のプロダクトマネジメントの知識の習得・活用も忘れずに！～ 54
55. ご清聴いただきありがとうございました Thank You We are Hiring ! https://recruit.fusic.co.jp/ 自由で裁量のある組織で、一緒に働いてみませんか？？