SaaS 产品开发第一版，不是把完整平台做小一点。它应该先验证一个明确问题：目标客户是否愿意用这个产品完成一个核心任务。
如果这个问题还没有答案，功能越多，判断越难。用户不用，你也不知道是功能不够、路径太长，还是场景本来不成立。
先写清楚目标客户
“企业用户”太宽。要写到具体岗位：销售主管、运营负责人、客服组长、财务人员、项目经理，还是老板。
不同岗位的日常任务不同，愿意付费的理由也不同。SaaS 第一版要服务一个主角色，不要同时讨好所有人。
核心任务要短
第一版最好让用户在几步内完成一件事。录入线索、分派任务、查看状态、生成报告、处理审批，都可以是核心任务。
如果一个用户第一次使用就要配置十几个模块，通常太重。先让他看到结果，再逐步引导更多设置。
账号和组织要早设计
SaaS 产品天然会遇到账号、组织、团队、角色和邀请。就算第一版只有少量用户，也要知道数据属于个人、团队还是公司。
多租户边界尤其要提前想。客户之间的数据是否隔离，管理员能不能跨组织查看，内部运营能看到什么，都不能等上线后再补。
运营后台是必需品
没有运营后台，SaaS 上线后就会很被动。用户有没有注册、有没有完成关键动作、哪里报错、哪个组织需要支持，都要能看。
第一版后台可以简单，但要能管理用户、组织、核心记录、配置和异常。这样后续迭代才有依据。
计费可以后接，结构要预留
早期 SaaS 不一定马上做支付，但套餐、用量、功能开关、席位数量这些概念最好先预留。价格没有确认时，不要在公开页面写死。
预留不是过度设计。它只是避免后面接付费时推倒账号和权限模型。
- 第一版必须清楚：目标客户、核心任务、账号组织、权限、后台。
- 可以后置：复杂计费、开放 API、复杂报表、自动化工作流。
- 不要承诺：固定增长、固定转化、固定交付周期和未验证市场结果。
上线后看真实使用
SaaS 产品开发的第一版上线后，要看用户是否回访、是否完成核心动作、是否在同一步卡住、是否愿意继续沟通。
下一版不要只按最初想象排。真实使用会告诉你，应该补功能、改流程，还是重新定义目标客户。
先别急着做很多角色
B2B SaaS 很容易一开始就设计老板、主管、员工、管理员、代理商、客户等一堆角色。角色多不代表产品成熟，反而会让第一版的权限和页面变复杂。
第一版可以先围绕主使用者和必要管理员设计。只要能完成核心任务、能看关键数据、能处理异常，就足够开始验证。
多租户不是技术名词而已
多租户影响的是客户数据归属。不同公司之间的数据能不能互相看到，内部运营能不能代客户处理，删除账号后数据怎么保留，这些都不是后端小问题。
如果产品未来面向多个客户，租户边界最好在第一版就定下来。即使功能少，数据边界也不要含糊。
别用管理后台替代产品反馈
后台能看到数据，不等于知道用户为什么不用。第一版还需要记录关键动作，比如注册、创建、提交、邀请、导出、报错。数据不需要一开始很复杂，但要能回答“用户卡在哪里”。
SaaS 产品开发的早期价值，不在于页面数量，而在于每一版都能缩短判断周期。上线后如果没有观察点，下一版仍然只能靠猜。
邀请和权限会影响增长
B2B SaaS 的传播经常发生在团队内部。一个人觉得好用，想邀请同事一起用。如果邀请流程、组织归属和权限不清楚，产品很难自然扩散。
第一版不一定做完整增长体系，但至少要知道新成员怎么进来、默认看到什么、离职或移除后数据怎么处理。
别把所有配置都开放给用户
早期 SaaS 常想把规则都做成可配置。配置太多，用户反而不知道怎么开始，后台也更难维护。第一版可以把高频、确定的规则做死，把少量关键项留给运营配置。
配置能力要跟着真实客户需求长出来。还没有客户验证前，过度配置只会增加复杂度。
给第一批用户留反馈入口
SaaS 第一版上线后，反馈入口要简单。用户遇到问题时，能直接提交截图、描述和联系方式。早期反馈不需要复杂工单系统，但必须有人看、有人整理、有人决定是否进入下一版。
产品越早接触真实反馈，越不容易在假设里越做越重。
