产品经理不是工程师，也不是项目经理，需要以用户价值和商业价值为出发点，探寻用户人性相关的需求，也就是用户为什么有这样的需求，关注用户体验，从用户价值出发策划商业模式，从全局提升产品竞争力，才能让产品在众多同质化产品种立于不败之地。
汽车其实是一个智能硬件产品
我一直想撰写一遍互联网产品经理与汽车的文章，这个想法从某著名产品经理去某汽车集团分享如何产品创新开始萌芽，到我梳理了互联网产品经理在造车新势力产品团队主要发挥的功能不足以造出创新的产品为止。
迄今又燃起我心中想要撰写产品经理有哪些底层思维是能够促使用户购买汽车像用户购买iPhone手机一样，购买了iPhone11后就期盼着购买iPhone12。
但是汽车行业就算是头部车企都难以做到，下图为笔者已经购买保时捷的朋友再次购车是否购买保时捷的截图：
不知道保时捷的产品部是否想过其用户并不愿意像更换iPhone一样一代一代跟着苹果公司的产品走。
这促使我想撰写产品思维中那些对造车产品经理影响比较深的产品思维是什么？
目前的汽车产品经理思维方式如下：
互联网汽车产品思维更多的是HMI（Human Machine Interface）思维方式。
即在汽车产品领域产品经理目前擅长的是HMI产设计方面的知识。
一般的HMI产品设计知识和流程如下
第一是产品定义:即通过用户调研，竞品分析，市场分析，通过功能定位定义产品。
第二是概念设计：即通过功能梳理有的也叫Featurelist阶段，概念发散，草图设计提取出产品创意阶段的各种创新概念。
第三层是交互设计：信息框架设计，使用流程设计，交互动效设计，想要的是实现人机（车）友好交互，实际上是仅仅在汽车上安装了很多类似安卓的智能屏显硬件。
第四是UI设计：汽车里有大屏幕，有小屏幕，对在狭窄空间内进行设计趋势分析，界面风格定义，界面设计更加友好。
第五是规范撰写: 交互规范撰写，界面规范撰写，UED培训，这点类似普通互联网产品经理撰写产品需求文档PRD。
实际上传统的汽车产品思维方式导致产品经理不是产品经理！而是一名设计师。
为什呢？因为传统汽车产品经理思考的是使得已有的汽车怎么能够更好开，开起来人机交互更美妙，或者是车子更大或者车子更小，或者更有面子而已。
产品经理不仅仅是优化产品，更应该的职责是创造产品引领用户需求，最好是新产品切入市场。
汽车产品需要新的创新，创新需要其产品经理具有新的产品思维，这种产品思维方式就是不要受到现有产品的约束，从新从用户的真实本分需求出发探索新产品的具体功能。
用新的汽车产品思维我们重新开一下人类对于汽车的本分需求，不讲面子。
1. 将人类安全送到目的地；
2.将物品安全送到目的地；
3.降低过程中的环境污染；
4.降低过程中的不良产品体验。
其中汽车产品核心的目标是将人类安全便捷的送到目的地，这么一看HMI设计的思维其实就不是汽车产品。
传统的汽车产品思维在汽车行业由于其周期长，门槛高等原因，一直处于卖方市场的状态时是可行的；
但在近几年，汽车市场由增量市场转为存量市场，竞争日益激烈，汽车生产商必须转变思维，以用户为中心，结合跨行业经验，推行新产品思维管理模式，谋求汽车产品创新以期获得市场发展空间。
汽车产品经理应具备的新产品思维
汽车产品是典型的面向消费者的产品，且研发周期长，要想产品获得成功，更需要了解用户需求，提前策划产品特性。在汽车行业，由于其对组织体系和知识的依赖性比较强，大多企业组织为矩阵式结构。为了突出产品成功的重要性，汽车行业以产品管理为组织形态的企业为重量级团队管理形式。强化项目聚焦，承诺和责任，必须整合解决方案以应对不断挑剔和专业的顾客，集成度越来越高的产品。
产品经理思维不同于以往的以产品为中心的开发思维，最重要的是引入顾客，根据顾客需求设计产品，否则以产品为中心，可能创造出技术先进，但用户无感知的产品。
当下，汽车产品经理必须秉承以用户为中心理念，熟悉各个环节语言，保证用户需求从用户中来，回到用户中去。
以市场为导向，满足用户需求并且将需求变现，实现其商业价值是汽车产品经理思维核心。
在用户需求分析时，要知道用户想的是什么，但在与用户交谈中，用户有时表达的是方案，这并不是用户真实需求。
在近两年，不管是新能源汽车企业还是常规汽车企业，开始研究场景下用户的痛点，但这只是问题级的需求。汽车产品经理需要以同理心思维找到用户人性相关的述求，才能真正打动用户内心，引起共鸣。
需求开发过程中，不能一味追求功能齐全，技术先进，要从用户使用角度出发。在众多新事物充斥的时代，快餐文化已经深入人心，对于新产品用户也希望是能快速上手，简单，实用，因此开发过程中仍然需要考虑用户的实际使用场景，简化设计，并辅以真实用户的体验评价。当产品开发完成，在营销策划阶段，产品经理需要考虑的是如何将产品的卖点传递给用户，而且能够打动用户。用户价值是重点，不能抛开用户价值来谈产品，只有在传播时从用户利益出发，才能打动用户。
产品上市后，需要不断追踪用户习惯，尊重用户习惯的前提下，思维如何从产品角度进行改进。
汽车产品经理工作职责
汽车产品经理思维最重要的是以用户为中心，从用户中来到用户中去，在整个产品管理流程中工作职责主要分为定和盯。定和盯指的是产品经理确定和监管的内容。
汽车产品经理工作职责重点在产品定义和营销策划及推广，产品开发过程中，主要保证产品按照定义开发，并时刻关注市场动态变化，判断是否需要调整产品卖点和方案，以保证产品的绝对竞争力。
汽车产品经理的能力模型
知识是人脑对客观事物的主观表征；
技能是人们通过练习而获得的动作方式和动作系统；
能力是学习者对学到的知识和技能经过内化的产物。
三者是不同维度的度量，产品经理的能力模型结合岗位职责和这三个维度进行描述。上图为汽车产品经理的能力模型。
其中通用软技能和专业技能为汽车产品经理的核心能力，根据不同级别的产品经理要求不一样。
产品经理不是工程师，也不是项目经理，需要以用户价值和商业价值为出发点，探寻用户人性相关的需求，也就是用户为什么有这样的需求，关注用户体验，从用户价值出发策划商业模式，从全局提升产品竞争力，才能让产品在众多同质化产品种立于不败之地。
产品经理不是数据分析师，也不是UI设计师，需要通过对实践来的数据具有挖掘用户隐性需求的能力，也就是用户不常常直接表达自己的观点，用户在行为中和在传播分享产品的过程中只爱分享附和他人目的是确定自己的特质。
例如，我们用户会在朋友圈常常点赞爱马仕、Dior或者其他产品，以确定自己是这种生活方式的特质。
产品思维是与时俱变的一种内容，背后的逻辑才是不变的。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>许多产品经理可能会经常面临这样的问题：公司现有资源不足以支持自己的产品设计和迭代周期，导致不得不妥协，所以导致抢资源似乎成了产品经理一种标配的能力。你是否想过，为什么你总是没有开发资源？
写在前面
这些年做产品，大部分公司总会出现抢开发资源的事情。其实这是个很正常的现象，毕竟想做的事那么多，天马行空天花乱坠，每个人都想有自己的产出，所以事情来了，需要根据一个事情的靠谱程度，资源方安排优先级。
人总是不够用的，如果刚好够用，大家都温温和和缓步安排，可能才是有问题的。或者说抢开发资源也是一个好的现象，毕竟在抢的过程中，逼迫大家需要先把事情想清楚。
但是这其中，可能有的产品或者运营会很痛苦，会觉得为什么自己总是没有资源，很多事情落不了地，我认为这是产品规划的问题。
一、为什么要做产品规划？
曾经我年少时，（虽然现在也不老），刚开始入行时候，得益于阿里大厂的很多习惯，经常会出现看师兄师姐做PPT，那时候也会听师兄们吐槽这个东西觉得虚头巴脑的，浪费时间。不过后来回过头看，才觉得这个东西的必要性。
从产品经理的角度来说，初级产品至中级产品，乃至中级产品升级至高级产品，很直观的一个点在于你可以从负责一个功能点，到一个产品，再到一个或者多个产品线。这就是一个从点到面的过程，所以当你负责的事情，从点开始，但是逐步拓宽自己的边界可以想到更大一个面的时候，也是产品程度提高的时候。
1. 所有人明确的目标——优先级的判断标准
首先产品规划一定是自顶而下的，而不是由底下负责执行同学汇总而成的。很多时候在下面的执行层是一个点的执行，可能负责好自己的事情，但不会考虑与其余产品可能的冲突。
如果一个产品涉及到多方时候，先有一个产品框架，才可以让内容不断地在框架里面增加。不会造成不到一年就发现这种产品结构或者技术架构没办法容纳更多的情况，又要重构导致的调整。
每个人也会知道我做的这一件事，对于整体会造成什么影响，有一个明确的目标，当每个人都按照总体规划拆解，把自己这部分做好后，基本总体的面也不会太差，才可共同拿到好的结果。
2. 组织上配备开发资源
产品规划会影响到未来至少3个月-半年的方向，同时还有一个更长远的设想。提前的产品规划，同时得到大家认可，才知道需要给你配备什么样子的人，大致配备多久，这就是产品需要把控好自己的开发资源。
如果什么规划都没有，能够达到的产出不知道，就一直说我需要10个开发，这种无法衡量投入产出比，如果没有价值，那为什么公司要浪费这个钱给你配备资源呢。所有一直嗷嗷叫，但是却没有实际规划的，基本很难要到资源。
3. 相互周知，共同规划
每个人都希望有一个好的结果，不光是产品要规划，与你相关的开发、测试甚至设计师，很多方面都需要规划，产品经理是一个业务的领头羊，当产品有规划的时候，同时目标明确，结果明确。
与你相关的产品、开发等也可提前规划。比如中台是作为一个支撑部门，如果业务规划提前出来，中台就可以更早的为业务布局，能够更快的赋能更多业务。
二、怎么做产品规划？
刚刚讲的是为什么要做产品规划，可能更多站在业务全局的角度，那从某一块小的产品来说，是不是就不需要产品规划了呢。或者应该怎么根据某一个产品进行规划。
举例：比如运营提出了一个优惠券的需求
1. 遇到的问题
企业之前没有什么营销活动的能力，运营想要更加自主的进行很多个性化运营的手段
2. 明确目标
首先公司今年的总体目标是什么，假设一个电商公司，目前比较成熟了，今年目标开始做GMV了
同时根据需求的本质，了解到运营不仅仅只是要一个券，而是需要很多运营工具，根据一些人群做个性化营销
3. 解决策略-产品大致方向
由于我们是中台，每个业务方可能都会随着业务发展开始有类似诉求，所以这块应该要形成营销中台的能力。但如果一个个营销工具做，可能会让我们产品、开发不断投入，所以需要把营销工具的共性抽取出来，形成中台化能力。
4. 确认产品框架
（1）竞品分析：市面上大致有哪些营销工具，全部列举出来。比如阿里有面向服务商的开放平台，那就看下开放平台对外提供的营销接口有哪些，那这些接口就是他们营销中台提供出的能力。
（2）根据我们企业需要，与运营碰撞，确认营销工具优先级
（3）产出产品框架：最后我对于我们企业营销中台分了三层
- 营销规则层：因为我们企业开发资源有限，不可能一次性将照营销工具全做了，也不知道具体效果如何。所以会按照一个个营销工具逐步去做，在做的时候将营销的规则抽象出来，形成营销规则中心。比如规则有：优惠条件（满**元、满**件）、优惠内容（减*元，打*折）
- 管理后台层：后台管理提供运营操作创建每一个营销活动的入
- 前台：由各个业务侧自行开发
5. 实施路径图
光有规划没有落地也不行，同样是没有结果。所以有了规划后，就可以产出具体实施路径图比如光一个营销模块，就会涉及到不同的层级，不同的营销工具，需要按照优先级逐步落地，同时要根据活动效果监控，加入迭代，形成产品闭环。不能闷头开发，结果业务效果不好。
总结：之前第一年当产品时候也做过优惠券活动，但那个时候想的是如何把这一件事做好，不会考虑更多架构的问题。现在会去通过1个优惠券的落地，提前设计产品架构，通过一个好的产品架构，可以再后续更多营销工具的支持中越来越快。同时规则的复用也可避免我们陷入不断地开发中。
梁宁：产品规划7问
- 我的产品解决了什么问题：痛点、痒点、爽点
- 我在为谁解决这个问题（用户画像）：他即刻满足了吗
- 有多少人需要解决这个问题（市场规模）
- 目前大家这个问题是怎么解决的（竞争分析）
- 我的竞争方案为什么能够在市场竞争中胜出？（不要简单地看单点的竞争力，而是要看线面体，谁给你赋能）
- 用户会在什么样的场景触发情绪？需要马上去解决问题（场景问题）
- 用户遇到这个问题的时候，他会想到哪个名字呢？
三、 产品经理的软实力
1. 多沟通，多宣导你的理念及规划
像我的习惯是，首先做某一个功能点的开发时候，比如优惠券，我会把我整体营销架构说清楚放在prd中，至少开发知道不是开发一个券就完了，可能还需要提前考虑整体架构。
2. 同理心：多考虑对方要什么，共同拿到结果
比如对于开发来说，也需要有业务价值的东西，而不是每次都在做代码的搬运工。对于业务方来说，可能要清楚他的目标是什么。
3. 靠谱：形成个人产品闭环
规划-执行跟进-结果，每一次都一个闭环，大部分的结果如果是好的，就会形成自己是个靠谱产品经理
4. 思考力
我认为产品经理最重要核心竞争力，多思多想多做。
总结
- 很多事情不是做得多就是对的，有可能一开始的方向你就错了，那即使走下去有可能也不会有好的结果
- 产品总结，不是到了总结时候想这段时间做的事情，然后汇总，你的总结在规划的时候就应该想好了
- 每个人都按照一个相对符合公司总体目标的方向，层层拆解，当每个人做好时候，总体的结果也不会差
我认为高阶的产品经理会升级为业务架构师。最后总结回归题目，为什么你总没有开发资源，先想想自己这个事情真的想清楚了吗，这一个事情会影响哪一个点，如何去说服别人。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>最近和朋友探讨如何规划供应链系统及财务系统，从业务架构到技术实现，从具体的功能及设计到数据的流转，涉及方方面面，基于此个人也进行了思考，虽然前期整理了很多FMS、SCM的业务流程，但回顾一下，总觉得还欠缺一些东西，最近刚好在看产品方法论和一些关于思维的书，本篇就试着写下对于系统规划的一点思考，希望与关注的朋友共同交流！
思考问题模式的转换
作为产品或研发人员，我们都是接收需求（业务或产品），创造或改善产品的人（新产品或老产品），这些都是我们习惯的也是一直在做的工作，当有新需求时你首先想到的是什么？
以我个人来讲一般先是将新需求简单理解一下，然后在自己接触的产品、系统中去搜寻与之有关联的内容，然后去想要改造的点有哪些，应该如何去实现，实现时会涉及哪些困难点，不知大家是否也是如此，这种应该属于功能性思考模式，即习惯于针对将需求转换或拆分为多个系统功能，然后结合相关的业务或系统进行扩散式的设计。
目前看这是一种初级的方式，但是对于公司业务、系统比较稳定的场景下的一些小需求是最简单、有效、直接的方式；需求尽快评审，任务会快速分解，项目会及时上线。
但对于一些较大的需求或项目，此种思考方式需要转换，我这里将其定义为系统思考模式即不以单个功能独立的去思考，而是站在系统的角度去讨论、设计。
做电商后端的产品或研发、或做ERP、供应链等软件规划，每个人可能负责其中一个或几个子模块，分工越细，涉及的范围越窄，所以应该增加思考的宽度，站在系统的角度去考虑，将各个模块能够串起来，起码要知道上下游模块的关联影响，这样有助于复杂问题简单化，从系统上也会避免烟囱式设计和重复造车的问题。
功能性、系统性的思考方式没有错，随着业务的熟悉程度、技术能力的不断提升，此时应该用平台思维方式去考虑项目需求。日常应该去多了解多个系统，在平台的角度将多个系统组织起来，形成一个平台架构，此时要考虑的就不是简单的实现，而应该是合理性、稳定性、扩展性。
功能、系统、平台这些还仅是从简单产品设计和系统的方面去思考，技术研发在日常工作中更多的是这种，所以还需要再度升级即产品思维，这也是N多人说的。要时刻牢记我们设计、规划、开发的一个产品，而且它不是孤立的。
一直都说产品思维，什么是产品思维？知乎上有很多讨论，也有很多种答案，「产品思维一种从用户、场景、触达等转化链路出发，完成目标的思考方式。」这个我是比较赞同的，它包括用户思维、价值转换，也隐含了交易模型的信息。
如何规划设计产品
产品可以是一个硬件，也可以是一个软件，也可以是一项服务，我们接触的产品就是软件、系统或一个接口等。
产品无论大或小需要知道为什么要做（Why)
更多的时候要想一下现有的产品是否可以满足，如果不满足存在什么问题。如果是一个从0到1的产品，那么就要了解，实现它能解决什么问题，有没有竞品或类似的产品。
这个通常会在MRD中详细阐述或在prd中更多以项目背景体现，对于为什么去做，一定需要考虑清楚的，不能形式化或程式化。
譬如公司要开发一个财务系统，它和用友、金碟等有什么不同，如果它是一个业务系统，那么它又和现在的一些系统有什么区别呢？
可以按照SWOT（优势、劣势、机会、威胁）去进行拆解，每项都清楚了，大家也就会理解了。
确定业务边界、范围即做什么(What)
要有个概况，我认为此部分可以采用产品架构图的方式呈现出来，它包括哪些功能、模块、上下游系统的接口等。通过它将可视化的具象产品功能，抽象成信息化、模块化、层次清晰的架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路。
产品架构图适用于较大的项目，对于一般的需求就不适合了，此时可以使用最常见的一种方式，即思维导图。
思维导图中有多种模板，最常用的有单向导图、鱼骨图、水平或垂直时间图等多种，在项目讨论、需求评审过程中它还可以作为会记记录的工具。通过思维导图可以清晰展示出相关业务模块，涉及的功能点等。
无论采用可用方式或工具，只要让相关人知道我们即将要做的内容，方向、策略等就可以。
确定目标（Object)
在项目产品实现过程中，经常会设定一期、二期分阶段的完成，尤其采用敏捷的项目管理方式「快速迭代、快速上线、快速试错，快速调整」，这非常适合互联网电商项目。
以目标为导向，来引导项目产品的执行，这就是现在各公司在推崇的OKR工作法，OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法。
产品可能要经历多个项目来实现，项目又可以拆分成多个小项目，所以目标分为终极目标、大目标、小目标等。
对于目标可以按照时间来设定即近期目标、中期目标和长期目标。
选对负责人和团队（Who)
这个非常重要，因为不同的人负责同一个项目会有不同的执行结果，大家可以共同回顾一下我们所经历的项目，有成功有失败，有方向上错误，这和目标(Object)有关，有范围上的错误，这和做什么(What)有关，也有和人(Who)有关的。
不同的人做，产品或项目的质量会不同，这也会影响到项目目标，这里有一个不值得定律，可以参考。
不值得定律，就是如果你觉得一件事不值得做，你就不会把它做好。细细品味好像确实如此，如果项目负责人是公司指派的，但他（她）对这个项目并不感冒，那么他（她）投入的精力就有限，讨论时就不会深入，那么即使最终完成，此项目也只是阶段性的，最后可能会不了了之。
在上家公司曾参与过公司级的信息化系统项目，即利用NC来替代目前所有的系统如SCM、销售系统、门店工具、报表等，经过了解当时技术、产品、业务等都觉得这个项目是耗费资源（人和物），并不能满足我们的业务需求和目标，但是碍于当时CEO要求，只能配合，从项目启动到执行，也就两个月的时间，项目宣告结束，这应该是不值得定律的一个体现。
经常参与一些小需求评审或研发任务讨论会，发现有的人并未全心的投入，多一点工作也不想做，以致于后续要花费很多时间去沟通，严重影响团队氛围和项目测试、上线等，此时他（她）内心就似乎有一种不值得做的态度。
选对人、选对团队成员，是重要的，有时候态度比能力更重要，能力可以在项目执行过程中通过积极学习去提升，但态度有时很难转变。
如何去做，怎么做（How)
这个是设计的过程，也是分解的过程，明确了目标，知道做什么，由谁去做，那么这些资源如何调配，根据短、中、长期目标按照什么样的路径去实现是关键。
对于产品或项目，可以采用产品路径图(RoadMap)或WBS工作分解法，将任务、资源、目标按时间周期有规律的整理出来，后续按此进行跟踪管理；站会和看板是简单有效的方式，提高沟通效率及时了解项目进展，这些都应该在项目真正开始前明确。
这些都是敏捷项目管理的实践，在此阶段确定了必要的方式方法，最重要的还是技术上如何去完成这个产品或项目，所以个人觉得在此时要进行技术选型、各开发团队间如何协作、不同的技术组（研发、测试、运维、数据等）如何配合等；面对业务产品的需求变更如何响应和应对，虽然敏捷强调的是拥抱变化，但是这应该是在不影响目标的前提下的一种变化。
这些有些还是属于大的规划，涉及很多细节还是要在具体实现过程中才能进行，在整个过程中我们还应该让自己始终以满足用户为目标，站在用户的角度进行不同场景的切换，这应该是用户思维的一种方式。
用户不单指个人或一些人的群体，它是一些在某个场景下，某些特征的人或团体的组合，对于用户思维可以去看看俞军方法论这本书，会有更深刻的理解。
风险及应对方案（Risk)
在不同阶段会有不同的风险，产品有营销推广风险，技术实现过程中有技术选型、架构设计等不同的风险，执行过程中有延期的风险等。
对于风险识别与管控是需要提前考虑和规划的，这在项目管理课程中都有针对性的讲解。
在实际工作中，风险一般都是提前根据经验而提出来的，但是在后续实施过程中往往会忽略这些风险，随着时间的推移很多风险都会让大家习惯，而且有些人也会刻意的规避一些风险，这对最终的结果有时会产生很大的影响。
在团队中有时会遇到一种善于迎上的负责人，对于上级领导安排的工作或任务总是拍着胸脯做保证，于风险基本避而不谈，对下则采用强压或推脱的方式，这种情况应该在（Who)阶段识别出来，这也是一种风险。
风险识别要客观的去识别，不夸大也不要规避，主要是针对风险要提出应对方案，这是才是关键。
资源规划(Resource)
人（产品、研发、测试、运维相关资源）只是资源的一种，在产品或项目实现过程中会涉及很多资源，技术方面有服务器资源、网络资源；此外还需要管理层的支持等隐性资源，如充分的授权。
资源就是我们在完成这个项目或产品的过程中，所应用的所有的有形或无形的各种需求的总和，在规划时要充分考虑到这些，以避免项目、产品超支或延期风险。
产出方式及衡量(Evaluate)
用户价值=新体验-旧体验-迁移成本，这个公式很有名，一个项目或产品的成功如何去考核，上线成功就是成功吗？应该不是的。
譬如，之前我们在做财务共享集成项目时，上线时需要完成不同业务线的应收、应付等与SAP的CCP、Brim集成；审核过程中要应用影像、审批流完成在线审核；支付时要与集团的电子支付完成对接；数据通过ESB进行同步等等，这些都是一些产品功能，对于财务部在完成集成后，要有工作效率的提升、人员成本的降低等。
这些是与目标相关联的，对于一个系统，还要考核其相关技术指标，如QPS、TPS等。
规划如何汇报
以上是针对实现产品或项目的整体规划，是借鉴了以前同事的工作方法结合5W2H进行了一点扩展，简化下来就是为什么做，做什么，谁来做（3W)，目标是什么，如何做（1O1H),风险及资源规划和产出价值（2R1E）。
形成一个标准模式，对于大家对产品的认识，在汇报过程中避免无头绪、无方向、无效率的讨论。对于汇报人要依据规划准确的讲解给相关人员，这也是需要方法的。
理论与方法
金字塔原理：这是由芭芭拉.明托提出来的，她毕业于哈佛大学，是麦肯锡公司第一位女咨询顾问。
简单的理解就是在汇报过程中，要先表达中心思想或结论，然后自下而下表达，自下而上的思考，纵向疑问回答、总结概括，横向归类分组、演绎归纳。
具体的原理也是刚刚了解，在汇报过程时对于问题回答时，要先说论点再说论据，对于论据建议3条即可(别超过5条），多了可能就啰嗦了（第一、第二、第三；首先、其次、最后…)。
在组织这些内容时，可以按照时间顺序「如：目前、现在、未来或第一、二、三步的执行过程」、空间顺序「如：地域、部门或属性等分类」、重要性顺序「如：会员、核心用户、普通用户」、逻辑演译顺序「推理的过程」。
还有很多分析方法我们可以学习训练并应用，这里汇总下这些名词，有兴趣的可以去百度详细了解。
标杆分析法、SWOT方法、波特五力分析、麦肯锡7步分析法、5W2H分析法、6W2H分析法、5M1E分析、8D分析、SMART原则、360度评估、甘特图、乌龟图分析法。
用户思维与交易模型
这两个是在读俞军产品方法论时提到最多的，用户思维说的个人的简单理解，对于交易模型我的理解是在产品设计和系统设计时都要牢记，它不是指以买或卖过程的货币转移，任何有价值的内容都应该属于交易，它就是利来利往即创造利益、分配利益的过程。
书中原文是：交易模型是指产品经理发现和设计的合理机制，它能促成用户做出某种行为（即交易），且可持续（生态是平衡的）。
此外，要有同理心，开过很多会，经历过多次争吵，应该以实现目标为导向，站在对方的角度去思考、看待问题，还是以前看心学的六字直言：聆听、欣赏、接纳。
总结
本篇从思考问题的方式（功能、系统、平台、产品）开始，到运用「Why,What,Object,Who,How,Resource,Risk,Evaluate」,再到汇报时可以运用的方法理论，是自己最近学习了解的一点认识，分享给大家，刻意的去训练运用这些理论，应该会使自己思考问题更准确、更专业、更合理吧！
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>DRD（Data Raquirements Document）顾名思义同prd一样，作为同研发团队沟通的一种凭借。便于管理当前数据埋点的状态和历史迭代逻辑的追述。也是建设公司良好数据体系管理的基础，那么如何写一份高质量的DRD文档呢？本文将从四个方面进行分析，希望对你有帮助。
首先，要明确数据需求。只有从业务本身实际需求出发，才能够采集满足业务所需要的真实数据。是想了解整个用户浏览页面内容的情况？还是想了解某个功能整体使用情况？只有需求清晰明确了，才能够合理设计埋点采集方案定义埋点指标。
数据是判断你工作目标是否达成的关键依据，是服务于每一次迭代上线后的效果衡量。通常指标定义好之后，围绕着定义好的一些指标进行事件和属性设计就可以着手写DRD文档了。
下面结合具体实例来说一下写好一份DRD文档分几步。
一、明确需求定义指标
通过需求拆分出核心的数据指标。定义指标前要了解产品的结构、用户行为来明确分析的范围。
实例：
数据需求：通过埋点采集用户行为，分析用户使用情况和选择偏好及流失原因。
指标类别：
- 常用报表指标：新增、日活、启动、周活、月活及注册数据、会员数据、使用时长、留存、系统稳定性。这些通常为日常关心的核心数据指标可以做到报表里供日常观察的指标。
- 营销指标：营销banner曝光、点击及各个营销位的点击排行、展示排行、业务转化等营销板块的数据指标。
- 用户价值指标：新用户的次日留存、7日留存、月留存、成本、用户的产品生命周期模型。
- 运营指标：会员和活动任务的热度、业务转化、会员新增、累计、续费等指标。
- 产品功能指标：导航栏、按钮点击、功能入口的点击和转化等指标。
通过指标常用的类别确定我们需要分析的数据指标，就可以进行埋点事件设计了。
二、事件设计
主要会从两个方面去进行事件设计一个锁定是核心要分析的页面所产生的行为，一个是锁定核心功能产生的行为。
页面事件：锁定要分析的页面和页面上的内容以及在这些内容和页面上产生的点击、浏览等行为。
功能事件：锁定要分析的功能比如：搜索、登录、注册、购买、会员付费、签到、扫一扫等，这些功能的入口、点击和完成行为。
三、属性设计
每个事件都有对应的事件属性来说明该事件具体分析的维度。属性可分为通用属性和具体属性。通用属性如：版本、设备、网络、IP等。具体属性如：各事件的来源、各页面加载时长、各内容的位置、各内容的ID等。
埋点时需要进行采集这些事件的参数和属性用来分析。事件属性维度的拆解可以依照4W1H（who、when、what、where、how）的方法去进行思考避免遗漏，这里就不在多说了，多多练习就好了。
通常的页面时间的属性参数会涉及到事件的来源位置、页面曝光时长、页面上曝光的内容、内容ID、内容类型、有无图片等。
功能按钮点击的事件属性设计时，一般只需要监控按钮点击数即可，不需要进行其他背后的属性说明，例如扫一扫、广告图片点击等。也有的时候可以把按钮所属的页面作为一个事件，把各个按钮名称作为参数，去设计埋点方案。
事件的采集就是在确定产品范围内找到用户的点击、曝光、完成等系列行为，最后针对各个行为进行属性和参数的细分说明。这样一份高质量的数据文档就完成了一大半。
这里值得注意的一点就是时刻清晰明确做数据埋点的目的是什么然后通过场景化思考进行方案设计，这样有效避免数据遗漏或复杂而无用造成的低效数据埋点方案。这一方法论不仅适用于埋点方案设计时也适用于在其他所有地方和场景中做产品方案设计时，值得大家牢记。
四、完善文档细节
正如本文开头说的，DRD是作为同技术研发沟通的一种凭借。是为了便于管理当前数据埋点的状态和历史迭代逻辑追述。那么就不可少了对文档一些细节说的备注，上线时间点，当前埋点时的状态，便于后续追溯。
所以一份完整的DRD具有的维度有：事件名、英文名、事件说明、事件属性名、事件属性英文名、属性值类型、属性说明、当前状态是否在线、埋点的形式是前端采集还是后端采集、及上线的版本记录及当时状态的备注说明，这样一份完整的DRD就完成了！
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>借鉴别人的产品，并不像抄作业，可以不用过脑，直接copy，以下内容，来源于我产品工作中的思考，可能和你在别处看到的不太一样，希望你能赏脸一读！
01
产品经理接到需求后，往往需要先去了解一下竞品是怎么做的，看看有哪些地方可以“借鉴”一下。
产品经理在策划时，对其他产品进行“借鉴”，是一个“常规操作”。
有时候，设计师和程序员会开玩笑说：“你们产品经理老是抄这抄那的，就不能有点自己的创新吗？”
有时候，我自己私下里侃大山，也容易张口就来：
“那个产品有什么了不起的？不也是抄某某产品的嘛，都是别人玩剩下的东西。”
“现在市场上的产品，同质化太严重了！产品经理只知道无脑抄，没有一点自己的想法。”
当然，这都是些玩笑话，并不是严肃的观点。
不过，最近我发现，有一些同行朋友，居然还真的是这么认为的。
他们觉得，产品同质化就是因为产品经理只知道互相抄袭。
这说明，产品经理水平太菜，只能抄别人的，没有能力自主设计。
甚至进而引出了对“人人都是产品经理”、“产品经理门槛低”等问题的抨击。
对此，我感到有些诧异。
我觉得，但凡对“产品经理”和“公司运作”有一点了解的人，都不应该会有这样的认知。
当然，我也一直强调，不同公司、不同产品经理，面对的情况可能非常不一样。
观点相左，可能只是因为大家所处的环境不同，所讨论的语境不同而已。
02
“哪个产品抄袭了哪个产品”，这是我们吃瓜群众喜闻乐见的话题。
首先需要强调，这里所说的“抄袭”、“借鉴”，并不是指“非法侵犯他人知识产权”，也不是指“恶意剽窃他人创意”。
这些行为是错误的，这点毋庸置疑。
这里所讨论的，简单来说，仅仅只是“你的产品‘像不像’别人的产品”这样的问题。
你会发现，哪怕是经济实力雄厚、团队水平高超的大厂，也总“抄袭”。
大厂刚推出一个新产品，马上就被指出，和国内外某头部产品非常相像，甚至达到“像素级模仿”。
这样的事情，经常发生。
不管大厂自己什么公关，明眼人都清楚，抄肯定是抄了。
以大厂的实力，完全有条件去做创新，甚至可能做得更好，为什么要出此“下策”呢？
这时候，有人就会把这个锅推到产品经理身上。
毕竟你是“产品”的经理嘛。
我觉得，这就有些荒谬了。
是全公司所有人都那么愚蠢，以至于产品经理这么明目张胆地抄袭都没发现？
还是产品经理已经强势到了可以完全主导产品，其他所有人都只能“敢怒不敢言”？
显然不可能嘛。
这肯定是领导层做出的决策。
道理其实也很简单，就是“不确定性”的问题。
眼前就有一套被市场充分验证过的成熟方案，为什么不用呢？
自己再搞一套，可能效果更好，也可能会搞砸了。
这里面有很大的不确定性。
如果没有可预期的超额收益，没有一个领导愿意承担这样的风险。
03
当然，作为执行人，老是抄别人的，我自己多少也会有些不好意思。
所以，有时候，我也会做一些“掩耳盗铃”的事情。
明明就是抄别人的，非要把左边的东西挪到右边去，把圆的东西换成方的，假装自己在“优化”。
但是，抛开感情因素，单从理性来讲，大部分情况下，我其实不太愿意在策划上搞“创新”。
原因主要有2个。
一、大部分项目都非常紧急，时间上不允许。
举个例子。
曾经，某大厂和我公司，都在做一个类似的项目。
据了解，他们那边，专门组建了一个团队，好几个人在负责搞这个项目。
而我这边呢，整个项目就我一个人负责，全都要我来搞。
但是，公司不可能说，因为我们人员少，就多给点时间，晚一两个月再上线。
所以，可以想见，留给我的时间，是极端的不足。
这样的情况，并不是特例。
一个大需求，今天刚布置下来，明天就要给方案，下周就要搞完上线。
这样的情况，我想，应该是很多产品经理的日常。
当产品经理每天被各种deadline搞得焦头烂额的时候，“花心思打磨设计”就是一种不切实际的奢求。
二、因为团队的“协作精度低”，所以不敢瞎折腾。
比如说，产品经理的prd中，提了5点要求。
如果不考虑“要求不合理”这样的情况，那么，按理说，团队就应该把这5点要求一一落实。
毕竟白纸黑字写在那里，大家都识字。
但是，现实中的情况往往是，团队只做了第1、2、3点，第4点给弄错了，第5点给漏了。
我一时间想不到应该用什么词来描述这种问题，所以暂且生造了一个词，“协作精度低”，以方便讨论。
在实际工作中，这样的情况经常发生。我不知道大厂的精英团队会不会好些。
面对这样的情况，产品经理需要花非常多的时间和精力，去沟通需求、跟进项目、测试验收。
即便如此，项目最终能到达预期的80%，就已经算是极限了，可以“验收通过”了。
如果是搞一个新的东西，那将不得不投入更多的成本，而且最终的完成度很可能又得下降个20%。
在这样的情况下，如无必要，产品经理一般需要尽量采用常见的方案，尽量复用原来的模块，避免瞎折腾。
04
借鉴别人的设计，是有诸多好处的。
比如上面说的，对公司来说，这样可以降低不确定性，减少风险。
其实，从产品经理自身工作的角度来说，借鉴别人的设计，也是很“香”的。
这里举几个例子。
一、在一些监管严格的领域，市面上通用的做法，往往是监管部门认可的做法。
有的时候，并不完全是“用户体验”的问题。
比如说，一些“确认条款”模块的设计，单从产品设计的角度，可能会觉得体验不好，或者影响转化。
殊不知，这是受限于监管部门的要求，不得已而为之的。
如果产品经理没有注意到这一点，策划的内容不符合要求，就很可能会暴雷。
这个错误，可大可小，有时候可能会非常严重。
所以，在一些涉及敏感内容的模块，如果产品经理没有条件进行充分的调研验证，那么，照抄头部产品的通用做法，就是一个稳妥、理性的选择。
二、借鉴竞品的设计，可以提高方案的通过率，减少项目推进的阻力。
有些时候，其实这样设计也好，那样策划也行，实际上没有太大区别。
更重要的是，让项目尽快上线，让产品先跑起来。
问题是，产品经理策划的方案，不仅需要经过层层审核，还要随时面对团队各成员的挑战。
这些“你一言我一语”的意见，并不像论文答辩，可以通过逻辑推导来达成一个“共识”。
大家说来说去，其实都是一种“感觉”。
“感觉”没法辩论，众口难调。
为此，产品经理需要反复修改方案，以满足各方的要求。
这不仅增加了工作量，也耽误了时间。
但是，如果这个方案是借鉴了竞品，情况就会非常不同。
自家的产品经理好欺负。但是，想要否定竞品，底气就没那么足了，需要有更多的依据来支撑自己的观点。
所以，大家会突然变得慎重起来，也没有那么多“意见”了。
这时候，方案就比较容易通过。项目推进起来，阻碍就会小很多。
三、如果需求方背负了较严苛的KPI，产品经理最好不要“放飞自我”。
一个方案效果好不好，可能有很多影响因素。
事实上，我们很难定位到具体是哪些因素在起主要作用。
产品经理在策划时，一般需要借鉴业内那些被市场验证过的效果好的方案。
一般来说，产品经理不会完全照搬，而是需要加入自己的理解，结合公司的具体情况，做一些调整。
但是，谁也说不清，产品经理“擅自”做的那些改动，会不会反而对最终效果产生负面的影响。
如果需求方的KPI考核比较严苛，那么他会非常保守，不能接受任何不确定性。
这种情况下，产品经理非要“自我发挥”，就是在给自己找麻烦。
因为需求方会不断跟你抠细节，你的任何自我发挥，都很难通过。
这时候，产品经理就应该老老实实，按照已经验证有效的方案去做，方便你我他。
05
借鉴别人的产品，并不像抄作业，可以不用过脑，直接copy。
曾经有一段时间，“聊天机器人”很火。甚至有人认为，“聊天界面”，才是更自然的、更有未来的交互界面。
因此，不少公司纷纷上线了“聊天机器人”项目。
当然，大部分都不是什么人工智能。
对话内容都是写死的。
用户只能在有限的选项中做出选择，然后根据用户的点选，调取相应的对话链条。
那时候，我公司也要上线这类项目，由我来负责。
我接到的要求，很明确，就是“照抄某大厂的产品”。
但是，“照抄别人的产品”，其实并没有想象中那么简单。
实际上，这个项目，在各个环节都出现了不少问题，把我搞得焦头烂额。
这里不展开细讲。
仅结合这个项目，谈几点“抄袭”时候的注意事项。
一、要细心观察，有意识地思考每个细节这么做的原因。
说是“照抄”，但是我也不可能潜入对方公司偷产品文档。
我能做的，也就是高强度地去使用对方的产品，各种“点点点”，尽量把更多的情况试出来，然后构建起完整的产品策略。
这个过程中，我们要有意识地去思考，每个细节这么做的原因。
比如说，有一个“回溯”功能，就是用户选错了，可以回去改选其他选项。
这个功能的入口，并不是一直存在的。
当用户点选一个选项后，聊天界面开始加载相应的回答时，这个入口就会隐藏，直到回答全部加载完成。
这个机制，一开始我没有细想，觉得没什么意义，就没跟着搞。
直到进入测试阶段，才发现，如果用户在回答加载的过程中进行“回溯”，程序非常容易出错。
这时候，我才发现，原来回答加载的过程中隐藏“回溯”入口，是出于这个考虑。
所以，才不得不赶紧补上这个功能。
二、要结合公司自身的具体情况。
在对话过程中，用户一般只能进行“点选”操作。
而机器人这边的回答，形式就丰富很多。文字、图片、音频、视频、链接等，都是可以的。
比如说，对方的产品在对话中，机器人在某个环节会发送视频。
这有可能，是因为对方的产品经理觉得，“视频”的效果会更好。
也有可能，刚好对方公司已经有了一些视频素材，所以产品经理随手就给用上了。
当我们在“抄”的时候，不能无脑照搬。
需要评估一下，使用“视频”，是否有必要？公司是否有条件去制作这些视频？成本是否能接受？改成“图片”是不是效果也差不多？
反之，如果公司自身已经积累了某些可用的物料，我们也要考虑，自己的产品是不是可以加上，充分利用起来。
三、在吃透对方产品策略的基础上进行补充，以满足公司自身的特殊需求。
虽说是“照抄”，但需求不可能完全一致。
所以，在弄明白对方产品策略的基础上，我们需要进行各种补充，以满足公司自身的特殊要求。
比如说，对方的聊天机器人，只有一个固定入口，一套对话内容。
而公司的需求，是要在不同渠道分别推广，每个渠道对应不同的对话内容。
那么，后台就需要增加“渠道管理”，不同渠道分别配置不同的对话内容。
考虑到，不同渠道的对话内容，可能只是部分对话链有差别，大体上是一致的。
那么，为了方便配置，就需要增加“复制对话链”的功能。
比如说，相比对方产品，公司产品的定位，更偏向于营销。
那么，就需要根据营销的场景，比如各种节日，变换界面风格。
所以，就得考虑，是不是要加上“换皮肤”的功能。
06
我并不是想说，“创新没用，抄袭万岁”。
只是，我一直想强调，初级产品经理是一线的执行者。
我们首先要考虑的是，如何把交付给我们的任务，按时按质地予以完成。
只有在能够很好完成工作的前提下，再去讨论那些自我提高、自我实现的话题，才会有意义。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>理解的深度决定着迭代项目的方向，迭代方向决定了产品的规划设计，会涉及公司的研发资源的投入。
产品迭代的价值决定了公司这个项目的价值，背后背负着整个项目团队的人力成本。
输出的关键还是由输入的质量决定的，如何快速又保质保量的理解一个正在运营的项目呢？
我们先了解一下什么是正在运营的产品项目。
正在运营的产品项目
正在运营的产品项目又叫常规项目。是指产品上线后正在有计划的营运的产品项目，通常产品项目正在根据需求和规划的方向进行迭代。
正在运营的项目的共同特点是它有自己明确的目标用户画像：它是对哪类用户设计的产品，它为用户提供了什么价值，它也有明确的产品名称，它还有固定的线上平台支撑业务的运作。
当我们交接正在运营的产品项目时，我们可以交接到的内容有：这个产品的基本信息、产品的需求池（这个不一定会有，要看公司的前任产品经理是否有输出）、产品每期迭代的业务流程图、产品每期迭代的原型图、每期迭代的prd文档以及线上产品的链接。
拿着这些对接过来的内容，如果自己没有一个完成清晰的思路，去将交接的项目分先后顺序有针对性的系统理解，即便我们将所有版本的产品原型图页面都看完了，流程也走了一个闭环，但是我们还是会发现，其实依旧不了解接手的这个产品，也不能清晰的说出具体是哪里不了解。
如何在有限的时间有质量的输入是我们需要思考的，这篇文章我们就如何学习理解新项目进行讨论。
没有需求背景，就没有当期的产品设计。
需求的背后是有原因的，理解这期版本迭代是为了解决什么问题，我们就抓住了这期产品设计的方向，它是我们开始理解产品的核心，只有将需求理解到位，我们才能在接下来的业务设计中不发生偏差。
那么拿到交接来的原型图，我们该如何去思考每期迭代的需求呢？
其实我们最开始的时候，可以先不看线上的产品，而是先找到最初版本的原型图，在最初版本产品原型中的迭代版本目录里面，记载着需求背景，描述了这期迭代是为了解决什么问题，理解了需求背景，我们就掌握了这期产品设计的方向。
如果我们通过文字描述还是无法清晰的理解需求为了解决什么问题，这时候就需要你去找领导沟通，把你是如何理解的、自己哪里有不懂的地方说出来，看看自己理解的是否正确，不懂的地方是否可以得到解答。
理解了需求后，我们带着理解的需求背景再去理解业务逻辑。
什么是业务逻辑？
业务逻辑就是业务的过程和业务过程中涉及到角色。是在什么时间什么角色做什么事情产生了什么样的结果状态。
业务在不同角色中的流转，就是业务流程。研究业务中涉及到的角色，我们可以知道业务流程存在哪些节点。
不同的业务规则组成了业务逻辑。复杂的业务一般业务逻辑也比较复杂，复杂一般体现在规则里，可能角色之间会有制约关系。
为什么要理解业务逻辑？
产品经理只有对业务逻辑掌握理解，才能准确的将业务转化为产品方案，否则会在产品方案中存在遗漏业务逻辑或逻辑流程错误。
怎么使用业务流程图理解业务逻辑？
我们可以通过下面两个方式来理解业务流程图中的业务逻辑。
1）关注业务中涉及到哪些角色参与这项业务：
刚刚已经阐述过，我们知道一项业务是由不同的角色一起协同为这项业务进行服务的，通过观察和梳理这些角色的定义规则、以及他们如何为业务提供服务、掌握角色之间的关系，能让我们对业务中发生的场景和业务逻辑更加理解。
打颗栗子：
当我们进入饭店后，饭店中有服务员为我们点餐，厨师为我们做菜，服务员为我们上菜，前台为我们结账。在饭店吃饭提供服务人员的角色就涉及到了3个，这3个角色通过协同完成了这一项业务的闭环。但是在不同的业务过程中，我们作为客人接触的角色并不相同，他们为我们提供的服务也是不同的。
理解一项业务中不同的角色和角色之间的关系，可以帮助我们将业务中的场景更加具像化，理解业务逻辑细节也会更加深入。
2）看懂业务流程图中的用户路径：
业务流程图中的用户路径就是这项业务时间轴从开始到结束的过程中，不同的角色分别做了什么事情。我们也需要将角色之间的关系理解清楚，将不同角色做的事情按照时间轴顺序把一个个小场景串起来，理解每一个小场景中背后的意义是为了达到某一个环节的什么目的，串联后就会形成一个完整的业务用户路径。
业务用户路径通常是固定的，而产品页面是依托业务的用户路径设计的，产品页面呈现的样式虽然会多样，但是无论如何改变调整都不会偏离业务用户路径。掌握业务用户路径我们在观察原型图就会更加理解原型图想要达到的目的，为用户解决的需求是什么。
再打一颗栗子：
如上图所示，还是使用刚刚的餐馆吃饭的栗子，只不过这次我们看到了流程图。
可以发现顾客的选菜动作发起了就餐业务的开端，找到了作为起点的角色是顾客后，我们可以顺着流程图的引导线可以看到和他交互的角色是谁，在这个时间节点做的事情是什么，继续捋顺流程引导线中每一个角色做的事情，思考他们之间发生的交互动作，一直走到流程的结尾。
走完全流程我们对于一项业务的发生始末的过程和业务逻辑中不懂的地方才能一一发现，梳理出来。
梳理用户路径的过程是一个发现我们时间节点中存在盲点的过程。当我们发现的时候将不懂的地方进行记录。记录后汇总与交接人、业务方或领导沟通讨论，我们才能对业务有更深的理解。
字段是什么？
每个字段都要有产品经理赋予它的定义及规则：字段界定的范围和边界、字段值的数据来源、数据如何输出展示、数据保存到哪里。
每一个字段单独拿出来，对于产品经理来说，都是零件库中的一枚零件，不同的零件可以组合成不同功能，提供不同的能力。
为什么要理解字段？
字段组成的内容是传达给用户信息的媒介，为了传达某一种内容或目的，需要产品经理在有限的页面中，为内容提供的能力精挑细选出字段零件，因为字段文案质量的背后隐藏着内容传达给用户时，用户理解的效果，影响接下来用户的反应和动作。
这就需要我们不仅要了解字段的定义和规则，还要去继续解读字段文案的意义。
打颗栗子：
抖音首页_推荐里面的字段有：昵称、标题、话题、头像、点赞数、评论数、分享数、音乐。
1）昵称：解决了是“谁”的问题。让我们能将一个作者的脸和他的名字关联起来的工具。下一次再见到他们，我们说出他们是谁。
2）标题：解决了“作品”的主题是什么。我们通过标题可以知道这个主题我们是否感兴趣。
3）话题：为了垂直内容。如果加了“#+文案”，就构成了这个主题对应的话题，点击“#+文案”会进入到抖音发起这个话题的用户中这个话题的全部内容。
4）头像：为了让人记住你。名字，头像和动态的作品可以让人们更好的记住你是谁，长什么样子。下次看到你的作品，一秒可以认出你。
5）点赞数：作品被认可的数量。点赞数越多，背后反映的是人们对这一作品的认可程度。越高说明喜欢的人越多。吸引用户观众将作品内容看下去。也可以满足作者的虚荣心，看到点赞数量，触发作者出作品的动力越强。
6）评论数：作品的引发的议论数量，不光要听作者说，还要引导用户观众的发言。数量越高说明这个主题引发的讨论越热。当作品能吸引用户看下去，引发用户想吐槽时会点开评论看看其他人是怎么说的。
7）分享数：作品让用户想要自己将其传播出去的动力数量，是对作品作者的肯定。数量越高，说明用户越认可作品。
也可以满足作者的虚荣心，触发作者出作品的动力越强。理解字段字段文案的意义，可以分析字段文案背后的意义和目的，字段是引导用户操作行为的内容。
理解字段的方法
我们可以将页面中的字段定义和规则，以及分析出的意义和目的提炼到Xmind中，站在产品层面思考这个字段想传达给用户什么信息，引导用户操作行为内容是什么，达到什么样的目的。
如果对字段有不明白的地方，我们可以先进行记录，最后一起找领导沟通去了解。
如果交接的时候有需求池，可以有时间多看一看需求池。因为需求池里面收集管理了这个产品的全部需求，通过查看需求池可以追溯产品的迭代方向。上述的工作都做好后，用自己对产品和业务的理解多与交接的产品经理沟通、与用户或业务方进行沟通，才会对产品有一个深刻和全面的理解。设计迭代版本时才能提出更明确的需求，掌握产品的迭代的方向，更好的把握迭代节奏。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>在创业公司，常见写prd的方式就是原型 + 备注说明。不仅速度快，开发同学看起来也方便。
而其中最复杂就是逻辑部分，需要能清晰表达你的想法和思路。
要知道，在需求评审结束后，开发会按照你的逻辑落地实施，测试也会按照它撰写用例。
因此，如何能让多方在认知上达成一致，不仅考验产品经理写作的能力，还包括用户视角的同理心。
接下来，以我设计的一个功能为例，阐述优化PRD中的逻辑内容的方法，希望能帮到你。
一、功能背景介绍
在系统「周期性任务」这个功能里，可选择3种方式的下发，分别是：
（1）每日，可选择 0:00 至 23:59；
（2）每周，可选择周一至周日，提交时间设置 5 天或 7 天；
（3）每月，可选择 1 号 至 28 号；
而目前系统仅支持「下周期」下发，举个例子：
今天是周日（4-19），设置任务开始时间是今天（4-19 0:00），任务结束时间是（5-19 23:59），选择每周的周五，提交时间 7 天。
按照已有逻辑，第一条任务会从下周五（4-24 0:00）派发，总共会有4条任务。
不知道你有没有发现，从今天（4-19）到下周五（4-24）这期间是存在空档的。
回归到对方实际的业务场景，其实是有足够时间完成任务并提交。
而这就是本周期的概念。
对此，我们需要将这个功能做成可配置，由用户自己选择下发时间。
二、优化前
按照我之前习惯，我会分类地将每个情况写出来，并附带一个例子进行说明。
从大类上来说，总共有4种情况，分别是每日、每周（5天）、每周（7天）、每月，最后的结果如图所示。
说实话，写完后我自己都不愿意再看一遍，更不用说开发了。
但在当时，我并没有意识到这个问题，总觉得自己已经分类写的明明白白了。
开发，应该看得懂。
但在结果上，确实打脸了。
就因为逻辑的问题，整个评审的流程延长了好几个小时，虽然说最后多方人员都理解了。
但也还是出现开发中多次询问确认的情况。
这件事的问题，主要出在我身上。
事后我去反思这件事，确实应该换一种更好的方式来表述。
最起码，自己是得愿意看第二遍的。
三、优化后
之后我也在思考，到底以哪种方式呈现能便于对方理解，就有了以下的产物。
其实，逻辑上都一样，只是表现形式上有区别。
都说要把用户当傻瓜，那开发同学不也是我们的用户吗？
产品经理需要用最低的认知成本，将自己的思路表达给对方，而方式不过是手段罢了。
写在最后
每一次的功能迭代，其实都有可以优化的地方。
重点在于你愿不愿花这个时间去探寻新方法，并将它实际去运用。
要知道，工作中最花费精力的就是反复沟通。
当一件事2遍说不清楚的时候，我们就需要警惕了。
找出其中的问题，定点把它解决掉，那么我们就能获得提升。
成长，是在一点一滴中取得的。
愿你我一同努力，一起进步~
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>