Yappli さん本社に遊びに行きたい！という一心で PdM という畑違いの勉強会に参加してきた。
イベントページ：https://yappli.connpass.com/event/373235/
畑違いとはいえ、いちサービス開発に関わる身としては頭にいれておくべき内容で良かった。特に、AI 活用してリーンに MVP 開発するというプロトタイプ思考は、Vibe Coding 時代だからこそあらためて実践したいと思った。
素敵すぎるボトル。
元起業家PdM、AIで”爆速MVP検証”を実現した話
リャオス さん
- クロスセル、価値拡大は 0→1
- エンジニアリソースを使って検証する余力なく、一発で当てたいが、検証なしで始めるリスクは大きい
- 小さく始めてしまう
- 1週間でMVPプロトタイプ
- 競合調査：DeepResearch
- (MAツールの)代表的な機能リストを作成：Cursor
- 機能イメージができてくる
- プロトタイプ構築：v0
- MVP検証
- ユースケース検証
- 0→1の壁が消えた
- リーン：顧客に聞け、正解は顧客が知っている（マーケットイン）
- 0 to 1：顧客に聞くな、競合せず独占しろ（プロダクトアウト）
- AI エンジニアを使って、エンジニアが作ったのと同等の精度で検証可能
- 顧客の優しい嘘
- アイデアに対して「ぜひ欲しい！」と、使う立場としてのニーズは違う
- MVP いきなり作って渡すことができる
- 顧客ヒアリングの時間が取れない問題
- 「リアルな拒絶」を早めに引き出す
- 開発フローの再定義
- リーンスタートアップにおけるBMLループのどれもはしょれず、ただ爆速になっただけ
- 「学習」もサボれない：なおいっそう頑張るポイント
Yappli流！「プロダクト改善」の進化といま
仲道 さん
- プロダクト改善の推進
- 要望、アイデア、技術負債の解消
- 改善がなかなか進まない
- チケットが減らず増える
- 工程が進まないチケット
- プラットフォームごとのリリースがばらける
- 問い合わせに追いつかない
- チケットが進まない原因：量、優先度、担当者不在、何度、リソース不足
- 改善要望がリリースよりも多くなりやすく、避けにくい。この溝が深くなると、
- 改善されていないことでチャーンする
- 多部署からの信頼低下
- 開発チームのモチベ低下
- 解決方法
- チケット残数の把握、認識を揃える、担当者を把握するなど、PdMがチケット診断者になる
- チケット状況を把握する
- PdM内で対話型の確認会（一人では無理）、判断軸をログとして記録して残す
- やらないものを決める
- 一定期間経っている、要望の熱が冷めている（要望が出続けているものはニーズ高いと判断）
- 呼応数見積により区分分け、大規模開発は「改善」から移動。アサイン待ちになってしまうため
- ブラックボックス化していたチケットボードをPdMがハブになり要望の集約、状況確認、共有
- 優先順位、増減傾向が明確
- やるべき のみがあるチケットボードの健全化
- 他部署連携がスムーズになり、調整コストを減らせた
- フロー整備だけでなく、社内周知でメンバーへの浸透も