尽可能清晰详细地定义产品：包括10个主要步骤
使产品方案具体且可理解：换句话说，需要思考用什么样的文字才能非常贴切地描述出你的产品，使设计师可以借此设计原型，HR可以借此雇佣工程师，而你可以借此拿到项目经费
下面的10步为产品定义过程，参照下面的过程来定义产品，通过快速重复这个过程，你可以验证之前关于客户问题的臆断是否正确，并添加更多更好的产品特性。当迭代越小越快时，你甚至不需要花大力气去猜测客户的需求，而是更多按照客户告诉你的去做，这样成功的可能性更大。
这个阶段完成后你已经找到一个覆盖面广，重要性高的用户需求，你还提出了一个独特的解决方案。你能通过产品单页或者10分钟的演示来介绍方案，也能凭借功能规格（包括FAQ、API和依赖清单）来讲述产品的所有细节。你还努力构建了一个简陋却令人振奋的收益模型，它正是你做这块业务的原动力。
- 撰写新闻稿：
- 脱胎于策略的文章，用于促进各方了解和公开透明，包含6大要素：
- 产品命名
- 发布时间
- 目标客户
- 解决了什么问题
- 如何解决（务必简明扼要）
- CEO的公开赞词：表扬的内容正是你那套切入市场的独特方式
- 篇幅不超过一页，
- 花几天时间。
- 脱胎于策略的文章，用于促进各方了解和公开透明，包含6大要素：
- 创建并不断更新FAQ文档：内部问题和外部问题两个部分
- 用于记录一些争议点和重要细节，
- 开发过程中及上线后抽些时间更新维护。
- 绘制线框图或流程图：
- 产品的可视化描述，在讨论或答疑中使用可以让观点更明晰，
- 花1天到1周不等的时间。
- 撰写产品单页或10分钟演示文稿：完备而简洁
- 写给高管或多数风险投资人看的产品介绍文章，包括5个要素：
- 产品名称
- 目标客户 + 数量多少
- 解决了什么问题 + 这个问题对于目标对客户有多大价值
- 解决方案 + 这个解决方案类似线上哪个产品，为什么你的方案能让竞争对手在长时间内都无法模仿
- 何时交付 + 主要的里程碑有哪些？
- 团队背景（针对VC）
- 是新闻稿的延伸，增加了市场机会（用户量）、收益机会（解决方案的价值）和长期竞争优势（对手长时间内无法模仿）这三方面内容
- 演示文稿和产品单页内容一致，只是表现形式不同。
- 演示的建议：听众对你的行业都有充分的认识和独到的见解，但并不了解你要做的事情的前因后果。你演示的最佳方式是先讲用户现状，再延展开来（参考先前的五大要素），迅速把要点讲完后再留出时间供这些聪明的听众就他们关心的点刨根问底。
- 花几个小时的时间写份初稿，收集反馈并做修改，反复几次便可定稿，1～2周
- 写给高管或多数风险投资人看的产品介绍文章，包括5个要素：
- 在FAQ中添加API文档
- 产品的第一个技术触角
- 你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要存储什么数据
- API最重要的作用是明确系统的各个边界，而明确的边界有助于人们了解各类功能或输出分归哪方负责
- 花几个小时简单起草一些API，后续在工程团队的帮助下完善
撰写PRD(Product Requirements Document, 产品需求文档)，功能规格文档
它是用来详细描述用户应该如何体验产品的文档 不包含系统在后台如何运行之类的技术细节，这些包含在技术规格或设计文档中
- 功能详情以及为什么要有这些功能，包含以下九个内容块
- 简介（使命和策略）
- 目标和非目标
- 用例或用户场景
- 用例是指用简要的语句来描述那些用户必须执行的操作
- 用户场景则是指用叙述故事的方式来描述用户是如何体验产品的
- 每个核心任务都会描述成一个类似下面的用例：作为视频聊天参与者之一，我希望能【共享我的屏幕给其他视频聊天参与者】。
- 优先级
- P0：没有该功能无法演示
- P1：没有该功能无法交付
- P2：锦上添花的功能 - 通常标上V2前缀表示会在V2中实现
- P3：哈哈哈！
- 原型图或线框图
- API
- 负载规划
- 依赖
- FAQ和开放问题：将它们的链接放入功能文档中
- 关键事件：列出主要事件的达成时间，如特性完成时间、可信测试者版发布时间
- 阐述产品各功能详情，以及为什么要有这些功能的最权威的文档
- 你可以将新闻稿、FAQ、线框图、产品单页和API文档等内容粘贴到功能规格文档的不同章节中,
- 还需要添加负载规划、非目标以及非常见用例（用于清晰表述FAQ中各种非常见情况的用例）等佐料。
- 几天（产品尚不成熟）还是几周（产品规模庞大且已臻成熟）
- 邀请设计团队和工程团队主管参与产品评审
- 为了获得项目组对产品的认可，并让他们帮忙寻找产品中存在的各种极端及边缘情况
- 如果团队认可你的观点则万事大吉，如果他们仍不认可，那么解决方案也很简单：重复第7步，从使命开始一步步想清楚问题到底出在哪里，然后调整产品规划直到他们认可为止
- 至少让有机会去想一想你的产品方案，否则等到猴年马月他们也未必会读你的文档
- 1天时间
- 找客户测试产品概念
- 在此阶段，你需要了解产品方案是否真正能解决客户问题。
- 做一次完整的认知走查
认知走查是指通过分析用户的心理加工过程来评价用户界面的一种方法，最适用于界面设计的初期。分析者首先选择典型的界面任务，并为每一任务确定一个或多个争取的操作序列，然后走查用户在完成任务的过程中在什么方面出现问题并提供解释。本解释摘自周荣刚和张侃所著的《界面可用性评价之认知过程走查法》一文。——译者注
- 找到现存或潜在用户，向他们介绍你的产品设想和原型，听听他们反馈
- 持续3周，每周3-5次
- 1天时间，或花数天时间进行在线调研都是不错的测试方法
- 命名、定价以及预测收益
- 可以晚些时候再想这些事情，通过收益预测我会更加确信我的产品能给投资人带来回报
- 产品命名。你需要一个客户喜欢的、能注册商标并通过版权审查的名称，后者可以让律师把关。
- 产品定价。的三个基本方法：按成本定价、按价值定价以及对比定价, 针对高科技产品的宽泛的行之有效的建议:
- 分析竞争对手，对比定价
- 调研客户愿意支付多少钱购买产品
- 简化初始定价以降低用户理解成本
- 把满足需求的定价再提高一些，推出后涨价比较难
- 收益模型。一个科学地拍脑袋出来的东西，构建一个简洁的收益模型：
- 估算买家总体市场规模：收费模式（免费增值、直接收费）、分析报告能帮助你进行估算。
- 预估市场规模的增速
- 估算你的目标市场占总体市场的比率：你针对的细分市场占总体市场的比率、你可触及的固件的市场规模占总体的比率。
- 估算通过市场推广你能触碰到的用户规模：市场预算/千人印象成本(CPM, Cost Per Mile/impression)
- 预估触碰产品的人中会有多少转化成产品用户
- 找到其他用户增长渠道并加入到模型中：如“邀请朋友”机制
- 收益=产品定价x每个时期增长的用户数
- 一个名为“愤怒的山羊”游戏的例子
- 几个小时
- 向管理层汇报
- 向管理层或VC汇报你的产品
- 使用10分钟产品演示文稿来汇报，并视需要展示FAQ、线框图等
- 预售可以让管理层在公开回应你的产品方案之前先了解一些背景。技巧：
- 为了让负责决策的高管最终认可你的产品方案，你需要预先争取中间每一级老板的支持，然后让直接向该高管汇报的家伙预先顺畅地了解你的产品概念。
- 路过式预售。趁着负责决策的高管站在走廊或者倒咖啡的时候走到他身边和他聊一两分钟你想做的产品，这时候你追求的不是一个决策，而仅仅是让他知道有这么一个事
- 向位高权重的人汇报产品方案须知：
- 确保你了解产品的所有信息
- 如果不清楚，不要试着糊弄过去，继续保持你英明神武的状态并回答他们：“这点我不是很清楚，我之后会去了解一下然后给您反馈。”
- 其次他们想了解什么你就说什么，不要坚持你的顺序。
- 最后，请阅读10.4节了解并实践“综述单页”法。那些亿万富翁都喜欢这个方法，因为它可以让你就最核心的部分进行互动交流且无需浪费时间在不重要的细节上。
- 30分钟或者更长
