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