目的が明確な製品へ
顧客が何を達成する必要があるかを定義します。
最初のリリースには、登録から実用的な作業の完了まで、一貫した流れが必要です。その流れに基づき、導入案内、ワークスペースの設定、アカウント権限、サブスクリプションのルールを設計します。必要な利用体験とその裏側の管理業務を整理し、顧客と製品の運営チームの両方を考慮した公開判断を支援します。
初期段階のアイデア、すでに有効性を確認した業務フロー、次の開発内容が決まっている既存プラットフォームのいずれからでもご相談いただけます。
プランとサブスクリプション
料金体系を、プラン別の利用権限と課金処理に落とし込みます。試用期間中、プラン変更後、更新に失敗した場合の動作を、顧客と管理者に表示する情報も含めて定義します。
- プランと機能の利用権限
- 課金サービス連携
- 試用、更新、解約
業務プラットフォーム開発
製品の中心となる、繰り返し行う作業を開発します。レコード、担当者、承認、レポートをつなぎ、利用者が業務フローを完了し、現在の状態を把握できるようにします。
- 製品の中核となる業務フロー
- 関連する業務レコードの連携
- 承認と業務レポート
アカウントと管理機能
個人顧客、組織、またはその両方に対応する製品構造を設計します。導入時の手順やチームの権限とともに、アカウント管理や問い合わせ調査に使う管理画面を構築します。
- 組織・ユーザーアカウント
- 導入案内とチームの役割
- 製品管理ツール
連携と製品の継続開発
製品に必要な外部サービスを接続し、計画した段階に沿って機能を拡張します。合意した利用指標と顧客の意見を参考に、次に検討すべき変更を判断します。
- 外部サービス連携
- 製品の利用状況の測定
- 機能追加と改善
製品利用の流れの例
新しいチームを、最初の有用な成果へ導きます。
チームで共有する依頼を管理するサブスクリプション型プラットフォームを想定します。アカウント所有者がワークスペースを作成し、同僚を招待して役割を割り当てた後、チームが最初の依頼を完了します。また、試用期間の終了、メンバーの離脱、アカウントのプラン変更についても、動作を定義する必要があります。
- 製品の価値を示す、最初に完了すべき作業を特定します。
- 組織アカウントの所有権と、個々のユーザー権限を分けて考えます。
- アカウント変更、解約、データ出力のルールを定義します。
- 登録アカウント所有者が組織のワークスペースを作成します。
- 準備同僚を招待し、必要な役割を割り当てます。
- 完了チームが最初の中核業務フローを実行します。
- 次へ利用権限は、アカウントの契約とプランのルールに従います。
仮想的なSaaSの業務フローです。アカウントと課金の動作は、製品ごとに合意して定めます。
製品開発の進め方
最初のリリースに、現実的な範囲を設けます。
範囲を絞ることで、機能を追加する前に意味のある評価を行いやすくなります。
最初のバージョンを定義する
想定する利用者、繰り返し行う作業、収益モデルを明確にします。必須の利用フローを整理し、公開時に必要な要件と、後から追加できる機能を分けます。
お渡しする成果物製品の開発範囲とリリースの優先事項一連の利用フローを構築する
中核となる業務フロー、アカウント制御、管理ツールを開発します。導入時の手順、日常的な利用、契約変更を確認し、顧客が支援を必要とするケースも検討します。
お渡しする成果物評価可能な製品リリース公開し、優先順位を決める
デプロイと運営手順を準備します。合意した利用指標とユーザーの意見を確認し、得られた知見を製品改善の優先順位に反映します。
お渡しする成果物公開計画と優先順位付き開発バックログ
SaaSのアイデアからMVPを開発できますか？
はい。MVP（実用最小限の製品）は、明確に定めた顧客層が主要な作業を完了でき、そこから学びを得られるものであるべきです。運営に必要なアカウント、課金、管理機能も含め、最初の開発範囲を一緒に定めます。
複数の企業が同じSaaS製品を利用できますか？
組織ごとに独立したアカウントを持つ設計が可能です。データ、招待、役割、サブスクリプションが各組織にどう属するかを定義し、開発とテストにアクセスのシナリオを含めます。アーキテクチャは製品の要件に応じて決定します。
既存のSaaSプラットフォームに機能を追加できますか？
はい。変更を定義する前に、関連するアーキテクチャ、アカウントのルール、利用フローを確認します。特定の連携や製品機能に取り組むことも、広範な改善を管理しやすいリリース単位に分けることも可能です。
次のステップ
最初の顧客に、何ができるようになってほしいですか？
製品のアイデア、想定利用者、現在の段階をお聞かせください。次のリリースの範囲を一緒に整理します。