我发现身边许多产品经理工作时间长了后，很少有一部分人会总结出自己的方法论，反而就是一个需求又一个需求的做，变成了一颗产品研发中的螺丝钉。
其实我们在完成一个产品设计到研发上线，许多错误都是会重复犯的，这些错误会影响直接自己在产品工作团队的影响力甚至是所尊敬程度，比如你是否就有遇到过一些同事因为你的产品经理工作方法，被吐槽你不专业。
恰好，作为一个小公司的老板和产品负责人，把我经历过那些影响产品经理靠谱、别人尊敬程度分享下
1.不重视需求文档
如果想避免自己被研发团队说是一个嘴炮，那么就得十分重视需求文档，首先就把需求文档的格式、排版以及结构都要罗列写出来，不能少。
需求文档的字数不需要太多，同时我们不能为了字数而写需求文档，但是需要把一个功能设计、系统设计将清楚，包含里面的业务流程、系统功能模块数量、各个功能模块是干什么的讲解出来。
2.原型一定要有，而不是胡乱画
在有的公司，产品经理会坐在设计师旁边，通过口述的形式，指导设计师帮忙完成自己的产品设计DEMO方案；还有的公司因为没有标准，就导致原型设计变成了高保真原型，直接跳过了原型设计图的概念。
这就会大大降低产品经理的专业度、和产品设计环节存在感。因为一个好的产品设计方案，一定要经过和业务、技术、老板等多方面确定沟通后输出的，所以不能是因为竞品长什么样子，我们就马上做，产品经理需要去找到对应的同事评估，同时原型设计图一定要漂亮，包含在排版、布局、色彩使用上。
布局：
布局应该符合用户在实际场景的操作习惯，比如移动端的APP原型设计应该符合安卓、iOS的系统交互规范，导航栏位置、返回按钮、放大、缩小操作等应该一致。
排版：
需要和实际上线所达到的排版一致，比如信息流是列表式，那么原型设计方案应该是列表式
色彩：
颜色不超过3类颜色，比如可以通过黑色、浅黑、灰色来表达页面里面的按钮、功能入口和交互操作。
原型设计应该可以在几乎没有产品经理讲解的情况下让开发、设计师等阅读者看到后即可理解原型表达的什么功能， 产品是用来提供什么服务的，同时里面的文案、排版都要和实际上的产品数据一致，不要用XX、或者省略号等来代替。
如果想增加产品经理自己的信服力，能够得到工作同事的尊重，原型、文档的能力是一定要达到以上面的标准的。
因为实际工作里，产品经理工作和大家都是平级，只有自己再工作中投入了时间、精力，大家能够认可你的工作价值，而这两点是你工作结果的展示。能够给出一份实实在在的需求文档、和原型设计方案，至少降低了实际开发过程中需求的偏差，同时还增加了需求的可行度。
3.具备产品经理的owner意识
提到这一点，有可能产品经理会说：“我自己很负责呀，从产品设计到需求上线我都跟着的，有什么问题我都会及时收集需求，并且进行规划。”
但实际上真正的产品经理owner意识，我认为一定不仅是完成自己的需求，还要善于接受外部的需求，比如业务方的需求、运营的需求，在一个已经上线并运营的产品里，往往产品经理的需求大部分是来自业务方的，我见过不少产品经理为了避免麻烦，会把需求推给别人，许多PM只是在为自己的需求做产品经理owner，但是没有考虑到业务。
可是只有让业务用起来的产品，产品的价值才能体现。
能够在下班时间，可以为其思考优化项和改进建议，这也是非常有少人能做到的，虽然我不是提倡大家加班，但产品经理职业就决定了你要对你工作的产品负责，只要产品上线了，都应该处理，在大厂里每个互联网产品都有7*24小时的运维工程师维护，正是因为这些产品随时都有用户访问、和用户使用，还有大量的订单交易，如果产品或系统出现问题就会直接影响公司收入，甚至是造成口碑大幅度下降。
4.不重视测试环节
对于一个新产品来说，要想极大的提升用户留存率，那就一定要重视刚刚上线的用户体验和基础操作流程。要是新用户刚注册登录就发现了产品BUG，那么自然就会快速流失了。
所以PM应该特别重视测试，不要把测试的工作丢给测试工程师，自己只做功能验收。和前面的产品owner意识相关，这也会导致产品上线效果不好，要么就是功能逻辑有问题，要么就是功能按钮和文案不对，或者就是数字和金额对不上。
因为及时通过缜密的需求评审、开发评审，仍然有一些需求会随着政策、技术实现等问题无法完成。所以在测试环节还能发现产品设计不合理的地方，可以再测试版本里进行修改，要么就变成新的优化需求到下一个版本实现。
还有的产品上线时间长，积累了大量的功能，产品经理并不熟悉以前的旧流程和功能设计，只知道对于新功能，所以还应该和测试同学一起评估新版本在以前的主流程是否有影响。
5.业务未来的发展和系统的可维护性
产品刚开始立项，我建议一定要考虑产品的业务是在什么行业，而找到最佳的技术选型，比如是用单体架构还是微服务的形式，在当前团队资源下，应该优先选择哪一个产品形态、用什么样的技术语言， 这都影响了未来的维护成本。
在这一点我们PMTalk就深受其影响。早期团队因为只有PHP开发，导致后续系统的维护性在没有PHP开发后，变得很差，除非招募PHP开发同学，则没有办法完成系统新功能的建设和维护。
还有就是早期选择了开源系统，以为开源系统会降低开发成本，结果就导致后期功能迭代变得异常复杂，开发者需要先查看以前的源码再定位问题，进行修改，变得非常复杂。
所以互联网软件的产品经理， 一定要尽可能把未来的业务、用户量、服务体量、用户使用场景描述清楚，通过和后端开发或者架构师帮你评估，减少你走弯路，要么就是产品经理自己要懂技术自己可以进行修复。
而因为技术选型失败，导致需要花时间、金钱来重构特别影响士气，因为功能没有新增，业务使用老系统体验差，还需要花时间等待。
以上，总结了一个靠谱的产品经理的5点基础。希望可以帮助到你，成为一个公司里面受人尊敬的产品经理。