DecisionBee
DecisionBee は engineering RFC と technical decision workflow 向けの developer tool experiment でした。創業者は素早く出荷しましたが、customer conversations の結果、target users は既存の Docs、GitHub、GitLab に十分不満を持っていないと分かり、約 1 か月で停止しました。
元のストーリーを見るプロダクト概要
何だったか
DecisionBee は engineering RFCs と technical decisions を書き、共有し、管理するための dedicated workflow tool でした。
誰のためか
課題 / 価値
general documents や issue trackers より focused な RFC workflow を teams に提供すること。
中核ワークフロー
teams が RFCs を書き、technical options を議論し、engineering decisions を dedicated workflow で管理する。
中核依存
創業者のコメントでは、interview した teams は Google Docs や GitHub/GitLab の RFC workflow に満足していました。
プロダクト形態
競合または代替手段
何が起きたか
概要
創業者は engineering RFCs 専用 tool が見つからなかったため DecisionBee を始めました。
結果
創業者は、target customers にとって problem が十分 important ではなかったため、約 1 か月で shut down したと述べました。
中核リスク
Weak Switching Motivation
終了理由
interviews では既存の Google Docs や GitHub/GitLab workflow で十分だと分かり、switching motivation が弱かったこと。
作る前に確認すること
なぜ重要か
DecisionBee は RFC-style decision workflow を狙った developer tool experiment でした。pre-build question は、engineering teams、tech leads、product-engineering groups が既存の tools から移行するほど頻繁で強い痛みを持つかどうかです。
主な確認事項
dedicated RFC tool に投資する前に、teams が既存の Docs や Git workflow から切り替えるほど強い不満を持つかを検証してください。
チェックリスト
- この problem の budget owner は誰か。
- buyer が毎週または毎月この workflow を使う trigger は何か。
- engineering teams に one-off launch spike なしで届く channel は何か。
- Weak Switching Motivation を早く発見できる evidence は何か。
- どの engineering segment が最初に支払うのか、なぜ今 urgent なのかを定義する。
- workflow が購入に値する頻度で起きることを確認する。
- launch traffic ではなく、engineering teams に届く acquisition channel を 1 つ検証する。
- buyer が Google Docs、GitHub issues、GitLab から切り替える理由を書き出す。
参考になる場合
- engineering teams や tech leads 向けの workflow tool を作っている。
- 既存の Docs、GitHub、GitLab より focused な RFC workflow を売りにしている。
- useful という反応はあるが、paid repeat use や switching intent は未確認。
参考になりにくい場合
- すでに paying teams が RFC workflow を繰り返し使い、更新や拡張をしている。
- 社内 mandate があり、external go-to-market risk がない internal tool である。
開発前テスト
- 少数の engineering teams に RFC workflow を manual で提供する。
- next version の前に、buyer から payment、renewal、dated pilot のいずれかを得る。
- non-launch acquisition channel を 1 つ試し、page views ではなく qualified conversations を数える。
- offer を Google Docs、GitHub issues、GitLab と並べ、今切り替える条件を聞く。
応用できる学び
- engineering teams が useful と言うだけでなく、workflow に支払うかを検証する。
- Weak Switching Motivation を最初に検証すべき assumption として扱う。
- more features の前に Google Docs、GitHub issues、GitLab と並べて比較する。
今作るなら
dedicated RFC tool を作り込む前に、engineering teams が Google Docs、GitHub、GitLab から本当に移行し、継続利用や支払いをする理由を確認してください。