在程序员眼中，优秀的产品经理长什么样？

编辑导读：与程序员打交道，是产品经理的日常工作之一。由于两者的知识体系和思维结构不一样，关注的重点不一样，所以在协同工作过程中，难免会出现一些分歧和摩擦，出现互相埋怨和吐槽的情况。赢得对手认可的才是真正的强大，那么，在程序员眼中，优秀的产品经理长什么样？本文作者对此展开了讨论，一起来看看~

一千个人心中有一千个哈姆雷特，对产品经理这个岗位，每个人都会有不同看法，但往往技术同学对我们的认可，是更值得关注的，因为它直接决定着产品落地效率和上线质量。

前两天参加了360内部组织的一次产品技术交流会，了解到我司技术大牛眼中优秀产品经理的形象，也借这个机会和大家分享下。

受技术认可的产品经理有何特征？大概可以总结为：上得了厅堂，下得了厨房，守得住寂寞，创得了辉煌！怎么理解呢？

01 对外部变化足够敏感

优秀的产品经理，要有前瞻性。

一方面，你应该是行业专家，对宏观大环境有足够认知，知道哪里有机会，哪里是业务增长点，哪里有坑，并带领大家规避风险，放大自身能力，跟上这些新趋势；另一方面，你应该对竞争对手敏感，知道大家都在做什么、怎么做的、效果如何，能基于你的判断，先于竞品占领市场。

尤其技术人员希望你在讲述产品功能前，先阐明需求价值、数据依据、结果预估，而不是凭感觉做事。

02 对内部业务足够清晰

即对自己负责的产品，要清楚用户在哪儿，用户有哪些场景哪些痛点，产品基于什么业务逻辑解决了这些痛点，带来了什么收益。产品经理要切实可行地把用户/客户问题转化为产品功能，设定业务目标并有节奏地推动落地。

同时，当需求过多时，不是只做需求的搬运工，而是要有一套中长期规划，尽量让当下方案在未来有可复用性和强稳定性，以便出现异常时能迅速找到替代方案。千万不要说两套完全框架结构不一样的交互方案，第一个版本上A，第二个版本推翻了又上B，会让开发人员崩溃的。

03 让自己的产出物足够专业

需求文档、交互原型、项目管理报告、需求分析报告、产品架构图、业务流程图……这些产品经理的日常产出物，撰写时务必学会换位思考，构建起和开发同学的同理心。具体包括：

1. 要能将业务需求/问题归因到正确的技术模块，最好对技术逻辑有认知；
2. 文档管理规范，需求变更及时同步；
3. 方案描述完整，逻辑完备，能考虑到异常边界情况。

此外，一定注意产出物的简洁易读，以快速理解落地为目标，避免“套模板”写文档。把字数堆的很多看起来很厉害，实际阅读体验会非常差。多用图、表，少文字描述。

04 和技术人员的沟通足够充分

沟通问题是老生常谈了，沟通是否到位，体现在：

• 开发前，对需求调研充分，方案合理，目标明确，能有理有据说服大家支持你的想法，认可要做的产品理念和方向；
• 开发中，关注人员分工、时间安排、成本消耗。当有变化时能及时通知到相关人员。
• 开发后，和技术人员同步数据，汇报时要能体现出技术人员的重要性，让大家有一种参与感。

关于如何说服的话术，这里贡献个小技巧，当技术人员不接受你的方案时：

1. 充分尊重对方意见，引导他说出反对理由，比如“因为我觉得用户在这里不需要XXX功能”
2. 对该观点先表示理解，提出自己也考虑过这种情况。但同样指出XXX功能适用的场景，能解决什么问题，有什么优点，如果不做有什么风险，会对其他模块有何影响等等。
3. 抛出同类产品类似的解决方案，借其他案例证明自己产品的可行性。
4. 提出：“很多方案没有对错，我们的想法都是主观判断，再争辩下去没有意义，如果我的方案实施成本不高，就先听我的，然后我们数据说话，出了事找我”，强调产品经理的判断力和目标意识，求同存异，但为快速落地，仍需要一个人来拍板，那这个人就是自己，因为自己会对结果负责。

通常这种情况下大家也就会表示认可，毕竟团队是为了同一个目标在努力。

05 总结

其实说了这么多，总的来看就两条，第一是要你足够专业，让我信服；第二是要能换位思考，理解我。因此，想要被技术同学认可，更多还是要提升自身专业能力，至于是否懂技术，更多是加分项，毕竟术业有专攻。

希望这篇文章能让你在和技术同学沟通时有所帮助，有什么想说的，欢迎留言与我分享~

#专栏作家#

申悦，微信公众号：互联网悦读笔记（ID：pmboxs），人人都是产品经理专栏作家，360产品总监，起点学院优秀导师。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议