PM在YY...作为强势的技术来回答一下吧。说明白WHY，HOW，WHAT就好了。
我想点两个赞，u can u up，no can no bb 什么的。
微软的win8之父年轻时候也是一个PM应该是微软最伟大的pm之一了吧。他有一天和程序员起了冲突，程序员说必须有两周才能干完，他说项目等不及了。就这样冲突一直没有一方让步，直至一周后，这个PM带着自己写的code给程序员看，他只用一周就可以这些功能。所以产品经理还是要懂一些技术才能和程序员更好交流
我觉得碰到强势的工程师是一件好事。同时，别人拒绝你的需求未必是一件坏事。
作为产品经理，你的任务是：
1、想清楚需求，并且让合作者认同你的需求（觉得这个需求应该满足，有一定的重要性）；
2、想清楚解决方案，并让合作者认同你的解决方案
如果对方完全不认同你的需求，请考虑你的需求是否合理；
如果双方共同认可需求，只是你的解决方案被吐槽说无法实现。
此时问自己两个问题：
1、这个需求紧急么？
2、这个解决方案是唯一可行的么？
如果不紧急，那么慢慢的多次商量。我周围的人们就总说 念念不忘 必有回响。
通常情况下，请相信你的工程师，想另一个解决方案吧——车到山前必有路，一定会有其他解决方案。
首先，要让技术积极面对本产品，如果你的技术团队对本产品都抱怀疑态度或者根本没信心，他们是不会有主动高效地去完成产品开发的。
其次，又要讲人格魅力了。其实这东西很虚，所谓能依靠人格魅力来影响弟兄干活的人，我想也没有几个。不过我觉得，一般产品能做的，有这么几方面：不要把自己处于高点，你和做技术的弟兄是平等的，不要总是以责难、指导、下命令的形式来待人；要理解技术的苦处，要懂得体谅他们通宵加班的痛苦，有条件的情况下，和他们一起加班；适时请大家吃顿饭（反正公司报销，算借花献佛）；偶尔也要告知弟兄们，自己也受到上层的很大压力，适当地装一下可怜。
最后，要懂得一些技术（我说的是了解，不是精通）。一些逻辑性的东西，必须要懂得。如果技术说无法做，要和他坐下来沟通，看卡在哪一个具体的点上。譬如某一个功能做不了，不是简单地就做不了这个功能，要找到具体原因。这些技能，其实并不需要懂得如何开发，只要有基本逻辑能力其实还是能够做到的。如果确实是技术问题，可以向公司的技术中心求助（神马？你们公司没有技术中心？那找高手求助吧，武林高手在华山）
What's more？有人说，这样做，产品经理就管得太杂了。嗯，这个问题确实很麻烦，但是确实是必须得面对的。所以，向老大请求要个产品专员吧，还是技术出身的产品专员最好。
其实技术很讨厌别人说”别人能做，为什么你就做不了“这类的话，如果有类似例子，最好给技术例子，”是否可以研究一下这个例子，看看别人是怎么实现的“
技术也有技术自己的想法，他们会给产品很多各种各样的建议（虽然我不想诋毁在座的某些技术，但是我认为在中国这样方式培养的技术，多数产品需求都是不靠谱的），千万不要当面诋毁或者嘲笑他们的想法，要耐心地和他们分析，为什么要这样做，为什么不能这样做。
在开发过程中，技术经常会产生质疑产品设计的情况，不要以权压人，说一些”我是产品经理，这个是我的决定，你不懂就别乱讲，照做吧“这样的屁话，虽然烦，还是得认真告诉他们，为什么要这样做，获取他们的赞同，他们对产品的积极性也会提高不少。
首先，要让技术积极面对本产品，如果你的技术团队对本产品都抱怀疑态度或者根本没信心，他们是不会有主动高效地去完成产品开发的。
其次，又要讲人格魅力了。其实这东西很虚，所谓能依靠人格魅力来影响弟兄干活的人，我想也没有几个。不过我觉得，一般产品能做的，有这么几方面：不要把自己处于高点，你和做技术的弟兄是平等的，不要总是以责难、指导、下命令的形式来待人；要理解技术的苦处，要懂得体谅他们通宵加班的痛苦，有条件的情况下，和他们一起加班；适时请大家吃顿饭（反正公司报销，算借花献佛）；偶尔也要告知弟兄们，自己也受到上层的很大压力，适当地装一下可怜。
最后，要懂得一些技术（我说的是了解，不是精通）。一些逻辑性的东西，必须要懂得。如果技术说无法做，要和他坐下来沟通，看卡在哪一个具体的点上。譬如某一个功能做不了，不是简单地就做不了这个功能，要找到具体原因。这些技能，其实并不需要懂得如何开发，只要有基本逻辑能力其实还是能够做到的。如果确实是技术问题，可以向公司的技术中心求助（神马？你们公司没有技术中心？那找高手求助吧，武林高手在华山）
What's more？有人说，这样做，产品经理就管得太杂了。嗯，这个问题确实很麻烦，但是确实是必须得面对的。所以，向老大请求要个产品专员吧，还是技术出身的产品专员最好。
其实技术很讨厌别人说”别人能做，为什么你就做不了“这类的话，如果有类似例子，最好给技术例子，”是否可以研究一下这个例子，看看别人是怎么实现的“
技术也有技术自己的想法，他们会给产品很多各种各样的建议（虽然我不想诋毁在座的某些技术，但是我认为在中国这样方式培养的技术，多数产品需求都是不靠谱的），千万不要当面诋毁或者嘲笑他们的想法，要耐心地和他们分析，为什么要这样做，为什么不能这样做。
在开发过程中，技术经常会产生质疑产品设计的情况，不要以权压人，说一些”我是产品经理，这个是我的决定，你不懂就别乱讲，照做吧“这样的屁话，虽然烦，还是得认真告诉他们，为什么要这样做，获取他们的赞同，他们对产品的积极性也会提高不少。
90后上司强势，其实是利用强势的外表掩盖经验与知识面的不足。但是经验不足的上司或许也有优点，例如人际关系可能相对简单，暂时不能纯熟地耍手段，和在你背后捅刀子，除非他性格特别黑暗，从小就腹黑。
作为程序员，架构师，但是同时自己兼任产品经理职位，并且经常和客户沟通的我来说一下我对于这个问题的体会：
1. “技术上实现不了”的技术潜台词：“技术上性价比不高”
技术上确实有性价比不高的东西。可能是和当前能力不匹配，可能是和技术选型冲突很大，也有可能是某需求的背后是众多大牛日思夜想要解决的终极难题。
“性价比不高”的意思是这条路可以走，但是走这条路会花费过多的资源：时间，人力，技术能力，业界对于某问题的一般解决水准，学术界对于某问题的前沿解决水准，相应的工具和技术堆栈。如果你的公司，团队，个人的目前的资源和水准并不足以挑战某些问题，则不应该给予此类问题过高的优先级。又或者要解决某些问题确实可以解决，但是解决所花的时间或成本会大大干扰主线任务，并且很可能导致工程超期，则不应优先解决。
2. “技术上实现不了”的针对PM的心态的潜台词：“你丫是傻叉”
你丫净扯些没有用的！不会写程序的PM不是好的需求方！懒得理你但是又不想直接说你是傻叉就用技术上实现不了这样的话！整天看些PM修炼集锦写些天花乱坠的文档搞些什么人性的设计真的大丈夫？你思想有多远我们就能跑多远么？你知不知道写程序也是一个工作，也是有轻重缓急和工作速率之说么？还有，写程序并不是从零开始的一个过程，每一段程序都有它的前后积累以及上下文支持的，并不是你一句话就说出来那么简单的。
导致这个问题的最主要的原因是：
PM方处理问题domain和程序员方处理问题domain本身的巨大认知鸿沟。
这个里面细讲出去就无穷无尽了，基本上要向程序员把全人类的所有方面都讲个遍，再让PM自己达到程序员的程序能力和经验，才能认识到上述鸿沟的巨大。这还不算解决鸿沟。
这个问题，和所谓的“我准备创业，万事俱备，就差一个程序员了”的问题是同一个问题，只不过后者表现地更加极端一些。
3. 如何（部分地）解决这个问题
广义的PM方，其实就是CEO，创业者，需求方，甲方，客户，以及市场。
广义的程序员方，其实就是架构师，CEO，创业者，以及自己所创造的技术/产品的需求方，第一个客户，和市场。
在大公司里面，这个问题基本是无法得到满意的解决的：
因为每个人的JD都限制了他的视角的扩大化。每个人都是他所在的局部信息孤岛的受益者和受害者。大家忙着满足KPI之类的东西，大目标是什么，也成了一个文档中写的东西。
而在小公司里面，或者创业团队里面，这个问题更加无法得到令人满意的解决：
看起来小团队会更容易形成共识，但是这个并非尽然。另一方面因为每个人的视角的扩大相应地要求他的认知水准和对于事，物，人，时，以及自己心态的把握能力要成倍地提高。而且一个人的视角和见识能扩张，但是他的技术能力的匹配度则很难以一个非常快的速度扩张，小团队会经常面临能力匹配不足够的问题。
4. 唯一的解决办法：强
解决办法就是变强：某人很强，你很强，你所在的团队很强，你的团队所能够匹配和动用的内部资源和外部支持很强。
怎么才能强？一个简单的办法是prioritize，做事有先后与轻重缓急，想问题也得区分重要度，要走的路径规划好了，又要能够坚持又要能够变通。不浪费资源，少浪费时间，战略和细节都不能差。全局想的清楚，局部看得明白，细部做得踏实，时间把握地恰当。能避难，也能迎难。真的要变强，需要错误试错和时间，也需要机会经验和视野。简单来说就是一个字，强人所难。
5. 小更新一下，“强人所难”的意思有两方面：
1. “强自己/别人所难”，就是勉为其难，把难以解决的部分，用耗时，毅力，其他方面的资源，其他方面的人员等办法，乃至于“拖字诀”（拖也是需要能力的，就是面对压力的能力），把这个很难的问题绕过去，或者变相地部分解决了，或者延后解决。强自己所难。如果push了别人，或者fail了别人，则是让别人为难，当然最后还是你自己为难。
2. “在大家都很难办的地方拥有超出寻常的强大能力”，就是说大家都趟不过去的河，你不知道怎么地就很轻松地过去了。比如说你是技术某方面技术超强，或者你是PM说服力超强，或者你是萌妹子让技术拿你没办法。在别人弱的地方你很强。
第一个强，强的是综合素质和心理素质，第二个强，强的是专业素质和专业能力。
这样你就能（部分地）解决（大部分的）问题了。
本回答的额外彩弹！！！！
请转到这个问题下面接受彩弹的洗礼！！！：
有哪些产品经理认为很简单，实则开发很难的技术？ - 前端开发
所以，重点是你要让他认同你提出的需求。
从这个意义上来说，技术“行话”反倒不如简单明了的说明你为什么要提这样的需求。
如果你的要求，技术真的无法实现（这就要求你有基本的技术功底），那可以跟他探讨为了达到目标，可以采用哪些其他的手段。
无法在技术上说服工程师，至少你们得在「目标」上达成一致或把技术说服。
大家都是平级，凭啥让工程师听你「发号施令」？
改需求只要说1句话10秒钟，人家要搞半天呢！
所以，让技术对要做的方案有认同，为什么这样做，为什么不那样做，目的是什么都讲明白。
甚至是，把备选方案也说出来，大家讨论。
只要目标达成一致，后面就好办了。
除非你是技术大牛，否则就不要在技术面前提「简单」二字，即使真的是很简单。后果自负。
产品和技术并非针锋相对，大家沟通不畅或者发脾气也是因为工作，互相都认为自己的方式可以将工作做的更好，才会有争执，这是一个大的前提。
另外就是公司上下都要确认一点，就是项目的领导者是谁，大家经过讨论以后谁来做决定，或者说，谁对整个项目负责，其他人必须全力配合。个人觉得产品经理应该拥有更大的权利，才能够成为整个项目的主导，这个权利需要制度赋予。
技术人员通常比较有经验，对产品的把握也有很独到而实际的见解，而产品经理如果不是技术出身可能有些专业问题难以理解，其实这些都是沟通的小问题，表达清楚了就可以了，做事的方法有很多种，只要有心通力去做。但不管是产品和技术都应该掌握更多的专业知识不断的提升自己。
另外就是，作为产品经理，作为一个项目的负责人，应该知道你的技术人员的技术水平，可以实现到哪一步，所谓知己知彼百战百胜，首先要做的是了解自己的团队，在与客户接触的时候也能很好的掌握尺度，不是所有人都是你的目标客户，尽量不要在技术人员说“我们做不了”之类的话的时候开发发脾气或者反唇相讥“那你能做什么”，先想好自己 的位置，你和技术实际上是一伙的，如果你接的案子确实不适合现在的技术做的话，那等于是赶鸭子上架，等于你在为难你的技术人员，在执行的过程中会有更多的摩擦和冲突，先找准自己的定位，然后去寻找目标客户。寻找目标客户也是产品经理应有的素质之一，过眼的肥肉抓不到就忘了吧，慢慢来嘛。
2、背后的问题：我相信这只是一个敷衍，而不是实在的答复。其中包含的问题可能是双方对时间周期的沟通问题、开发部门对项目规模的预估问题、开发部门对产品的认可度问题、两部门间关系问题等等。如果产品经理没有看出来，那赶紧上报自己领导换个角度去考虑问题，别硬磕了；
3、产品经理不要奢望去懂技术，关键是要了解技术部门的工作流程以至整个项目的工作流程，这样你的计划性和控制力自然就上去了。真要说去“懂”技术，呵呵，任何一个工种都是专业性很强的，产品经理的岗位也是，对不？
4、自己没有任何问题吗？
很重要的一点是意识到，公司雇佣你当产品经理的目的，就是为了让你带领一帮最优秀的技术人才， 设计人才， 数据科学家，律师等等做出好的产品。产品经理的作用， 不是让你做设计，搞技术，挖数据，因为你不是这些方面的专家。而是能够有效地利用好这样一帮人，让搞技术的人闪耀发光， 让设计师巧思灵动，让数据科学家柳暗花明，你就赢了。
所以，我的建议是，首先，要相信你们团队搞技术的人都比你懂技术并且承认这一点。我一般都会先说，你在技术上是权威，所以特别想请教你，从你的角度看怎么实现xxxxx。相信我，技术大牛最厌恶的就是产品经理自己屁也不懂却指手画脚，胡乱要求。要肯定他们的能力，问问他们想，好好讲讲你自己对这个产品的vision，问问他们如何实现。
第二点，如果技术不同意你的意见，研究清楚是为什么。是因为你们在乎的东西不一样（技术常常会在乎“这是一个碉堡了的算法”，而你在乎的可能是“到底大家会不会点这个按钮”。）还是因为你们对这个产品真正解决的问题没有达成共识。我的原则是，公司来的都是聪明人，聪明人之间意见不一致，估计是本身掌握的信息不一样，或者认定的目标不一样， 如果本身掌握的信息一样，认定的目标一样， 在乎的东西一样， 那你们估计多半会达成共识。
至今没有碰到过，因为SE觉得，没时间，成本太高，没有价值，而假称实现不了的。上述三个原因都是拒绝的正当理由。
技术方案是产品与设计共同探讨的，不是一方单独给出的。
产品的重心还是讲清楚what，why，when，how。技术上如果不可行，一定是能够讲明白的。
如果真有强势的，不愿意澄清的SE，那就换个人分析。如果这个强势的技术，势力还非常大，只要需求价值够大，可以换个团队。
我经历过一次，一群做了10年开发，转做产品超过10年的人，和一群做了20年设计的SE，围绕一个关键技术是否可行无法达成一致。一群人在会议室里PK了三天，达成一致后才最终结束。
一般来说，技术经过一段时间的详细分析，仍然认为不可行，都是接受分析结论的。当然一段时间后别的公司实现了该需求并上市了。这种情况也发生过，那是要算旧帐的。
2.做事要深思熟虑，在找技术，设计，测试，等等人前，先问问自己，这样是最好的解决方案吗？如果总是修改方案，换位思考，自己是否愿意总被改来改去。
3.谁强势不强势不是装出来，拿架子拿出来的。以职级来压人，只能得到背后鄙视。要让合作者打心里佩服。不断提高自身素质。
4.不断学习，扩宽相关知识面，但并不是要做全能。知道自己是干什么的，明白衔接领域的流程方法，以及所需资源。
5.与人方便，自己方便
其实，很多产品不尊重技术，也不尊重人。
1，不尊重技术人员的成长；认为技术跟说话一样简单，一学就应该会，一点就应该通；
2，不尊重技术人员的时间；认为技术人员就应该去加班，认为技术人员的时间，就是应该由他们去支配；
3，不尊重技术人员的自我；认为技术人员满地都是，随便招一个就能把不听话的技术替代掉；
产品经理除了必备技能外，对技术的了解是加分项，了解技术会让你和研发沟通更流畅，更好应对研发阻力。当然此外情商是算是必备技能，和情商低的产品合作真是生不如死。最后这句试用所有行业。
研发拒绝产品的需求，通常出于以下几方面的原因:
1. 欠缺尊重感: 作为产品经理的你，在心里是否真正尊重你们的研发人员？如果你并不认可研发人员，对方是能够感知的，继而产生本能的排斥，趋向于拒绝你的需求。
2.没有把需求赋予意义: 当你提出这个需求的时候，有没有同时告诉研发人员这样做的目的是什么？为了达成什么产品目标？人们总是对被赋予意义的事情更加上心。
3.需求逻辑不清晰: 排除了上面两个因素，那么最有可能导致需求被拒绝的原因就是你的逻辑不够清晰，或者逻辑上存在一些明显的的问题，这种就被称为不靠谱的需求。研发人员常常说，技术上无法实现可能是因为他们想不清楚你的逻辑要怎样被实现，也就是说你的逻辑是不清晰的。在这一点上，如果你有计算机的专业背景，一定会有帮助的，因为你会本能的去考虑如何用代码逻辑来实现人脑逻辑。你可以学习简单的编程，例如，把电影院订座系统的这个程序写出来，好好理解一下。
4.并非真是拒绝: 我发现有的研发人员是以拒绝需求作为一个讨论的开始的，他们只是说这个需求难以实现，其实是留了一个空间，让你跟他继续深入的讨论。这种情况通常是他们手上的事情非常多，已经产生本能拒绝的心态了，所以你就需要去论述你的需求具备更高的优先级。
a) 不要对研发人员说，这个东西实现起来很简单啊，除非你百分之百确认这个东西是件很简单。
b) 想清楚了再做，不要轻易的修改需求。研发人员很辛苦的。你一个想法，他们要写很多行的代码，你随便换一个想法，代码又要被推翻了重写。
1.产品经理懂技术是不是必须？
不是。每个职业角色都会碰到很多不同的对接角色，这些技能可没办法全学过来。
而且对技术难点的预判(不一定对)也会影响对产品的设计。
个人认为应该是产品大胆提需求，和技术沟通再减掉现阶段实现有困难的部分。
懂一些更好，可以提前筛去不靠谱的设计部分
2.关于关系远近
好沟通但能力不行，强势但能力一级棒，你选哪个，为了最后出好活，肯定要技术好的。
对方是否强势，个人觉得并不是问题，关键是作为提需求的你来说，心里是不是有谱，也就是你的能力行不行。
经济社会，大家都做好自己的事，关系好人家也不能陪你玩，满足你的烂需求，浪费自己的职业生命。一次两次成，多了则没戏。
所以多关注自己，你有理，你怕谁
3.过往经历
从自己经历来看，好的技术不仅coding技术好，而且思维缜密，能帮你过滤和改进，所以，沟通过程也是产品优化过程。
他们甚至能在业务层面给出好的建议，所以也要善待技术
不需要强势，君子求诸己，先换位思考再沟通。
一般很鄙视那些没有经过大脑就提出的需求。为什么这个需求，怎么做这个需求，遇到意外情况怎么办？这几个问题都没有想好，业务细节都没推敲就提出的需求，怎么可能做的好。
产品人员可以不懂技术，到一定要学会懂技术员。
1.心诚则灵
2.铁棒摩针
3.积累信任
4.寻找盟友
前提就是找共同点，争取站在一条船上
产品经理和研发方一开始就是在两条船上。产品经理希望产品的功能越多越丰富越好，提倡做加法；研发方关注产品的稳定性和兼容性，提倡做减法。从某种程度上，他们天然是对立的。
当一个强势的技术在以“这个功能实现技术上无法实现”为理由来拒绝时，不管是因为资源不充分或者技术上有难度，其实质就是，坚持做会影响到稳定性。
产品经理不一定要很懂技术，但一定要从技术的角度出发来考虑问题。
这个需求是不是可以分解的？如果需求能够分解的话，那么就一定要分解，而让技术能够一步步实现。产品的质量和稳定压倒一切，需求盲目而快速的堆叠也许能够占一时的先机，但对不稳定的产品，用户一定会用脚投票，而一旦用户形成了某个产品不稳定有质量问题时的观念时，基本你就永远失去了这个用户和受他影响的一批潜在用户。
这个需求在同类竞争对手的产品中有没有实现？如果同类产品已经实现了，那么产品经理应该有8成的把握可以坚持自己的主张了。因为这意味着这不是一个不可能完成的任务，而研发方用技术上无法实现来抵制就基本站不住脚，至少，大可以一试。
实现这个需求从技术的层面看有什么好处？实现新的需求就意味者改动，意味着投入资源，意味者带来不稳定。从技术的层面看，这就是代价和成本，那么产品经理如何引导研发经理看到回报。这个需求能不能开辟一个新的市场和吸引新的用户，能不能为公司带来收入，能不能提高公司的竞争力进而激励公司的股价。最直接的，研发方能不能学到新的东西从而提高技术水平和进行技术的积累。如果产品经理能帮助厘清成本和回报之间关系，相信研发方也会试着考虑考虑。
最后还要看公司的架构了，那个能够拍板的人一定要是能把投资和回报算得很清楚的。Ta最好是一个既懂产品又懂技术的。以技术无法实现或过分困难为由推脱开发责任并不应该视为影响产品的进度。
因为已经连开始都被开发人员拒绝了，还怎么开始呢？
这个时候的PM的最大问题还是在于沟通。
技术实现力度大，好，在资源紧迫的情况下，这是主要需求，我们就将需求中一些次要的部分降低难度，最次的办法是降低质量，保证功能上线。
没有所谓的不能做的事，只有不能做事的人。
如果产品不会技术，千万不要被技术人员所谓的不能做而难住。你要认真的问他具体哪里不能做，一定要让他一五一十的说出来，首先他就要理清自己不能做的理由。然后你再问他有没有更好的解决方案，因为这个时候的技术人员必须提供解决方案，然后你与其他干系人进行决策。
除了投资方是获得解决方案的，我们每一个人的存在就是为了解决一个又一个的问题，制造问题并不能有效促进项目的进度，要达到共识需要不断的沟通。作为技术人员，遇到较难实现的需求时，我一般这样做：
1、问清楚从产品角度为什么提这个（这些）需求。
2、觉得能力有限无从下手，那就直接说先研究再说，一定时间（1-2个工作日？）后给答复。
3、觉得有困难，告诉他困难是在哪里，需求所需要的成本。
4、如果在产品上有自己的考虑，就直接表达自己的想法。我想不会有产品人员在拒绝跟技术人员讨论对产品的看法。
沟通这些后，尤其是第四条，基本上就不会以“技术无法实现”的借口推脱。当然这是以“双方同一个团队目标一致”为前提。如果以上下级的身份来沟通，那就只好以“拿人工资，做好本职工作就行了”的态度做事。
一句话总结：与其命令技术人员去被动实现，不如让技术人员明白为什么这么做并主动去解决问题。从技术人员的角度来说，如果拒绝了产品的某些功能或改动,主要有这么几种情况:
1. 能实现，但是不能在时间点实现
2. 觉得这个功能不需要，甚至觉得提出这个建议是很可笑的事情
3. 看你不顺眼或者看老板不顺眼
根据情况去处理.
但是记住:如果你达到了让技术人员让步的目标,那么很可能与"做出好产品"这个目标越来越远.1. 产品懂技术有利于和技术沟通，节约时间成本，但不可班门弄斧，毕竟人家是专业的；
2. 无论技术还是产品，根本出发点应该保持一致，那就是大家在追求极致的用户体验的道路上精益求精。如果不在这个主旋律上，就很难谈妥了；
3. （建立在第二点基础上）技术同学也是人，有七情六欲。技术同学的抵触情绪来源于：a. 感觉自己被产品指使，不配合 b. 有产品sense，否定产品的想法 c.产品频繁更改需求，让技术觉得火大。
解法：a. 沟通的时候态度好一点，语气弱一点，陪技术加加班，请技术喝喝饮料，卖萌是很管用的。这样关键时刻才能刷脸。 b. 最好有明确的数据和清晰的逻辑来说服技术，最好最终结果能佐证你的预期。下次遇到这种问题时技术会很信任你。 c. 多体验每一步流程，确认每次操作可能存在的问题，在有限能力内，替别人考虑周全，与人方便与己方便。
1 了解技术实现原理
2 逻辑清晰
3 人格魅力
1.真是技术问题.这没什么好讲的,通过增加个人关系或者通过管理手段说服其去学习和修改.
2.没时间.进度很忙.那就通过修改进度什么的来做了.
3.懒惰,对产品没信息,认为加这个没什么意义.
4.技术对产品认识很清楚,并非实现不了,而是认为这个功能没什么意义或者需要大量的工作量来完成,而且这功能对产品的功能提升并没多大改善,反而有很高的重构风险.并不是说你是产品经理,你说了的功能就要加.这样的认识是不正确的.
最重要的一点是你要懂技术，不一定是要亲自开发，但是你一定要懂得更多，熟悉每一种技术的特点。
面对强势的技术人员，我觉得最重要的就是让他们从心里认同你的需求，自愿地去帮你实现，否则就算你只是在口头上说服了他们，最终的结果也未必能达到你的期望。当然在这个过程中，争吵是不可少的，但是双方都应该站在对方的角度作沟通。
所以说产品人员需要魄力与魅力，让自己带领的虚拟团队一致认同自己要做的事。
如果我搞不定会告诉你为什么:
1. 逻辑前后矛盾
2. 很多设计师的通病: 只有 UI 完全没考虑 UX, 或者设计师给的东西根本不符合你给的需求
3. 表述不清楚, 不如直接告诉我想抄什么好了
4. 想法过于迂回曲折却不知道到底是为了啥, 说说目的或许我会告诉你更直接的做法
5. 法律或者用户条款不允许这么做
...
我是PM，目前所属在电商部门，我们电商负责人特别想找自己的技术，这样一个是沟通方便，还有就是我作为PM，可以从一次次的配合中，学到基本的技术常识，虽然我学过数据库和C，但早忘光了，我可以补回来，但需要时间，所以有个自己人在技术团队里，会非常方便。
我目前的最大阻碍就是，技术部负责人看不上其他人，产品评估会上已经说可以做了，中途又在开发的时候，让执行的技术偷偷做了修改，而且不经过产品经理的同意，上线了才知道是改了的。这点我觉得很过分，我等于被架空了，而且没有被尊重的感觉。主要是！这个产品出问题，用不了，运营的需求满足不了，是我来担责任，不是技术。这个我觉得就是人品有点问题了，估计给我穿小鞋。在规划时就拉技术一块来，哪怕是旁听，发现问题他会及时提出的。
等你定案了，技术告诉你无法实现，他说服你很累，你改需求也累。
最重要一点，技术不是你的下属，也不是你家孩子，高高在上的命令，只能让他反感，消极抵抗。你可以告状吵了他，但换一拨也一样。其次，对事不对人，要把这个需求/项目分析清楚，明确自己的需求，有自己的立场和原则。
最后，技术如果以无法实现为由拒绝，要搞清楚无法实现的原因是什么，在我接触过的技术中，大部分原因都是这个：这个东西，尤其是已经迭代开发过几次的项目或者产品，其框架和技术选型其实已经制约了某功能的实现，很少真的是该技术人员水平导致无法实现。
2、站在他的角度去思考，尽量用道理去说服他，不要指望技术能和你想的一样，技术由于长期的工作在特殊的环境下，大多数比较孤僻、内向且不善于表达，这点需要你去体谅
1，你和技术平时相处的关系如何，结合你对技术的认知，与其他技术人员的沟通，分析出是技术不能实现，或者工期紧张，或主观否决你的想法。
绝不可以用强硬手段与技术负责人发生冲突，这样的后果只能是恶性循环更可能导致你的产品失败。 我认为你应该耐心的与技术交流，向他表达你对产品的理解让他对你和你的产品理解，对你们有信心，让他们产生兴趣，甚至可以请他吃饭等。我认为和技术负责人搞好关系加深工作与私人的友谊，是最好的解决方式。
本问题我比较有发言权，因为和我直接接触的技术就是一个比较难缠的家伙，呵呵，说正题：
1. 沟通：首先要和技术成为朋友（方法及尺度自己掌握），在中国很难分清工作与私人关系的，当你和他成为朋友（都是人，相信你能做到），一个好的开始
2.合作：前提要把自己的工作做好（不怕狼一样的敌人，就怕zhu一样的队友，你懂的），其它按照正常流程去操作首先个人感觉追求和技术人员说行话的这种想法和做法是错误的，而且很有可能会招来技术人员的反感（他们会说你是技术还是我是技术啊，你懂什么），如果能顺利沟通，那么很容易被技术人员带到技术实现细节，而不能从宏观上去看待整个产品的发展目标和轨迹。
——————————————————————————————————————
so，如何能说服技术总监和开发人员，个人认为功夫全在日常的积累了。
这种积累包括对行业的发展前景的认识；
包括对行业中的强劲对手动向和产品的理解；
包括对自家产品发展目标、定位、当前业务情况的理解；
如果这些自己能拍着胸脯的娓娓道来，那肯定不惧怕和技术大牛的对决了 强势体现在哪里？我看到的情况有2种：
1 不同意在规定的时间内完成规定的东西。
2 不同意产品设计，认为应该遵照他的想法。
针对1：往细了问，不能完成的原因是什么？时间太短，还是资源有限，还是实现难度大，还是风险较高。问到细节后，你才可以有针对性地说服他，或解决问题。
针对2：要么武断，你就听我的。但一般这样会引起更大反感和抵触不合作的情绪。另一种，就是鼓励对方说出自己的想法，再通过事实去说服。这部分工作很大程度上靠说话方式、逻辑能力。能让对方真的接受你的想法，或暂时同意按你的想法做。当这样也无效，并且你认为严重损害工作效率时，找上级是必须的。