$30 off During Our Annual Pro Sale. View Details »

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

funakoshi
October 26, 2021

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

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

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

funakoshi

October 26, 2021
Tweet

Other Decks in Business

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. 01
    スピードは大事…

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  32. なぜ?ビルドトラップ…
    32

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  44. 理論<実行

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  50. 理論<実行

    View Slide

  51. 理論<実行<覚悟

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide