アプリのアイデアを実際の SaaS 製品に変えるテナント モデル、アカウント、権限、サブスクリプション、資格、サポート、リリース パスを計画します。
製品を明確に定義できるが、最初のリリースが従来の開発キューによってブロックされることを望まない創設者とドメインの専門家。
- 顧客との明確な約束が 1 つあるバージョン 1 の SaaS スコープ
- 安全なアカウントとテナント モデル
- 同期を保つ請求とアクセス ルール
SaaS プロダクトは機能の集合ではありません。これは、多くの顧客が同じコア ワークフローを通じてアクセスできる結果です。顧客の名前、苦痛な仕事、そして顧客が価値を受け取る瞬間の名前を挙げてください。バージョン 1 ではそのループに重点を置いてください。
アカウントが 1 人の個人に属するか、1 人の会社に属するか、あるいはその両方に属するかを決定します。招待、役割、所有権の移転、データ分離に関するルールを作成します。すべてのクエリと自動化はテナントの境界を尊重する必要があります。発売後にこれを改造するのはリスクがあり、費用もかかります。
中心的なタスクを完了するために必要な情報のみを尋ねます。役立つ例、賢明なデフォルト、および目に見える次のステップを提供します。サインアップだけでは製品の適合性についてほとんど意味がないため、新しいアカウントが価値に達するポイントを追跡します。
プラン、試用ルール、使用制限、アップグレード、ダウングレード、支払いの失敗、キャンセル、返金を定義します。支払いプロバイダーからの Webhook は資格レコードを更新する必要があり、製品はそのレコードを確認する必要があります。インターフェイス全体にプラン名のチェックを分散させないでください。
顧客は、パスワードの回復、データのエクスポート、アカウントの削除、請求書受領書、およびサポートへの連絡方法を必要としています。オペレーターには、監査履歴、安全な偽装、失敗したサブスクリプション イベントを修正するためのツールが必要です。これらのパスにより、デモと人々が信頼できるサービスが区別されます。
同じユースケースを持つ数人の顧客を招待します。オンボーディング、最初の価値が得られるまでの時間、繰り返しの使用、サポートに関する質問、キャンセル理由を観察します。隣接する市場や長い機能リストを追加する前に、コア ループを改善してください。
はい、健全なデータの分離、権限、請求状態、可観測性、およびコードとデータの出口パスがあれば可能です。ビルド方法によって製品エンジニアリングの責任がなくなるわけではありません。
1 つの貴重なワークフロー、アカウントとテナントの分離、重要な権限、信頼できる請求資格、復旧パス、基本的な分析、およびサポート連絡先。
はい、有料ベータ版です。手動請求書では早期に支払う意思があるかどうかを検証できますが、自動アクセスは最終的にプロバイダーが確認した支払い状態に従う必要があります。
認定された新規アカウントの数が最初の意味のある結果に達し、コア ワークフローを繰り返すために戻ってくる数を測定します。