实际上，通过前两个步骤，你已经获取了一个可量化的目标体系了，而在这个环节是提醒你去注意目标体系中的优先级和精力分配问题：不同的目标之前，哪个更重要？哪个更需要确保完成度？哪个需要你花费更多的时间和精力？此处需注意的是：优先级和精力分配不一定完全一致。当你完成了这个步骤，目标体系正式确立。
3.形成计划
目标体系完成后，就需要把目标落实到计划上。计划其实就是为了实现目标而进行的目标任务项拆解，并且根据时间跨度的不同，可以先拆解为长期计划，再把长期计划拆分为中期计划和短期计划。
同样举例说工作方面的事，如果目标是一年后想对行业具有个人影响力，那么可能需要在主流行业媒体上发声，并且参加行业交流活动。
为了实现这个目标做计划，假设，经调研发现类似的意见领袖去年在某知名媒体发稿了30篇，并且在同业活动中做嘉宾6次。那就大概知道，以你现在的资历和程度，想在一年内达到他的标准，就肯定要比他做得更多更好：比如说把年计划定在一年内撰稿50篇，参加同业活动12次。再做拆分，就是要每个月撰稿4～5篇，参加同业活动1次；再拆分成周计划、日计划，可能就变成了每天撰稿500字这样非常小的任务量了。
4.量化实施
形成计划后就要考验执行力。这里更多涉及的可能是一些量化的个人管理工具，可以帮助你更好地实现计划。常见的包括：
●手账管理法：把你的所有计划都记录在随身携带的手账上，每天都记录下来自己的计划和完成程度，可以随时查阅随时翻看，提醒自己计划的完成情况。
●Excel管理法：与手账管理法类似，同样是把所有计划都记录在Excel工作表中，并定期更新维护实施情况。因为通过量化精进法制定的目标体系可以通过Excel工作表清晰地反馈出它的整体性和分解流程，也更方便地去记录整体进展。
●24小时时间记录法：记录下来你的一天24小时是如何分配使用的，定期整理分析；找出哪些使用时间的方法能帮助你完成计划，哪些时间是被浪费掉了，以优化自己的时间分配，支持计划的完成。
这些方法没有高低好坏，就看是否适合、是否有效，这个在实践中感受下做出选择就好了（我个人非常受益的就是笔记本管理法）。但无论是使用那种方法，量化执行、量化记录都是必须的，这将帮助你后续对自己进行更冷静地分析。
5.进程控制
在实施计划的过程中，有可能会出现任务提前完成或者无法完成的情况，这就需要我们对整体任务进程做一个分析。严格来说，你的计划应当是按照你预设的时间刚好完成，如果出现误差（更多是无法完成），那就要考虑是否是目标或者计划本身出了问题。是否是目标定得太高（比如说一年内成为第二个马云）？是否是每天的任务量太大（没有考虑到加班的情况，结果完全没有时间做自我精进）？
Tips：进程控制就要求在计划执行一段时间后进行总结、调整和校准。我的习惯是每周和每月都会做总结，分析这个周期的执行情况，以调整下个周期的计划安排。
6.验收迭代
如果是一年期的计划的话，那么到了一年后，自己实现了一年前预设的目标了吗？在技能和素养方面提升到自己期许的程度了吗？
与制定计划时自己定下的目标相比，对自己做一个全方位的验收。如果某些目标实现了，记录下实现的心得和经验；如果某些目标没完成，那么就追溯你之前的实现进程，看看是哪里出了问题，出问题的原因是什么，如何规避……把所有的这些经验教训都应用到下一轮的自我迭代中。
三、结语
很抱歉这里没有成功学，没有速成法，也不会出现一列书单、一堆课程或者是几个相互不耦合的学习方向，给你一个看上去似乎很干货但并不实用的假象。自我完善没有捷径，唯独摆正心态，用对方法，接下来就是用时间这把刀，一点点对自己进行打磨。
耐住性子，等待尘埃里开出花。
作者介绍：莔莔有神，公众号：破壳（Pokeclub），人人都是产品经理专栏作家，帝都产品经理，有从0到1和亿级用户产品经验，专注数据增长、商业分析、互联网金融领域。
3.3 产品经理，你会忽视哪些很重要的“小事”？
Killifer
今天在知乎里看到一个问题：
作为一个产品经理或产品负责人可能会忽视哪些实际上很重要的小事？
觉得这个问题很有意思，所以，这篇文章就根据我的角度来尝试回答一下这个问题。
题目既然说的是小事，那么我就不说产品经理最重要的一些事情，例如：
●我个人认为的最重要的四个素质：沟通能力、业务能力、理性思维、逻辑思维；
●产品经理基本工作内容的落地执行；
我们就尝试按照不同方面来列列看，到底有哪些事情是我认为同样很重要，但是可能其他人不这么认为的“小事儿”。
一、合作方面
1.合作过程中多积累
产品经理经常需要和不同的人进行沟通和对接需求，例如公司领导层、运营、投放、商务、业务、设计、开发、测试等。
不同的人，都会站在不同的立场，出于不同的目的，向你提需求或者反馈意见。在他们需求合理的大前提下，你是直接根据他们的做了呢？还是多多向他们请教一下呢？
●运营投放们需要你配合的时候，不要以为自己不相干，要多看看他们的活动类型、多思考他们的投放渠道、多问问为什么这么选择；
●程序员围在一起沟通技术细节的时候，不要以为不关自己事儿，要多听听、多了解下他们是如何实现需求的；
●设计们出设计稿给你的时候，不要一味着收到稿子完事了，多和设计们讨论和请教一下，为什么这么做的原因；
●老板觉得要提前做某个需求，不要只把自己放在执行的位置，要多想想为什么这么做，对公司有什么好处，公司最近有什么变动，如果想不明白，可以尝试问问看；
……
这些都是宝贵的各个角度的实践知识啊，都是需要看专业书才有可能看到的东西（有可能连书里都没有）。现在，你通过一个个需求，就慢慢都了解了，这么一个大好的补充各方面知识的机会摆在你面前，怎么能浪费呢？
不说好处的都是耍流氓，这么做的好处如下：
●对其他和你合作的人以及他所在的岗位有更深入的了解；
●慢慢积累自己对各方的大概知识框架；
●基于前2点好处，相互之间的沟通会越来越顺利；
●在之后的需求时间预估和项目排期上会更加有把握一些。
2.摆正和各方关系的心态
产品人要端正几个态度，那就是：
●不要把设计师、开发、测试当做实现需求的机器；
●不要把运营、投放、商务、老板等人当做只会提需求的外行。
经常在各种地方看到产品人在各种吐槽，例如：
●就是简单的移动一下位置、放大一下，想不明白为什么美工做不出来；
●一个简单的功能，程序员都搞不清逻辑，实在是太弱了；
●老板只会提需求，太坑了；
你用这种对立的心态去看待你的伙伴、你的组员，那么你和大家的关系怎么会好呢？人家跟你关系不好，更是不可能愉快的共事啦。想让别人尊重你的前提是：你得尊重别人。
这么做的好处：
●伙伴们能够在愉快、相互尊重的气氛中工作；
●对于个人，是一种素质的提升。
二、产品工作本身
1.从产品的角度考虑问题
这里说的是：多从整体上考虑问题，而不是仅从产品岗位角度考虑问题。
举个例子，这个版本的需求都已经确定，版本上线时间也已经确定了。但是，运营和投放因为某种原因，要在下个版本做一波大活动和投放，需要产品这边配合开发一些东西，这个时候怎么办？
如果仅从产品岗位考虑问题的话，会觉得这个太临时了。如果应承下来做的话，不但要临时给自己增加工作量，还需要和设计师、程序员重新沟通时间、调整计划。他们也可能因为临时的工作量而导致一些负面情绪的出现，你还得进行安抚。
但是，从整个产品考虑的话，这又是一件需要立刻完成的事情。毕竟，在整个团队有数据压力的情况下，需要用一些外在方法来带来新增和日活，这样对整个团队都好。
再举个例子，一些小白产品们总是会纠结在一个公司里，到底产品更重要还是运营更重要的问题。总觉得公司重视运营，不重视自己，从而很难过。
Tips：这种想法并没有什么意义，如果站在整体考虑的话：需要强运营的产品，自然偏重运营；需要强功能的产品，自然偏重产品。
偏重问题，只是量的问题，并不是质的程度。考虑怎么对产品好，这才是最需要纠结的问题。
这么做的好处：
●对整体产品比较好，不会因为产品的私人考虑而有所偏差或者停滞；
●对个人发展比较好，不断的锻炼自己的全局观思维。
2.多和团队伙伴沟通业务
有时候，能看到产品人抱怨他们的团队成员。比如，我们组里的人都不关心需求、他们只知道做，做了又做错，真是无语。
这个时候，其实你要反思一下，是不是你从来不和他们沟通为什么需求要这么做，才慢慢导致这种情况的呢？
当然，我也清楚，不是所有的程序员、设计师都对为什么要做这个需求有兴趣，但是如果连懂都不懂，你怎么指望大家设计、开发出你想要的东西呢？
不妨在每个版本沟通需求的时候，顺便把每个需求这么做的原因也和他们沟通一下，不管是从数据分析结果、用户反馈，还是公司高层出于战略考虑，都可以说一说。我还是坚信：基于理解基础上的需求实现，从长远上看比较“安全”。
这么做的好处：
●基于理解的设计和开发，可能能够在照顾到现有需求的前提下，考虑到一些可能的坑和未来的改动；
●长久，大家会更有团队的感觉。
3.看数据结果前，辩证数据的真伪
很多产品经理会经常说：
从数据结果可以看出balabalaba……
这都快成为一种口头禅了。但是我要告诉你，如果数据本身就是错的，那么你所谓的数据结果就是个无稽之谈。可能你会很疑惑，数据怎么会错呢？
当然会了：
●可能因为不同平台的不同算法，导致数据和你真正想要的算法不同，从而出错；
●可能因为开发埋点的时候不小心弄错了，从而出错；
●可能因为开发实现某个相关功能的时候，实现方式的不同，导致连带影响到数据偏高或者偏低，从而出错；
数据出错的可能性很多，因此，在说出“从数据结果可以看出”这句开场白之前，先去了解清楚数据本身是否出错。
这么做的好处：
●不会把时间浪费在错误的数据上；
●对数据分析会有更深入的理解；
●更容易得出真实的数据结果。
4.产品材料一定要文字留档
这是个非常重要的事情，请一定要记住。
刚进公司的时候，我发现公司里居然没有产品文档可以共享：了解产品基本靠多使用；要修改某个功能，基本靠经手人的记忆力。这样是非常传统并且不科学的方法。一旦出现经手人离职的情况，接手人就不知道怎么办了，说不定得让程序员找对应的代码才能解决问题。而其中最重要的是：产品的增删演变历史以及对应的需求文档。
这么做的好处：
●出现问题或者需要优化的时候，可以根据文档找到具体参考；
●从历史中了解变迁，有助于需求的管理；
●有助于项目的交接。
5.需求要对接完整
工作中会经常出现要和第三方沟通对接需求的情况，这个第三方有可能是公司外部的，也有可能是公司内部其他小组的。
有些产品觉得既然是技术对接，那么所有的事情就都可以等技术对接的时候再去做咯，然后就把所有的东西都丢给技术了。但实际上，真是这样吗？
●也许流程可以先梳理起来；
●也许对接文档可以让对接方先准备起来；
●也许测试环境可以让对方先搭起来；
●也许要配置的接口可以让对方先设置起来；
Tips：和第三方对接，本来就存在很多坑（文档不齐、接口不OK、对接时间超长等等），产品最好要能够在对接前期先准备起来，这样程序员在对接的时候也会比较方便和省时间。尽量把对接控制在可控制的范围内，而不是任由发展。
这么做的好处：
●和你合作的程序员会比较舒服一些；
●对接完成的时间相对可控一些，从而计划好的上线时间也相对可控一些。
6.要做好准备再拉人开会/讨论
越是工作到后面，越是讨厌开会。为什么呢？
●往往没有一个讨论重点
●有重点，但是都是头脑风暴
●没错，头脑风暴是好的，但是同一件事，如果每次开会都是头脑风暴形式的，那么是非常让人心烦的。
因此，无论是开会还是讨论，都应该在之前就列出讨论的主题、围绕主题的一些点，这样大家就可以根据内容进行有条理性的讨论。从结果上，也更容易有效果，搞定事情。
三、个人思维方面
1.不要害怕变化
举个例子，产品比较小的时候，需求可以有很多，面临的方向也可以有很多，大家都在进行调整。这个时候，有可能会因为某些因素（公司要求产品盈利等等），而出现原本安排好的下一版需求没办法做了或者推迟，优先做其他的。而这时你已经做完了所有的需求分析，一旦改变，那么就要赶时间做新的东西——这个时候，该怎么办呢？
我能理解，其实很多人会因为个人原因去拒绝这种变化；大家都是人，怎么会不明白呢？
但是，做产品人不可以这样——因为有可能会因为你的坚持，导致团队在做错的事情。这个时候，需要考虑的不是个人增加工作量的问题，而是对整体产品好不好的问题。如果确定对整体产品比较好，那么就该摒弃个人的负面情绪，顺势好好的执行下去。
这样做的好处：
●对整体产品好、对团队成员好；
●顺便锻炼自己的应变能力和心脏承受能力。