产品方法论
四维产品功能价值评判方法论：Idea、Value、Solution、Efect
编辑导语：产品经理在工作中总会遇到一些问题，这个功能做不做？这个功能有什么价值？这个功能能解决什么问题？等等，这些问题都要从多维度进行判断；本文作者分享了关于四维产品功能价值评判方法论，我们一起来看一下。 如何评判一个产品功能做还是不做？ 这是一个产品经理或者产研团队都需要面临的高频问题。 做过调研，大家对于这个问题往往会提出如下解法： 看价值有多大，价值大于成本就做； 看时机是不是成熟，成熟就做； 看解决了用户什么问题，解决了就做； 看是否符合俞军公式：新价值—>原价值—切换成本就做等等。 诸如此类的回答都对也都不对。 这些一维（yes or no）决策方法都能够从某一个维度过滤掉一些次要功能，但往往忽略了其它因素。 比如当只看俞军公式的时候，新价值—>原价值—切换成本，那么滴滴应该all in无人车，大幅度削减人力成本；但背后的因素诸如就业问题、企业研发成本、政策时机就完全没有考虑到。 所以为了能够建立起一个足够完整和体系化的模型，帮助我们筛选掉无用功能，我们需要一个充分考虑各方面因素的功能价值评判方法论。 在这里推荐四维评判模型，为了避免中文同义词产生的误会，我定义了四维为：Idea、Value、Solution、Efect，会用这四个名词来阐述。 一、Idea层面 四维评判模型和对产品价值的思考层次有关系，一个产品功能本质是“提供一个Value的Solution”，它往往起源于一个Idea，最后对整个产品生态产生一个Efect，这四个维度是基本的产品价值逻辑。 越高层次的产品经理，越应该充分考虑到这四个维度。 举个例子： 一些产品门外汉往往会有很多Idea，经常会因为想到一个Idea而高兴到手舞足蹈，然而往往想不到更深的3个层次：这个Idea有多大价值、用什么方案（Solution）来实现这个Idea、这个Solution在实现Idea之外有哪些负面影响和成本。 这也是往往产品经理最被诟病的点——太执着于灵光乍现追求一个标新立异的Idea，仿佛找到了成功的钥匙；但实际上往往前人都已经思考过类似的Idea，甚至早已在某些维度不合适而Pass掉了。 从灵光一现到Idea落地产生价值，还有十万八千里。 二、Value层面 真正入门的产品人，至少会思考到Value层面，也就是我们常说的产品定义和产品核心价值确立。 我们经常说一个好产品，可以一句话概括它的价值、它提供了什么服务、解决了什么问题，比如： 微信：熟人社交平台； 滴滴：出行平台； 大众点评：本地生活决策平台； 这是一个产品的核心Value，产品功能应该围绕这个Value来建设，一步步让这个Value越来越大进而形成壁垒成为标杆。 不是围绕这个Value的功能，都很难帮助产品在这个Value上更进一步，应该不做或者少做；这也是为什么微信（主打社交价值）会支持直播、拍一拍这种新的社交动作，而不会把京东、微保等电商金融业务放到比较重的板块。 而支付宝作为支付产品，首页是支付等功能入口，虽然也有朋友功能，但更多是作为转账的渠道；可以积累一些交易关系，但很难沉淀社交关系，和微信的好友关系功能类似但其实价值不同。 如果提出一个功能是支付宝做朋友圈直播和拍一拍，那么显然只是核心价值的衍生功能，并没有帮助到“支付”这个核心价值，优先级就会稍低。 三、Solution层面 更进一步，真正一线的产品经理，面对的问题更多是——为了用某个功能的属性来加强产品核心价值，如何进行方案（Solution）细节的决策。 比如大众点评为了“让用户更好的决策”（Value）想“展示更多店铺的信息”（Idea），可以选择的功能（Solution）有很多，比如： 支持店铺的VR展示； 展示客户的评论供大家参考； 支持对店铺进行打分来排名； 实际上我们发现1是暂时没有做的，2和3是做了的，我们尝试分析一下背后的原因： 支持店铺的VR展示，确实提供了更多店铺信息，但我们的核心目的是帮助用户更好决策（吃哪个或去哪逛），这个决策（拿饭店举例）的主要因素在于：价格、菜品色香味、就餐环境等等；而VR展示更适合展示全方位静态信息，比如看房，对于每天就餐的情况很难实时展示。 如果为了实时展示而用直播的方式呢？ 一方面会有顾客隐私风险，另一方面直播模式太重，就餐信息量太小，所以相比之下视频功能更合适；所以你可以看到目前饭店是有视频展示的，并且分为官方视频和客户视频；官方视频往往是品牌宣传类非实景的，客户视频往往是拍就餐时景的，这样商家不去私自发布客户就餐视频，平台法务风险也就小了很多。 同时因为视频提供的决策信息（就餐环境和时景）次要于价格和评分等，故入口要深一些。 上面这个分析过程，不一定是全部原因，但至少是一个一线产品经理该掌握的，用怎样的Solution，尤其是这个Solution细节该如何来提供Value的分析方法。 四、Efect层面 思考到Solution层面之后，初期其实仅仅是一个方向，还很粗粒度；这个时候如果贸然提出方案，不但会被开发问详细规则问到无语，还会存在很多细颗粒度的变数，而这些变数往往导致方案失效。 比如支持店铺拍视频，支持多长？谁来审核？是否要匹配类目运营？做不做视频社区？这些都是Solution背后的无数个小的细节决策点，这个时候进行决策需要考虑的就是Efect。 永远要记住：我们做一个功能不仅仅是因为它很酷或是很有价值，而是因为它的价值符合产品Value，并且Solution方向正确，同时效果（Efect）好。 这个效果就包括正向效果和逆向效果（成本和并发影响等）。 从成本上讲，长视频和短视频的并发量和带宽成本不同，所以能展示清楚信息的情况下，没必要支持单条长视频。 从并发影响来说，如果视频功能是有效的，那么可以拍视频的商家的展示效果一定是优于无视频商家的；那么在这种情况下，店面不好但性价比很高的店铺就很吃亏，这部分店铺的目标用户可能会因为视频展示这个功能，对没视频的店铺产生质疑导致决策变更。 这种情况下，对目标用户的讨好就带来了对非目标用户的伤害，所以在考虑到一个功能好处的同时，也要从平台大盘视角出发，充分考虑到非该功能用户的反应和影响；如果这种影响会让正向效果大打折扣，那么也是不值得做的。 对于Efect的评估，往往需要很深厚的行业经验积累，也是每个产品经理需要不断深耕和追求的核心竞争力之一。 比如之前讲到携程收购去哪，瞬间拿到了大量的市场份额，试图和航司谈价获得更大利润；而机票行业上游比较集中，航司集体改变规则，同时扶持其它平台，导致收购获得的市场份额又逐步回退了；所以收购这个方案的本身价值在于提升市场份额和议价权，但忽略了给航司侧带来的影响，最终这个影响让初始的目的失效了。 所以这不是一个好的Solution，因为长期来看没有达到预期的Efect；所以产品经理不懂业务，很难正确评估出方案背后的效果，进而很难做出正确的决策。 虽然支持了一个新的功能会显得平台很酷，但更重要的是要达到某一个目的，取得预期的效果；再好的方案，如果没有达到预期的效果，或者和预期效果方向有偏差，一定是某一个维度上没有考虑周全；也许是用户成本预估失误、运营资源没有提前匹配，甚至是负面影响大于正面影响。 所以我很赞同产品team用最终效果来进行考核，如果效果好，做得功能越少，那么PM能力越强，这也许就是“少即是多“。 五、总结 最终总结一下，评判一个功能做不做，最少要有4个层面： Idea只是起点，需要寻找Idea背后的核心价值是什么； 要定义好产品的核心价值，然后只关注能建设核心价值的Idea； 一个Idea可能有无数个方案来落地，方案需要不断细化来考量是否能达成效果； 方案的效果=正向影响-并发逆向影响-成本，即使正向影响很大，但逆向影响和成本更高，也需要调整方案； 以上就是「四维产品功能价值评判方法论」，希望能够帮到大家。 作者 花生酱先生，微信公众号：产品之术。金融业资深产品经理，对职涯规划与个人发展有丰富经验，产品涉猎广泛，ERP、金融领域较多。
产品方法论之“三位一体”法
编辑导读：作为一个初级产品经理，进入职场后才是“真枪实战”。尽管之前在书中学习到再多的理论，现实中一样也会遇到难解的问题。本文作者总结了他晋升时常用的方法论，并佐以案例，分享给在职场中有困惑的产品经理。 又到了一年一度的秋季晋升了，评审期间翻出往期的晋升文档，发现其中有好多内容其实可以拿出来分享给大家的，毕竟来自真枪实弹的方法论，更接地气，也更有人情味~ 一、我要分享一个什么样的方法论？ 这次分享的方法论来自我还是初级产品经理时，根据工作内容总结的一套方法论。 彼时，我作为初级产品经理，已经开始负责一些中小型的项目了，并且开始根据业务提出的需求，结合自己的产品sense，凝结成产品需求，进行评审上线。 此时，一直有个很靠谱的产品大拿在带我，我有什么问题也都和他知无不言（多说一句：这很重要，在我们还是小白的时候，一定不要不好意思，有问题一定要及时暴露，自己闭门造车是无法成长的）。不过，我也踩了很多坑，有过被质疑，有过自我怀疑。幸运的是，这些坑最终没有困住我，而是促成我发现了一些产品经理这个岗位的规律，并最终内化出了一套方法论。 这套方法论也成了我晋升材料中的一部分（当然也成功晋级啦）。现在我就结合我的经历，来拆解我的方法论。 二、需求来了，无从下手怎么办？ 假设你是教育类APP的产品经理，这个产品姑且叫做【学习真好APP】。 在Q1的某一天，你们的学科老师提了个需求，要做引流课的活动，进行招生引流。而你是刚入职2个月的产品经理，产品业务以及产品流程都已了解，突然有这么个需求让你做，并且规定1周内给出方案，1个月内上线。 其实真实的业务场景就是这样的，业务的需求都是没有边界的。通常业务方只抛出个需求，也没有目标和价值，也没有具体的实现形式，只是说明这个功能的一个需求点，并简单交代了上线时间（有时间还是那句最头痛的“越快越好”）。 这个时候应该怎么剖析这个需求呢？ 其实这个时候，你要遵从你的内心，说出一句“什么玩意”。不是玩笑哦，如果你不清楚这个需求，首先要想的的不是怎么做，而是为什么。所以，需求来了后的第一步，就是求证。 对于产品经理来说，产品最重要的是什么呢？我认为是产生价值，没有价值的产品就是废品。 在需求层面，你是否了解它的价值呢？如果业务给的需求没有标的价值，你第一个要考虑的，就是这个需求的价值。 引流课对于公司的价值是什么呢？弄清楚了这个问题，才算是明白这个需求的价值。终于，你带着这这个问题，与学科老师一阵唇枪舌剑，彼此对于这件事情的价值达成了一致。 对于公司，引流课可以为公司在线课业务带来新的用户增长，增量用户作为用户池，为正价课导流。【学习真好】作为公司2C业务的重要的出口，做这个需求责无旁贷，学科老师需要为引流课输出内容，保障课程质量。 价值意识和业务对齐后，就进入到产品经理的主场了。产品经理这个时候无论title高低，都要有个大局意识。你不是一个人在战斗，你要利用一切资源完成需求的核心目标。在做需求的时候，你要考虑都涉及到哪些业务线，你的需求对各条业务线的影响是什么。 举个例子，引流课不是静悄悄的在APP上线就万事大吉了，如果用户都不知道有这么个活动，等到引流课结束，他都没有接触到这个活动，怎么能保证活动效果的最大化呢？没有庞大的流量，引流课做出来只能是效果寥寥。所以，这个时候就要考虑这个活动从前期预热->活动上线->用户维护->活动下架的整个环节中，都涉及到哪些业务线的参与。 比如针对这个活动，前期预热肯定需要产品运营的参与，在上线活动前吸引用户过来，更有条件的时候，也需要公司的市场部，针对线上线下的渠道进行广告的投放。 将每个环节的业务都串联起来后，就需要产品经理梳理出一张战斗部署图，一个项目就是一场战役，要有毕其功于一役的决心。这个时候需要作出各个时期的泳道图，把每个时期涉及的业务线和各业务线的关联划分清晰。即使此时还没有比较清晰的方案，也要做到心中有数，把主流程跑通。比如可以做个这样的泳道图： 图1 业务线梳理完毕后，就到了产品专业的层面，从【学习真好】这款APP的产品定位，考虑需求的细则。 你要针对产品中的用户进行分层。比如，新用户和老用户，这两部分用户在引流课活动中的优先级肯定是不同的，因为他们能产生的价值是不同的。 新用户是我们最希望获得的群体，他们是我们产品能够持续存在下去的希望；老用户的心也不能伤害，要保证他们的粘性。针对新用户和老用户要制定不同的产品策略和产品流程。比如输出一个裂变玩法，每老带新一位，新老用户都可以减免学费或发放优惠券。再比如新用户完成引流课购买后，我们送他一些正价课的优惠券等等。 产品需求都明确之后，产品经理就要遇到一个问题，就是不清楚如何实现这种需求ROI最高。 不知道你有没有这种感觉，明明这个需求我知道是什么样子的，但就是不知道怎么做才好。比如页面内容是瀑布流展示，还是把内容聚合成一个个小集合进行显示。甚至是一些细节，比如一个商品到底展示哪些内容，都展示肯定不合适（用户没有重点，页面凌乱），展示少了又担心用户错过信息。 产品经理这个时候很容易陷入闭门造车的自我怀疑当中。其实，这个时候是考验产品经理经验的时候，有经验的产品经理做起这种确定性的需求如丝般顺滑，因为他都遇到过，他深深的知道哪种方案适合这种场景。但是，对于比较初级的产品经理，是没有这种经验的，万事开头难，到底要从哪里下手呢？ 首先，建议产品经理多向外部看看，因为大部分的需求，市场上都有同样或相似形式的产品。可以货比好几家，看看其他家产品针对你接到的需求都有哪种实现形式。看的产品多了，你就会总结出很多共性的点，比如从功能框架到功能流程，有很多功能点都是约定俗成的，用户也是有使用习惯的。建议多看看主流的产品，不要追求标新立异去看比较小众新奇的产品。 主流的产品都经过市场验证，即使流程体验不佳，也都教育了用户，用户也有了使用习惯。小众新奇的产品不确定性高，如果产品体验没有被用户接受，你若参考他们的产品是有很大风险的。 当然，这个是针对初级产品经理的，由于经验少，一旦判断失误，是会减弱在研发侧威信，很容易让研发同事产生不信任感。而追随主流的方案，会在最大程度上规避风险。随着经验的积累，产品经理会逐渐总结出自己的经验，并沉淀出自己的方法论。最终在“向外部看看”这个环节，就可以不拘泥于主流产品，这个时候产品经理就可以博采众长，将其他产品的亮点为己所用。 在看过了大量竞品/同形式的产品后，还是要回到用户视角。这个时候要考虑，你的用户画像是什么样的，他们的习惯如何，你的产品上都有几类用户。 还是拿【学习真好】这款产品举例子，你产品定位是K12的教育服务平台，那么你的用户就包括了5~18岁的男生和女生，并且还要包括他们的父母。具体分析用户的颗粒度要做到精细化，比如：学生使用你产品的时间，学生家长所在的城市（一二线还是四五线），学生家长的收入情况，学生家长的职业分布等等。 在细分用户的过程也是拆解出用户痛点的过程。结合你上面参考的几种功能实现形式，就可以初步分析出你的目标用户的使用习惯，并制定针对性的产品方案。 那是不是说，我拿着制定好的方案就可以开干了呢？先等等，在敲定最后产品方案的时候，还有一个步骤要做，那就是模式分析，也就是你整个方案的策略。 在参考其他产品方案的时候，不要仅停留在“器”的方面，也要关心下“术”。一个好的产品策略，可以让方案的执行井井有条，并可提前预见到产品不同时间可能出现的情况。 那模式分析到底要分析些什么呢？其实这个模式分析，是一次针对整体方案的检验。 一个功能不是单独存在的，它一定是有着一套业务体系的，每个业务体系是环环相扣的。在上面输出的产品方案中（图1），可能只是整个产品模式中的一环。你要向上+向下去分析整个产品模式，看看有哪些环节在你的整体方案中有缺失，哪些环节会对最终的结果有重要的影响。 回归到开头的例子，引流课不只是在APP中banner位上有个入口，点击之后有个落地页等流程。还有私域流量的建立、裂变的玩法等助力活动效果的方案。这个时候就要去检验最开始制定整体方案时，有没有遗漏。因为项目是你发起的，其他兄弟部门只是配合，你不提出新的方案，他们很少有动力帮你完善（很现实~）。所以，这个时候通过对整个模式的再次梳理，把之前方案中有问题的环节进行修缮，把之前遗漏的环节补齐。 比如完善之后的泳道图可以是这样： 图2 这个时候，你的方案才做到了闭环完整，最大程度的保障落地效果。接下来就是项目立项，给各个合作部门落实需求，并制定统一排期上线了。 小结一下 上面的分析部分是“三位一体”法的第一部分，我称之为【想透】，【想透】的部分要从内到外的去考虑需求。正所谓“运筹于帷幄之中，决胜于千里之外”。我们就是每个项目中的军师角色，我们一定要保持头脑清醒，思路清晰，这是我们迈向专业化的重要一步。 我将【想透】这个过程抽离出两个部分： 1）入里 公司层面考虑价值：从公司层面出发，考虑需求对公司可以产生的价值，在很多公司的企业文化中叫做：向上一层思考。 业务线层面考虑依赖的端侧：梳理出所需要的各支持业务线，并初步梳理出实施方案。 产品层面考虑需求（用户体验）：需要从产品的用户出发，考虑需求是否符合产品定位，并对用户做好分层，具象出分层的用户需求，实现用户体验与业务需求的完美契合。 2）出外 需求层面考虑竞品/其他优秀产品：在具象出的需求中，有哪些在其他竞品中已经直接实现，或间接实现的。他们目前做的情况怎么样，有哪些方面是需要我们借鉴的，有哪些方面是我们需要规避的。 用户视角出发定位需求：在考察竞品/其他优秀产品实现的方案过程中，如何判定哪种实现方案适合我们呢？需要我们从自身的用户视角出发，通过我们对自身产品的用户画像，进行需求定位。 业务模式：竞品/其他优秀产品的业务模式都有哪些可借鉴的点。这个是产品实现形式中上一层的设计思路，是我们通过完成整个实现方案后总结出的模式。 三、需求都准备好了，怎么推进啊？ 这个恐怕是很多产品经理在需求评审以及项目推进过程中一直盘旋在脑海中的问题。在产品经理生涯的初期，很容易因为在需求推进的过程中有所遗漏，导致项目出现风险，有些风险甚至会被定性为事故。这也是产品经理总是背锅的原因之一，排除其他人为因素，产品经理自身的考虑不充分，背锅真的是有苦难言。 判断一个产品经理是否“靠谱”，就是通过一次次需求的落地效果去强化个人标签的。 此时首先要考虑的，就是“人”。产品经理作为需求分发的统一出口，需要将信息传递到所有涉及的人员。其中，不止是所负责业务线的产品经理、技术人员、测试人员，还有相关联业务线的产品经理，以及相关的技术人员、测试人员以及其他相关联人员。 确认了人员后，就要保证信息的高效传递。 根据需求的大小，会有不同的传递信息的方式。如果是比较小的需求，可以在一次需求评审中将相关联的产品经理、技术人员、测试人员叫到一起进行需求的传递。然后根据传递后的结论同步到相关的人员即可，比如：业务人员、产品运营、相关联业务线的产品经理等。 如果涉及的业务线较多，就需要先和关键业务线的产品经理以及其他关键人员（比如：关键的技术owner、测试owner、产品运营、业务人员等）先同步需求，需求内容达成一致后，即可启动各业务线的需求评审，并制定后续的推进计划了。 在信息的传递过程中，需要按照顺序，由高到低（公司意志到业务内容，由高层到执行层的顺序），由浅入深（让受众循序渐进的了解需求）。比如针对不同的同步场景（是业务人员、产品人员的同步场景，还是技术人员的同步场景），制定不同的信息传递方式。不过无论是针对哪类人群，都是要把项目的背景、目标、价值传递到位。 我见过很多产品经理在和技术人员进行需求评审时，把背景和目标描述的不清晰，导致技术人员在不清楚背景和目标的情况下，提出利好自己的技术方案，导致最后项目的结果走样。其实在一个晋升体系完善的项目团队中，产品技术是可以做到心往一处使的，每个项目的背景、目标、价值都是独一无二的，一定要让受众感受到项目的价值、并了解到项目的背景、从而和产品经理达成一致的目标。这样后面需求内容的落地才能做到水到渠成，技术人员和其他相关联人员才会尽自己所能地去完成最后的目标，共同促进项目的顺利实现。 当然在信息传递的过程中，势必会有很多意料之中以及意料之外的事情发生的。 比如：你可能会预料到其他业务线最近项目比较多，可能没有时间配合你做这个功能，此时你在信息传递前就要做好项目优先级的排序，并做好方案的安排，保证在目标达成一致的前提下，进行合理的需求优先级排列。 针对意料之外的事情，比如：技术人员关于需求有不同的意见，其他业务线的产品经理觉得你的方案有问题等。当有人持有不同意见的时候，要找到分歧点的根源在哪，有时候根源可能不是方案有问题，而是在方案上针对其他业务线的部分考虑的不全面，导致项目有风险导致的。 找到分歧点后，需要进行充分的沟通，保证最后需求是朝着正确的方向前进，不要自说自话，要相信问题一定是有解决方案的，产品经理需要引导各个端口人朝向最终的目标迈进。 在各端达成一致后，要保证各端的时间是符合项目上线预期的，同时，也要尊重各端给出的时间。比如：技术开发功能的时间是按照功能点去排的，强行缩短时间，会导致提交代码的质量的不到保障。当然，缩短时间也可以靠增加人力去解决，但在不增加人力的情况下，最后结果交付质量需要时间去提供保障的。同时其他业务线可能同期有优先级更高的需求，这个时候产品经理一定要做好时间的取舍。 在需求中的信息同步完成后，项目就进入到了落地阶段。此时，产品经理切不可掉以轻心，虽然信息已经同步，但此时仍然存在变数，比如其他业务线有高优需求插入，技术侧发现重大BUG难以解决需要变更方案等。这些风险在项目落地阶段都有可能发生。 产品经理一定要做好时间表的维护，包括总体项目的进展，以及细化的每个业务线、产品经理、技术人员、测试人员的各个重要时间节点，包括：需求评审时间、提测时间、联调时间、测试时间等等。 同时一定要按照周期进行项目进展的跟进，比如：通常项目的周期是按照天进行的，那就要保证当天的一个固定时间点各个端口的负责人（通常是产品经理和测试人员）在一个统一的群组里面汇报当天的工作进展以及存在的问题和风险。通过这种每个周期性的项目跟进，最大限度的保证产品经理对项目进展做到心中有数。 小结一下 上面的分析部分是“三位一体”法的第二部分，我称之为【做够】。 【做够】的部分强调事无巨细，项目的执行阶段要把握好每一个环节。其中要处理好“人”和“事”的关系，在你每一次处理好项目落地过程中的每一个环节时，你会收获一个在工作中至关重要的标签，那就是人格魅力。这是产品经理的软实力之一，一旦建立起人格魅力，它既会帮助在面对技术人员、测试人员以及其他业务线的人员时，让他们因为你的人格魅力而对你产生信任，也会帮助你自身不断向更高的台阶跨越。 在【做够】这个环节中包含三个部分： 1）同步 人：直接相关人，包括本业务线的技术人员、测试人员等；间接相关人，包括其他业务线的人员。 事：针对不同的人，把项目的背景、价值和目标都传递到位。 2）决策 求同：在和相关人进行同步时，需要保持目标统一，并根据相关人事情的优先级进行需求的推进。 存异：当相关人有不同的意见的时候，要分析分歧点在哪，进行充分的沟通，要保证需求向着正确方向前进，最后结论要尊重各自时间（对内：要保证项目上线时间得到满足，对外：尊重客观时间）。 3）执行 心中有数：需求确定后，要明确关键时间节点（提测时间，联调时间，上线时间），并按项目周期跟进项目进度，及时暴露问题并解决问题。 四、需求成功上线了，真的就结束了吗？ 其实无论需求上线后的结果如何，我们都要做好复盘。针对正向的结果，我们要做好数据的沉淀，并将方案做成案例沉淀到个人的知识库中。针对负向的结果，不要避重就轻，一定要深挖问题的根源在哪，并找到解决问题的办法，并制定风险预防机制，防止下次出现同样的问题。 对于项目复盘后产生的经验，最好能够输出一套外化的内容，输出到其他业务线。这种行为模式在组织影响力中称为：知识传承。这种能力是产品经理成长为高级产品经理必备的能力之一，如果在初期就有这种能力沉淀，后期的职业生涯会顺畅许多。 其中关于项目经验和数据的部分，可以作为案例沉淀下来，放到公共的知识库中，作为案例的结果支撑。有些项目本身在上线后是具备复用能力的，比如：在教育行业中的拍照判题能力，这种能力就要考虑是否可以打包成通用能力输出到其他业务线，帮助其他业务线更快的抓住市场机遇。 如果项目上线后没有通用能力可以沉淀，那么项目中所采取的方法是否可以做成方案输出到各业务线呢？比如：获客的运营方案，项目中所采用的技术方案，甚至项目管理方案，都可以打包成解决方案输出到各业务线。 以上只是引子，每次项目上线后对产品经理的价值往往体现在复盘环节中能够总结出什么。完成每次的总结，你会体验到从量变到质变的过程。总结过程不止是个人成长，你也会在外化经验的过程中获得更多的认可，何乐而不为呢？ 小结一下 上面的分析部分是“三位一体”法的第三部分，我称之为【反哺】。…
小公司产品经理：如何改善“野路子”，构建自己的方法论？
编辑导读：产品经理属于新兴职业，没有太多职场老鸟能带人，除了少数大厂拥有完备的产品体系，大部分产品人都是摸着石头过河，也就是所谓的“野路子”。那么，作为一个小公司产品经理，该如何改善野路子习惯，构建自己的方法论呢？本文作者依据自身产品实践中的所思所想，结合案例对上述问题展开了分析探究，与大家分享。 所谓“野路子”，即没有规范的工作方式，做事情没有依据，想到哪做哪，做到哪算哪，经常会陷入自己不知道干嘛的境地，这样的工作状态会极大的降低工作效率，长期以往甚至会影响自己的工作情绪。 如何改善“野路子”，即流程化、标准化做事，最佳的方法就是定义Standard Operating Procedure(标准作业程序），以下简称SOP，让自己在遇到问题时有所依据。 下面我将结合个人经验，详细阐述产品工作中如何通过定义SOP，改善野路子，形成自己的产品方法论。 一、定义与同事配合的工作流程 1. 了解互联网公司需求迭代的流程 如图： 2. 明确自己需要做以上流程中的哪些事 根据自己公司的情况细化，明确自己需要做以上流程中的哪些事，比如我司就需要产品做需求调研、产品设计、产品方案宣讲、研发过程跟进、收集反馈这几类事情。 3. 确定以上的事情需要哪些人（WHO）对接，以及如何(HOW)和他们对接 （1）需求调研 需求调研根据需求来源一般分为两种： 一种是内部需求，一种是外部需求。内部需求对接人包括BOSS、研发、测试、运营、市场，这些需求调研的工作和他们约好时间，反复沟通直到双方都没有异议就可以了； 外部需求一般对接人是客户，要复杂一点，懂得随机应变，不要当场答应实现需求，只要做好访谈记录，回来可以和决策人（一般小公司是boss，有些是产品总监或者技术总监）讲清楚大概需求，至于要不要做，怎么做，什么时间做（需求优先级的问题），这些问题留给决策人。 （2）产品设计 产品设计一般情况下是初级产品经理最重要的工作，设计过程中的对接人主要是需求方，有时也要需要技术参与讨论方案可行性，最重要的是和需求方反复确认以保证最终的方案过关，这一点会在定义自己工作的SOP中详细讨论。 （3）产品方案宣讲（评审会） 产品方案宣讲，一般对接人包括UI/研发/测试，有时需求方也会参与。这时候要提前预约时间，准备好产品方案的产出物，比如流程图、功能架构图、原型图、PRD文档，如果涉及项目管理，要在禅道等团队协作的工具中建好需求号，便于开发人员领任务。 宣讲的顺序一般是先业务流程图，再功能架构，然后根据业务流讲一遍原型图，至于文档就不用讲了。记得讲完一定要同步，如果团队有同步的软件，比如svn,git，也可以用邮箱，我们公司用的git，然后在群里发一句，“**原型图V1.0.0,PRDV1.0.0已经更新至git，请有需要的小伙伴自取”。 【PS：请在每次需求变更后，及时更新为原型图和PRD文档，并同步给相关同事，必要时重新开会强调变更，这一点尤为重要】 （4）研发过程跟进 研发过程中可能会出现各种各样的情况，对接人一般是开发和测试。比如开发、测试不理解需求，你要解释；开发、测试发现需求有些情况没有考虑到或者有规则不清晰的，你要补充需求（这种情况虽不能完全避免，但越少越好）；甚至，前后端联调出现问题，需要你定义接口。总之，就是在开发过程中一切的问题你需要负责解释。 （5）收集反馈 收集反馈一般对接人是运营或者用户，这里主要是记录上线后出现的问题，为后续产品迭代提供依据。 以上的5点是仅为个人总结的内容，不同公司的情况可能略有不同。 二、定义自己的工作流程 最重要的就是产品设计SOP的定义，这个过程需要自己反复思考总结，每一阶段都有相应的输出物，并且在平常工作中不断实践才有效果，以我总结的产品设计SOP为例： 需求调研→业务模型搭建→流程图→产品功能架构→原型图→PRD文档 1. 需求调研 这一步需要尽可能多的收集需求的信息点，包括需求的目的，参与的角色，上线时间，很多细节的想法等等。如果只是需求方只是一个人，那么他会提关于很多需求的描述，尽可能记下来；如果是头脑风暴式的需求，那么有不同的人提出不同的需求描述。 以PCG(Professionally-generated Content)的课程APP为例，A可能说课程要能定义属性（视频/文档），包括价格，名称等，B可能说课程要能下架，下架后前台就看不到了，C说用户要能够选课程，购买课程，D说要有购物车，只要是会上没有发现有明显问题的信息，统统记下来；我一般用onenote分点记，很多人喜欢用思维导图。 示例： 推荐工具：onenote 2. 业务模型搭建 根据需求调研记录的信息点搭建业务模型，最重要的是梳理主流程，听起来好像很难，但实际操作比较简单，在草稿本上列两点：参与角色、每个角色涉及的操作。 同样以上述课程APP为例，涉及到的角色：包括平台运营人员、用户，涉及到的操作：平台运营人员上架课程，用户选择并购买商品；注意，这里涉及的操作不是要列系统中详细的操作，而是业务过程中完整的闭环操作（包括线上、线下）。PCG的内容是自己生产的，所以线下还包括制作流程，那么完整的业务模型应该是： 运营人员制作课程→运营人员上架课程→用户选择并购买商品 注意：业务模型的搭建一定要闭环，所谓的闭环就是实现最终的效果，比如C端的产品一定是要通过用户直接购买/广告/增值服务赚钱的，B端产品一定是要解决闭环解决问题的，一定要考虑系统层面做到哪一步，作为需求的边界。 我一般只会粗略的列，因为这个时候列得太细反而会干扰自己的思考。 推荐工具：草稿纸，笔 3. 流程图 一般画三种业务流程图，功能流程图，任务流程图。 业务流程图一般用泳道图（如有并行则用UML），主要是根据搭建的业务模型，在相应的泳道里按照顺序画出每个角色的操作。切记，不要想一步把所有流程画在一个业务流程图中，只需要把整个过程中最关键的一条/多条业务流画出来即可，否则适得其反。 示例： 功能流程图：主要是为了实现某种具体的功能，比如支付功能的验证流程，需要给出不同情况下的结果说明，包括支付成功的流程，支付失败的各种异常流程，开发很有可能拿着你的流程图去写逻辑判断的，测试可以直接拿着流程图写测试用例； 示例： 任务流程图：是为了实现某种任务的整个流程，只会在关键节点做判断，主要是为了让开发和测试知晓用户的核心使用路径。 示例： 推荐工具：ProcessOn 3. 产品功能架构 产品功能架构是就是用思维导图呈现，该产品需求包含哪些模块，这些模块包含哪些功能； 示例： 推荐工具：X-mind 4. 原型图 用界面化的方式展现元素，一般分角色，把对应的模块列在相应角色的文件夹下，先把框架搭起来，再从数据流的角度一个一个页面去画，我一般会把页面跳转和一些动态面板的交互画出来，比只画静态页面要直观很多。 过程中会有很多创意和想法，记录下来，画完自己按照流程跑一遍，看下有没有流程上的障碍，如果有的话，记录下优化的点，逐个优化。 原型图需要保留版本，每更新一个版本同步更新给团队成员。 示例： 推荐工具：axure 5. PRD文档 PRD文档每个人写法不同，不必按照别人的模板生搬硬套，现在很多团队敏捷开发直接在原型旁边标注，看起来很方便。我一般是在原型旁边注明重要的逻辑，另外再写一份Word文档。文档需要做一个目录，方便后期定位，还有每次更改的记录，最好在相应的位置标上最新更改的时间并显红，内容主要包括流程图、功能架构图、功能描述、原型图。 （1）流程图 把业务流程图贴在PRD文档的总述里，记得axure第一页也贴一份，功能流程图、任务流程图贴在相应的功能描述下。 （2）功能架构图 功能架构图在PRD文档综述里贴一份。 （3）功能描述 功能描述需要分角色、分模块，分页面，一般是一个页面一段描述，弹窗放在同一段描述，但也不绝对，也可以用功能点划分，比如列表、增、删、改、查，规则就是用MECE（互相独立，完全穷尽）的原则分清楚，具体描述主要包括三个方面： 数据的呈现，这个页面呈现的数据是哪里来的； 每个原型每个元素的描述，按照原型的页面，从左到右，从上到下撸一遍，每个UI/字段代表什么意义，有哪些规则，每个操作相应的页面变化是什么，数据变化是什么，想清楚，写出来； 描述异常情况，每种异常情况对应的页面是怎么样的，提示是什么。功能描述就是穷尽所有你能想到的注意点，如果你自己都觉得哪些规则好像不对劲，那一定是哪里没想清楚，一定要静下心来好好理理，否则开发和测试后面会找你的。 （4）原型图 在每段功能描述下贴上相应的原型图。 PRD需要记录版本，每一版本记录修改的地方、时间等，而且每次变更及时修改并同步给团队成员。 示例： 在小公司没人指导一定要勤于总结经验并运用在以后的工作中，不断调整，最终形成自己的方法论，这样一方面可以提高自己工作的效率，另一方面不论是转行或是跳槽都能很快的适应，为以后的工作打下坚实的基础。 以上。
我的产品方法论（一）：用户和需求
用户是需求的集合，用户需求是某个特定的用户在某个特定的情景下所某件事所产生的某个特定的诉求，做产品策划设计的必须要明白这两者间的关系。 经过一段时间的产品知识学习思考和产品实践的积累，我逐步形成了一些我个人的产品方法论。对我影响较深的前辈有：俞军老师、张小龙老师、刘飞老师以及王诗沐老师。他们的文章和书籍中蕴含的思想对我产生了很大的影响，因此我的方法论中也会明显地带有他们的思维观点倾向。 首先，用户和需求的研究较大程度上属于产品前期的工作，但贯穿于整个产品生命周期中。 一、用户和需求的关系 下图反映了我对于用户和需求对产品所起作用的理解：总的来讲，对用户和需求的把握是产品策划/设计的前提之一，他们更倾向于内部前提，对产品来说另一个重要的前提是商业前提，我会在后续的文章里加以阐述。 需求与用户的关系 这里，我个人倾向于区分出三种需求类别：用户需求、本质需求、功能需求，这三者是有较大差异的。 首先我们通过用户研究，抽象出用户需求，而直接的用户需求往往浮于表面且过于驳杂，需要我们我们对直接的用户需求进行进一步的思考和提炼。最终归纳出用户的本质上的、最深层次的需求就是本质需求，这些本质需求往往隐藏较深不易发觉。本质需求是我们在产品决策中极度重要的参考依据。 通过对本质需求的把握，我们会进一步抽象出产品的功能需求，即某个具体的功能点，这是进行产品设计的基本单位。切合本质需求的功能需求，往往更为重要，也是产品能否成功的关键。 二、关于用户 1. 什么是用户 用户是需求的集合，用户也是自然人，我们必须看到用户的主观性和情感价值。 即我们在研究用户的时候，应当明确需求来源于用户，因此在这个范畴上，用户算是用户需求和本质需求的背景和前提。因此在功能需求论证的时候，用户是格外重要的考虑因素。 看待用户，既不能完全割裂差异化地看待，也不能过于归纳标签化，要把握适当的划分依据，对用户进行合理划分，这就要求我们具有合理的用户分群方法。 2. 用户行为模式和特性 我个人对用户行为模式的认知是：个人化的认知偏好+情景 => 最大化的期望效用 => 发生行为 => 行为结果进一步修正认知偏好 这样的用户行为模式一定程度上反映了用户的特性： 内部性：个人认知、性格差异 外部性：情景、环境差异 动态性：用户状态往往会在经验的反馈下不断演化，在时间维度上产生差异 即不同的人，在不同的场景下对一件事情的结果会有不同的预期，而结果一旦发生就会进一步反馈给用户，修正用户的认知。因此在进行产品决策的时候要细致考虑好这些因素的影响。 3. 用户研究方法 问卷 访谈 数据分析 自发提炼：通过论坛、贴吧等形式收集用户意见 4. 用户研究原则 一定要亲力亲为，深入用户心理，最好的用研，是自己成为用户 应当对用户进行分群，并以用户群为基本单位进行用户研究 用户研究贯穿于产品生命周期的整个过程，在产品周期的任何时候都要做好用研工作 访谈和自发提炼是最直接的用户研究手段，而问卷、数据分析等方法往往用于验证前两种方法所得到的结论 做可量化的研究，警惕数据陷阱；做可定性的研究，发掘背后的原委（尽量提炼出本质需求） 三、需求 1. 用户需求 用户需求是某个特定的用户在某个特定的情景下所某件事所产生的某个特定的诉求。用户需求往往是直接的，通常表现为某种解决方案的直接反馈（想要跑的更快的马），很少有用户能直接反映出本身的原始诉求，即本质需求。因此我们应当谨慎批判地看待用户需求，听用户的，但不要照用户说的做。 用户需求通常直接来源于用户研究，在提炼用户需求的时候，我们需要注意这些原则： 尽可能多的和广泛地收集需求 对所提炼地需求按维度进行分类 重视长尾需求 2. 本质需求 本质需求是用户的深层诉求，往往是较为抽象的且具有代表性的。把握本质需求去完成功能需求，往往会获得更理想的效果 3. 功能需求 功能需求是根据用户需求和本质需求构想出的实际的产品功能需求，可以直接对用户需求和本质需求进行满足，是产品设计的开端和基础。 一般来说，经过前期的需求收集和想法提出后，我们会有很多的功能需求。这个时候对功能需求的取舍，以及确定功能需求的优先级是我们的重要工作，对于我个人来说，我进行需求分析论证的方法和角度如下： （1）基本面 是否切中用户本质的深层次需求：这是最关键的一点，如果没有满足这一点，那么所设计出的功能通常是针对“伪需求”的，必然无法达到预期效果。能切中用户本质深层次需求往往就会有较大的效用，也足够刚性 是否切中产品的目标：需求是用来实现产品目标的，而目标往往也分为长期与短期、用户性与商业性等，该需求是否有助于实现目标并能够维持保证这些目标之间的平衡性？一般来说长期目标会偏向战略、建立口碑之类的内容，而短期目标则是盈利、获取流量的方向，我们需要在不同的目标之前做出平衡调整措施 是否切中人性：切中人性的需求往往更有机会达成预期的目标，比如满足人的自我表现、寻求认同的心理，比如满足人的好奇心、带给用户新奇体验，这些切合人性的需求推动起来会更加自然 （2）外部环境 流程：该功能需求的流程能否简单快速地跑通而不遇到较大阻碍，这样的需求往往更灵活、更易实现 情景和场景：这个功能需求发挥作用的的情景和场景是什么，在这个情景场景下需求是否能起到应有的效果 用户：该需求面向哪些用户群，涉及到的基本角色是什么？不同的需求往往会有不同用户群的侧重，我们要明确这个需求面向哪个群体的用户，并确定是否能够较好地满足这个特定的用户群体 ROI：即投入产出比，考虑所需资源及成本、实现难度，实现这个需求所花费的成本有多少，获取的预期收益能有多少 供需情况：满足这个需求是否要涉及到供需两端，如果是，供和需两端都能稳定保证功能的正常运行吗？会不会出现一些问题导致供需端出现问题进而导致功能受到影响 （3）其他 频率：功能需求是高频还是低频，这个属性会跟其他属性混杂，进而影响需求整体 其他影响：是否实现该需求会带来哪些影响？除了上述所提到的，一个功能需求的实现往往会带来更深远更复杂的影响，譬如在某个生态平台是否符合该平台的政策？譬如会对竞争对手产生哪些影响？我们需要全面地思考，注意到其他任何可能的重要的因素 总结 以上就是我对产品策划设计中用户和需求的一些浅显的看法，不足和完善的地方还有很多，如果读者能看到请指出。并且我会在之后的学习和实践过程中不断迭代这套方法论，让他成为我工作事业中的有利武器。
产品经理如何打造自己的产品方法论？
当产品经理积累大量实战经验与岗位认知后，学会从中总结方法论与心得能够帮助我们高速成长。那么具体要怎么做呢？过程中有哪些要点要掌握呢？笔者将结合这些点梳理如何打造产品方法论。 28岁岁末的时候，立了个flag，希望在30岁时，能形成自己的产品方法论，如今而立已过，开始做数据产品相关工作也近有五年；这五年来，因为人生轨迹的跳跃，产品本身所在的行业并不固定。好在产品逻辑本身可以触类旁通，加之无论行业如何，自己的兴趣和做的事情，都是数据产品本身。 行业上走过了电商O2O、在线教育、智能硬件、金融风控，产品范围也从之前的数据分析产品跨度到了数据服务、数据应用产品。 外人看来只见其宽，而自己而言，实际一直在数据产品的领域耕耘沉淀。 遂尝试着整理过往的思考和笔记，算是自己的成长，也是不成熟的分享。 01 建立自己理解业务的方法模型 理解业务是理解需求的大前提，所谓理解业务，往大了说是理解公司的商业模式，往小了说是理解产品的具体应用场景。事实上，即使是相同行业的不同公司，业务模型也是千差万别；掌握一套理解业务的方法论，能够使我们的产品之路不局限于行业和平台，快速向新的领域拓展自己的产品力，能够使我们快速的理解新平台的需求场景，更好的推进产品实施； 就实践而言，当我们接手一个新的产品之后，可以分以下步骤去了解业务，以及负责产品对业务的意义： 1. 与业务核心KP沟通，了解业务流程，并自己绘制一个业务流程图，明确以下信息 整个业务分几个环节、步骤？ 每个步骤的具体内容是什么？ 每个步骤之间的依赖关系？ 2. 梳理业务业务流程图后，对着业务流程图，我们要知悉并思考以下信息 业务各步骤涉及的人员、应用系统都有哪些？ 我们负责的产品处于哪个步骤，涉及人员有哪些，解决的核心问题是什么？ 这个时候，我们基本已经定位了自己产品所处的位置，以及产品解决的问题，那么就可以通过具体了解该环节产品涉及人员的具体操作流程，来理解产品的需求本质； 如果条件允许，最好自己参与到业务的实际操作中去；这种参与不是简单的用用自己设计的产品，而是要以业务角色的身份，融入到业务中。 02 掌握基本的产品研发流程 产品经理需要了解一个产品从需求到上线运营的整个流程。虽然各类产品课程都有这方面的介绍，但落地到每一个公司，这个流程又千差万别。 产品的实现的基本阶段可以分为以下几个环节： 需求阶段；（收集需求，需求调研，竞品调研） 产品设计阶段；（信息架构设计、交互原型设计、需求文档撰写） 开发实现阶段；（需求评审、排期、开发、测试、验收） 上线运营阶段；（发版、运营） 整个流程，根据各公司的组织结构、采取的开发模式不同，具体做的事情可能会不一致，比如很多后台产品，本质上没有竞品调研阶段；很多产品经理其实也没有信息架构设计的习惯，某一些研发团队会把需求评审和排期放一起，等等，不一而足。 但无论所处的环境如何，产品经理自己心中一定要有一杆秤，知道哪个阶段该干什么事情。 我们不一定非要按照哪本书定义的方式来，心中有杆秤的意义在于，如果需要我们从0开始打造一个团队打造一个产品，能够如何快速的组织起项目工作。 落到实践上，产品经理至少能画清楚三个流程图： 传统的瀑布开发模式下的研发流程图； 敏捷模式下的研发流程图； 自己当前所处的团队所采用的实际研发流程图； 以下是笔者之前整理的一个研发流程图： 流程图仅仅只是体现了研发过程的框架，我们还要知道并且能够写清楚，某一个节点的关键事项和输出，比如需要一个什么会议，产出什么文档；同时各公司可能都有自己的项目管理协作工具（比如teambition、jira等），我们要梳理清楚这个流程如何在协作工具上体现；如下图梳理了一个研发流程的关键动作以及输出： 对于很多公司而言，这个开发流程可能由专门的项目经理或研发经理搭建并把控。 笔者的意见是，无论流程具体的onwner是谁，将一件具体的事情抽象化、流程化，本来就是产品经理逻辑能力的体现，无论从提升自己的产品专业能力角度、还是加强自己的项目管理能力角度，都具有重要意义。 03 有一套自己的产品设计风格 我们常说的产品化，本质上是将一套解决方案固化下来，说白了，就是套路，产品化即套路实体化。 前述的业务理解模型、开发流程，亦是业务理解的套路、开发流程套路。 产品经理要有一种无时无刻不在做产品的思维习惯，亦即无时无刻不在总结套路，所谓的自己的产品设计风格，即是自己做设计时有一套成型的方案套路。 总结下来，三个方面： 1. 根据所在团队的开发偏好，确立自己的文档规范 BRD、MRD、PRD、原型图这些产品经理的产出文档，网上没有统一的模板，但作为个人要有统一的规范。 所谓的规范，即前后一致，逻辑自洽，比如写PRD的时候，同样是功能描述，一般有两种方式： 前端逻辑、后端逻辑、统计需求分开描述，好处是相关开发能够更快的get到自己要做的事情，坏处是任何一个开发都缺乏对功能的全局掌控，不清楚自己的这个接口、表设计最终展现给用户是什么形态。 主要描述交互逻辑，后端逻辑夹杂在交互描述中，好处是开发能以用户视角清楚功能最终的形态，坏处是前后端的逻辑要由开发做二次拆分。 产品经理可以根据开发团队的偏好，选择一种模式，但同一个项目下的PRD，最好保持相同的方式，而不是这个需求用第一种，另一个需求用第二种。 以下是笔者之前在某家公司的梳理的PRD文档规范： 2. 原型设计时，有一套自己风格的素材库 很多产品经理会在网上找一些原型素材，作为自己设计的模板。 但进阶的产品经理，一定要能够将已有的素材融入自己的设计风格，甚至根据所在公司的业务特点和设计规范，自建自己的素材库。 当别人在看到一个原型、一个文档、一个产品时，能说出“这很有XXX的风格”，笔者认为，这就是产品经理的一步成功。 04 选择并建立自己的产品理念 乔布斯、俞军、张小龙、梁宁等产品大佬都会在各种场合输出自己的产品价值、产品理念、方法论。 作为产品界的芸芸众生，对于这些理念当然先是理解，其次是尝试着在实践中运用。 但到了一定阶段之后，我们需要选择并坚持打磨，只有坚持的理念才能称为理念，也才算是理解。 再之后，就要尝试着建立自己的理念、价值、方法。 以下分享几条笔者坚持的产品理念： MVP原则：抓住核心需求，以最小可行化最低成本方式去验证需求是否成立。 如无必要，勿增实体：一个功能、一个控件、一个操作的新增，很多时候并不是看起来那么简单，很可能会对现有架构、流程造成极大的改动。 取舍理念：这个世界没有十全十美的解决方案，任何一个方案，都有其优势劣势，你不是三井寿，不能什么都想要。 通用化：任何一个设计，不能只考虑眼前，一定要考虑是否兼容未来的规划和产品的最终形态。 再分享几条产品工作的方法原则： 坚持学习技术：要对自己负责的产品所使用的技术逻辑有基本的了解，才能更好的跟开发合作； 主动背锅：主动承担产品开发、运营过程中出现偏差的责任，当产品功能与预期不符时，首先一定要反思是否自己的需求描述没有讲清楚。任何时候，不要有开发理所应当这么理解的想法； 善意沟通：不要去为沟通对象预设立场，永远抱着解决问题的姿态去沟通。 关于产品理念和工作方法，这里只简单的点一下。更详细更多的内容，未来会单独整理文章。 这里想表达的核心是：进阶的产品经理，要有自己的做事方法、理念，而不再是见步看步，被环境左右。 这些其实都是平时整理的点点滴滴关于产品的思考和总结的拼凑。工作七年，产品工作五年，看了下为知笔记，在各公司各项目输出的规范、文档、流程该接近百万字了，平时吐槽不少，但却并没有时间好好整理自己的思考。 这是一个开头，如果你也热爱产品，热爱数据，赐教。 作者：尘寰；公众号：第四阳关少年录
