帯の短い製品

振り返りの契機

下記のように感じたメモがSlackにあったので、振り返る。

結果的に多要素認証を使うユースケースを社内に絞ったけど、多要素認証単体だと顧客の課題解決に至ってないって感じだったのかな振り返ると。toCにしろ社内にしろ帯短かった気がする。これについてはもう少し振り返ろう

NGだった理由

これはクリアだった。大体以下。

• 担当者がいないので当然予算もない。
• 担当者がいないので、他の仕事に比べて相対的に優先度が下がる。
• toC担当者に売るにはtoC向けに売るように、担当者の業務に最適化する必要があった。

結果的にリスクベースとかDynamicRuleってソフトウェアのコアは同じだけど、toC/toBともに担当者の業務上の要求に答えうるには製品の価値（とそれを支える機能）が不足していた。今目下実装しているのはtoBのソレだし、toCでも担当者（事業責任者）にとっては計測とか他の業務上成果だす価値が不足してたという事。

メモ：現状把握している顧客の課題

顧客の顕在課題はリモートワークなど複雑な労務状況に対応できる体制になってない事。直接的な原因は継ぎ接ぎのシステム構成、複雑な業務要件（関係性や権限に応じたセキュリティ）に適応できない代替手段。

根本的な原因

ITリソース（予算と人材）の無さ。リソースがないと継ぎ接ぎのシステムで、SIが丸っとやらないと全社的なソリューションの導入が進まない。導入するソリューションは大体SI主導なので入れて満足。大抵は定着が進んでいるのか、ROIを満たしているのかをそくていせずに導入前の提案通りにはなっていない。

SMB向けのマーケットプレイス事業を売却後、エンプラ向けのSaaSをやってます。元エンジニア：Ruby / Go / Nuxt / ReactNative