产品经理是做什么的？我目前的理解是，他是一群想出解决方案，解决问题的人。创业者转型做产品的人，我会在这一年半的时间里给你我新的见解和原则！
本文的产品经理方法论仅供参考。请不要完全模仿。产品经理要有自己的灵魂！我已经意识到真相，但我现在不能做所有的事情。请不要在道德上绑架我。谢谢你。闲话少说，给你点信息吧。
一、思维模式
思维模式是我们部门老板邓主任经常跟我们说的一句话。那么什么是思维模式呢？
广告:这一年半的成长，感谢你不断的拐弯抹角和打磨，谢谢。
我理解的是，每个人在思考产品和给出解决方案时都形成一种固有的思维方式，并且因人而异，所以每个人都必须形成自己的思维模式。不是强制要求每个人的思维模式完全一样，但是你可以借鉴别人好的思维模式来实现自己的方式。
定义:用技术MVC架构思考和解决问题。[我的思维模式]
解析:
m:数据库的底层，也就是交易的本质。v:表示层，体现在原型界面，也就是我们大家看到的各种载体上UI设计的页面。c:业务逻辑层，即各种业务流程在各种事务之间的流转。所以我思考问题的顺序是:首先挖掘这个需求背后的交易本质和价值，然后分析涉及到的各个环节的业务流程，最后用原型接口串联整个交易流程。因为我的技术背景，我希望在做产品经理的时候，把经典的MVC技术架构和我思考问题的方式结合起来。我不知道我是不是第一个提出用mvc架构作为思考问题的思维模型的产品，但我不想成为最后一个。
二。工作方法
1.如何需求调研？
了解问题现状:问清楚需求者遇到了什么问题，想解决什么问题，哪里不舒服，哪里疼，不解决会怎么样。最后，记录需求，与需求方确认。现有业务流程:问题出现了，那么你现在用什么方式避免这个问题？你现在的业务流程是什么？流程中你想做哪些优化？功能:这个问题解决后，会给你带来什么好处，产生什么价值？可行性分析:对结果进行优先排序并及时反馈。做还是不做，必须给出合理的解释；需求者说的不都是需求，要自己筛选；他说的痛苦，是片面的，要追求问题的本质，他想解决什么问题？
2.如何评估需求？
产品原型+规则:
在评审之前，你必须独立思考这个需求所涉及的所有规则。虽然有些情况可能自己考虑不完全，但是一定要自己深入思考。否则打电话给其他项目组成员是极其不负责任的。
在这里，和我之前做项目经理时的思维方式完全不同。所以我不得不改变我之前固定的思维模式。在这个过程中，出现了一些困难。幸运的是，我活了下来。
初步产品和需求方原型审查:
自己画出来的原型和规则还得和需求方核对，确认是否符合初步预期。如果没有，就要及时调整新的原型+规则，如此往复，直到需求方满意。
产品的初步技术原型审查:
需求端完成了，就需要项目组的技术成员单独完成。技术和需求方关注的角度不同。需求方就是通知它有这样的页面和规则。技术，会问为什么会有这样的页面和规则，能不能解释清楚。如果不能把技术提出的问题解释清楚，就修改原型+规则，直到任何技术都没有问题，这一轮评审就结束了。
组织产品项目团队的所有成员正式评审:
当需求和技术都确定下来后，召集项目组的所有成员，组织一个大型会议室，并正式审查系统的当前版本将是理所当然的。最终调整的prototype+规则必须与项目团队的所有成员同步。如果这次形式审查还有疑问，原型+规则要重新调整。如果没有疑问，那么项目评审成功，顺利推进到开发阶段。
项目日程安排:
与产品技术讨论项目进度，并向需求方报告最终上线时间。如果有延期的风险，一定要提前告知需求方，并给出合理的理由。
在线验收:
测试并接受需求后，进入产品+需求方的接受阶段。此时一般处于灰色环境，不会影响正常上网数据。双方同意上线后，对上线流程进行了测试，项目当前版本上线成功。
3.如何自己工作？
遇到问题，至少先想到解决办法，再和别人沟通。
不要没想清楚就和别人讨论一个问题。如果真的没有想清楚目前的问题，可以咨询相关人员，然后自己搜索答案。
凡事都有反馈。
出于尊重，任何人任何事都要反馈。哪怕一时无解，哪怕一时忙碌。看新闻不回复，容易引起误会，让别人失望。
多听少说，不打岔，不强加个人观点。
这更像是礼貌的方式。如果真的要打断，请说:对不起。有时候产品经理组织会议，作为主持人要打断大家偏离主题的话题，要有驾驭场的能力。不是不尊重，我们只是想让会议更有效率，更有价值。产品经理的会议纷繁复杂，如果控制不了领域，会浪费极其多的时间；别人在讨论的时候，不要用自己的主观意识去诱导别人，误导别人。尤其是需求方的吐槽，让它畅所欲言，让它开心。然后，自我总结挖掘问题的本质。
始终关注问题状态、业务流程和功能价值。
这三点缺一不可，非常重要，非常重要，非常重要。公司体制改革的时候，我吃了不少苦头，因为我还是小白产品，没有自己的思维模式，没有关注问题的现状，没有关注现在的业务流程，没有关注功能的价值，给我后来做的产品挖了很多坑。导致上下游系统嵌套太深，坑越来越深，很酸。
你必须对上游和下游系统有所了解。
这也是一种很深的感受。很多时候，各个系统的产品只专注于自己的三分之地，思考需求和问题，没有把涉及的上下游系统考虑进去。这样一来，我们自己的系统就没有问题了。这样一来，串联起来的上下游系统就暴露出各种各样的问题。
有时候，我能理解我的系统需要不断，要加班赶原型写规则。我怎么会有时间去了解其他系统？但是，时间就像一个X沟，挤挤还是有滴，大家。
控制自己的情绪，不要激动。
产品，被质疑，被颠覆，diss完全正常。
你会做产品吗？你做了什么垃圾产品？我想换产品，你不能。能画出原型吗？你想清楚了吗？这个项目的意义是什么？你是哪种垃圾？
铁，冷静点，阳光总会在雨后落下，甘巴！
设身处地，保持换位思考。
不同的人，你要把自己切换成不同的角色，尽量和他们保持同频，了解他们的想法和想法。这是非常困难的。我就说，还差十万八千里。
对过程和结果都要负责。
很多时候，我们明白我们要对过程负责。然而，其实我们更有责任。产品上线，任务完成了吗？迭代之后能不迭代吗？产品的生死与我无关。反正我已经做好了。
这些想法，我认为，都是错误的。我们只做到了0到1，1到100，还有很长的路要走。要有产品主应有的情怀，创造更多的社会价值。
你必须比任何人都熟悉自己的产品。
自己做产品，就要完成输出。至少有原型+规则+操作手册，如果有视频就更好了。一是容易传承，二是以后容易记住。有时候我负责的系统有点多，有些功能忘记了细节，有信息的好处就充分体现出来了。希望你们的产品能为子孙后代种下树来乘凉。
4.如何与项目团队成员合作
我们应该像一家人一样互相尊重，互相爱护。
因为可能是技术背景的产物，我更倾向于技术相爱的情况，而不是网上报道的拳打脚踢的情况。这个因人而异。反正我不会和技术翻脸。
从用户的角度写代码
我经常提醒自己项目组的技术，不要把代码写的烂熟于心，多想想背后的意义。如果你是用户，你会使用这个功能吗？价值是什么？有些技术很好，根本不用我提醒。相反，他们在很多情况下可以给我很大的帮助。
你有一个锅要打。
产品，而且很多时候是背锅的人。有时候，项目组其他成员的锅，我觉得没必要追究，是我们的锅。然后单独去找发现问题的项目成员沟通，引起他们的注意。
我不为难你，但请不要给我挖坑。
说实话，如果我要认真的话，我可以自己评估一下技术同事估算的工期。我没有干涉技术评估的工期。我没有放手，但我尊重他们，评估他们自己的发展时间。自然，我心里有了一杆秤。不过，别总在快上线的时候跟我说延期。评估工期不是儿戏，请认真对待。我喜欢未雨绸缪，任何风险都提前告诉我，这样我就可以控制项目的进度。
所有新的要求都必须经过我的批准。
所有要求都要经过我这边过滤。通过一些小的改变，需求者可以直接与技术交流。但是你得告诉我，我同意了才能改。如果我不同意，我会告诉需求者和技术原因。
5.如何与项目组以外的同事合作？
关键人物交流
对于外部的团队合作，一定要找关键的人，能做决策的人，有话语权和决定权的人，这样沟通协调事情才能事半功倍。
借助外力
如果外部团队的相关关键人员不配合，请上级领导协助，并告知整个情况。反正就是一步一步举报，直到这件事情有个结果。不要害怕得罪人。我们是做事的人，不关心人。
所有正式决定都必须记录在案。
所有正式决定都必须保存在数据中，以防止双方在未来忘记或争吵。
三、经常遇到的坑有哪些？
历史数据
任何体制转型的大问题都深深困扰过我。将数万条按照旧规则的旧数据与系统改造后的新规则进行匹配，并保证这些数据的上下游系统能够贯通，是一件极其困难和麻烦的事情。
没有技术空，导致项目延期。
有时候，被这样困住，让我无言以对。本来大家都玩得很开心的上线，突然技术过来说我这里不空搞你的项目，要搞其他更重要的项目，你的项目要延期。一次没事，一次又一次，你开心吗？你有好的需求吗？
缺失的技术缺陷
考验小哥哥小姐姐其实很厉害。没有他们，一个项目上线肯定会出现更多的问题。但是，米白有一些缺点，上线后仍然存在技术缺陷。如果重要紧急，要求队员加班必须解决；如果不重要，不紧急，不要让人家加班太难。设定一个宽松的优化时限对双方都有好处。技术好的人，不要为难他们。
需求的变化
另一个长期存在的问题，需求变化带来的风险，是非常麻烦和严重的。但是要根据自己的经验和能力来判断这种需求变化的影响范围。如果影响小，能改就改；如果影响很大，必须作为风险上报；如果它影响了思维模型中的底层数据结构，则必须报告为严重风险。
迫切的需要
我最怕这种人，不讲道理，霸道。整个项目的正常上线流程我不清楚，现在和一周内都要问。谁的事情不紧急，谁的需求不重要？如果你现在想要，我给不了。我可以快速评估小需求，尽快上线。我今天就尽量上线，绝不拖到明天。但是，大需求的过程还是要走的。
影响上游和下游系统
上面已经提到了，再次强调其重要性。我觉得不仅仅是产品经理，整个项目团队都应该考虑这个问题。
缺少一些原型规则。
这个锅，是产品经理的，没想好。然而，我不这么认为。项目被需求方和所有项目组成员审核，大家都没注意到。我们不小心错过了也是无意的。我们只能通过不断的刻意练习来尽量避免这种问题。
项目团队的临时替代
在项目开发中途，技术突然离职或者被其他项目借调，导致项目突然风险上报，也容易措手不及。如果技术离开了，我们必须尽快找人接手我们的项目。如果技术被附议，我们的产品还得了解具体原因，想办法解决。最终目的是保证项目的正常开展。
修复数据
当数据在上下游系统中流动时，不可避免地会出现一些错误的数据，这些数据在系统上是无法修改的。这时候只有通过技术手段，才能在后台修改这部分问题数据，保证数据的正常流动。
忙于杂事，无法专注于原型+规则。
很多时候，我们会被各种琐事打扰。所有需求者的需求都很迫切，但项目的正常进度却被各种杂事和会议拖慢了。很多事情和问题都要处理；很多会议，我都要参加。这时候，高效处理问题并给出解决方案，高效讨论会议并达成会议目标就显得尤为重要。在这一点上，我们还是坚持以物待人的原则。
四。项目延期了怎么办？
看到这里，相信你也发现了，项目最大的风险就是项目延期。因为延误，后果可大可小，因项目而异。那么，如何解决呢？
查明原因
项目延期原因:需求变更、原型+规则考虑不全面、技术bug、项目工期评估不正确、项目团队成员突然变更等。哪个原因或者哪些原因，搞清楚了，再对症下药，争取下一个版本或者其他项目，不要再做了。
制定解决方案
可怕的是，连产品经理都无所适从，无解。
报告风险
所有项目都被报告为风险，这导致了延迟。如果应该知道这件事的人不知道相关原因，那就说不通了。而且，一定要给大家一个合理的解释。
摘要
感谢这一年半来所有帮助过我的公司同事。我取得了一些进步。请在剩下的时间里照顾我。
本文由@飞猪会爬树原创发布。每个人都是产品经理。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
