这半个月内接手了两个全新的产品任务，均为自己比较陌生的领域。在原始需求一团模糊，甚至只是由领导转述的情况下，没有一点点防备地来到我面前。
话说回来，产品汪遇到类似时间紧、任务重、没有头绪且不熟悉领域的新产品，算是工作道路上的大概率事件。反而是一路顺顺当当按照教科书的产品设计流程做下来，最终取得胜利大家举杯相庆的情况寥寥无几。希望这篇文章对面临同样问题的朋友有所帮助。
三个关键词：短时间、陌生、0到1
1、了解需求
“XX想做个什么什么样子的产品，你看看整理一下，过几天带材料过去沟通”。
这话是不是有些耳熟？是的，我们很有可能碰上这样所谓的“需求”，尤其是在用户为大型企事业单位，最开始不便直接沟通的时候。这次我也不例外，这2个新产品一个是从领导处直接口头传达，另外一个是市场人员转发的看完满是黑人问号的业务说明书。
由于时间要求紧，不可能留有充分的调研时间，但即便如此也还是需要从消息源了解最基础的3个问题：
1、用户是谁
2、解决什么问题
3、核心场景
接下来，在搜索平台或应用市场根据关键字筛选出同类产品。一个新需求新产品，95%以上的产品已有与他们相近的同伴了，我们通常不需要重新制作轮子（虽然也有例外，比如其中一个是国企单位内部定制型产品，相似的平台并不多见，至少在网络上）。
将认为典型的功能、页面、流程等碎片信息快速收集（自己习惯用onenote），先广撒网粗筛一遍，选择10个以内最具代表性的同质产品，准备开始针对性细化梳理。
细化分析过程中，将高频出现的模块及功能点快速列出，先不要去分别排序什么的，因为目前只是描绘整体轮廓的阶段，先要圈定出大致的功能范围。
2、梳理产品结构
也就是俗称的搭“产品功能框架”。个人是用思维导图或Execl，或是二者一起，将产品最核心的模块、功能点归类整理，形成初步的产品概要面貌。
注意的有两点：
1、抓高频使用场景功能
2、站在最核心用户群角度
这个过程如同搭房子的打桩一般，第一点很好理解，类似于找出地基中心桩。场景分析是必要的设计流程，也是产品经理的思维方式，这直接决定了一个产品的价值。
第2点则是在产品有多角色用户时需要着重考虑。举个栗子：比如某个产品是物业社区类，那在梳理产品结构时，我会按照业主客户端->物业客户端->物业管理后台的优先顺序依次进行需求梳理。再从这几个用户群视角去考虑他们最迫切想解决的问题是什么，之后将这些问题一一对应到可以解决的功能点上。大致是一个树形结构的思维方式，将大而广的问题化为小而精的功能点。
顺便说一点，我们在梳理移动端产品时，往往也需要同步设计管理后台，后端设计一般是在前端基本完成后再开始进行。原因很简单：后端是为前端服务的，前端展示的内容，决定了后端应该对应输出什么样的数据。因此管理后台通常也是由各类数据的汇总及分类、业务流处理、权限角色、数据字典等支撑性功能组成。
另外，之所以选择思维导图或EXECL作为产品结构文档，是因为字不如表，表不如图。可视化的内容会让人相对容易接受。在初期的产品输出中，尽量避免用一堆洋洋洒洒的文字，不利于表达也不方便后续沟通和调整。
3、与用户讨论，细化调整
这样在短时间内（可能是3天，也可能不到24小时），基本可以拿出一份不至于太离谱的产品结构图，同时通过之前2个步骤也基本了解该产品的使用场景及典型功能。但这还仅是“形似”，要想做让其具有真正可用性，还是得和最根本的需求源头沟通确认，不断纠偏、调整、细化。
在与产品A的用户面对面沟通时，发现他们是将平台定位为一个综合性和专业性都较强的施工管理型平台。与从市场人员反馈的平台规模存在不小偏差。同时对方也说明，虽然他们想要的功能很多，但目前只有若干个模块是迫切需要的。以此为基础，大致明晰了产品成型过程中的实现优先级。
产品B的发起方是一家信息化服务商，负责人的一家合作伙伴已在该领域进行了近1年的调研和数据收集，这就可以为我们完善产品、提高实用性上提供重要的参考依据，不至于让我们在“想当然”的路上越飘越远。
在和用户需求沟通或是调研时，最好先带上自己的想法，哪怕想法暂时很浅薄。如果时间允许，带上两套以上方案，让人做选择题总比问答题更容易，而且更容易聚焦问题。
4、产品设计、沟通、调整
根据与用户面对面沟通的关键信息，调整先前的产品结构图，细化功能列表，同时开始做产品原型图，从最常用最核心的几个功能页面做起（流程图等前期各种配套工作就不一一赘述了）。
比如产品层级有个4,5,6,7级，那就别先去纠结这些过于子级的页面内容，先把经常在用户眼前出现的页面设计出来。也别太过于去纠结诸如按键长什么样、摆放位置、滑动手势等细节（只是说不要花太多时间，而非完全不考虑），我们总得先把地基打好再考虑房子得用什么样的窗户。
快速做出几页关键原型图后，和需求方确认，若认可则以此为基础继续细化。之后再次沟通、调整、细化……不断完善产品一个个页面原型，开枝散叶，这是一个由表及里，由浅及深的迭代过程。
5、输出1.0版
自己做PRD实际上就是用Axure，在原型上写明对应的交互说明、功能注释、各类规则等，在原型目录上根据页面层级命名，而没有加页面跳转等交互。一来加动效意味着需要大量的时间，在后期修改时候所耗费的精力更是指数级的；二来，开发往往不知道哪些按键有交互动作，让他们一个个点过去也不现实。
如果涉及到合同签订，我也会做一份WORD版的需求说明书作为合同文件之一。产品在实际开发过程中，程序猿自然更愿意看原型（其实很大概率上他们更爱看着UI效果图做）。不要觉得产品汪写文档很辛苦，其实看的人也同样辛苦……
产品经理输出PRD后进行需求评审会，评审会后根据会上讨论意见修改、上传SVN，在平台上发布本次版本要做的需求，之后项目经理会将需求转为一条条具体任务安排至每个成员，并对技术细节进行把控。团队内部目前用的项目管理平台是禅道（之前也有用过JIRA等），现在有很多跨平台、轻量级的任务管理软件也很适合小型团队。
产品1.0版通常只是个Demo的模样，需要在用户侧和团队内部小范围试用，然后再修改PRD、开发、测试、发版本等一轮又一轮地为产品勾勒出真实的样貌。
一些题外话
首先得说明，以上产品过程完全不是标准的“从0到1”的模板。什么样算是标准呢？书上一般这样描述：
先是需求调研、可行性报告、项目启动会、需求分析、产品设计、UI/UE设计、测试用例、研发等等等等。
但很多时候，理想化的过程只会描述路的样子，而没告诉你这路上有多少坑。等你看过一摞子书籍教程，憋红小脸充满干劲，明天可能就丢来一个任务：
“哎，市场那边说有个大客户想做个XX系统，你赶快设计个产品方案呗！对了，明天就要。”（微笑摊手）
嗯，听过很多道理，依然过不好这一生。
不同企业团队的运作模式千差万别，所遇到的产品形态更是光怪陆离。你也不用说“艾玛你这个产品流程不正确啊！”正确的都是教科书上的，对于产品而言，只有方法，没有答案，因而也注定不会存在套路化的产品养成方法。
我们看过那么多设计流程、思维方式、实战操作、各种原则和经验教训，目的是为了将来碰到的时候，就不会……以同样姿势再踩一次坑。当然也不是学习无用论，毕竟当你懂得判断了，犯的错就会减少，犯的错少了离成功的路自然更近。
也欢迎大家留言分享你在各种刮风下雨艰苦环境下的产品从0到1之路，让我们开开眼界，彼此腹黑嘲笑，共同成长呗。
