感觉你像以前的我，以前我也搞不定开发，还是要多学习，多去了解，遇到事情多问几个为什么。

开发说太复杂，多问几个为什么，问问为什么复杂，问到最小颗粒度的原因后就可以了。

开发说需要做很多工作，让他讲讲具体有哪些工作，这些工作的难点在哪，是主观还是客观原因，问清楚。

后边又说目前做不了，那就是能做，不是能力不行，而是时间上不允许，那日、周、月、年全部做出来，时间不够，那只做日、周、月呢？如果他说可以，反问他年不就是把月的数据累计起来吗，这有什么复杂的？如果还说做不了，那就把最小颗粒度的原因、以及技术难点、主客观原因整理打包，以日报和周报的形式反馈给上级领导。

遇到讲理、讲逻辑的开发，我们以理待之。

遇到耍小聪明、胡搅蛮缠的开发，往死里问，抓他叙述事情的漏洞进行反击。

综上，还是得多学习，多去了解功能实现原理，久而久之，就会懂了，即使不会敲代码，也能cover住。

这个跟懂不懂技术，我觉得 其实没什么关系

最近，我这里有个财务产品，要把所有竖版的报表 改为 横版

原因，最开始设计这个产品的人，不懂业务需求，所有的财务报表都是竖版的，只为了多放一些数据

但是，现实中，财务的报表都要横向装订，竖版无法装订和使用，必须要改成横版

跟研发经理沟通后，答复，工作量太大，是否真有必要全都改一遍，现在竖版不也一样使用，让用户克服一下，以此就一直放着不动

解决方案：
1、讲用户需求，讲使用场景，告诉他这个事的必要性
2、讲这部分的收益，改了就有几十万的收入，不改就没有
3、找更高一层的领导去做判断

这年头，有几个老板会跟钱过不去？完全没有风险和技术难度的事，多干几天活，就大把的钱进账了

细想过往的经历，好像只有在我刚入职场时才会遇到技术困扰，听不懂技术说啥，什么mq，redis，分布式，而那时的困扰也不在于影响了项目，只是一种新人的迷茫。现在来总结为什么我没有遇到困扰，我觉得有三点吧：

1.我坚信没有开发实现不了的，如果开发有这种反馈，那有可能是我自己的产品方案有问题。所以如果技术上说不能实现，我只会问他我的产品方案哪里有问题，如果他说没有，我就会请他去评估方案并给出开发人天，如果人天很多就麻烦他细拆；

2.我不纠结于我一定要理解开发的实现方式，我的焦点一般在于各系统的交互节点、交互方式与交互的信息，具体开发的详细设计，我会以学习的目的了解，但从项目的角度我会完全交给开发经理把控。如果出现了生产问题开发又一时解决不了，我才会要求开发用我能听得懂的语言给我讲清楚他的开发逻辑，再从产品的角度出发告诉他哪里不符合业务需求，需要他自行再去设计代码的改动方案；

3.被开发欺骗最多的就是谎报工期，这种如果开发经理不负责不管理，那产品需要能了解开发的能力和性格才能避免被骗。可以分以下情况：
（1）小项目一般都是常规开发，用的手段跟以前差不多，可以找一个之前的项目做进行类比。如果第一次做，自己在项目中观察一下对应开发的工作状态，做一下估计里面有多少水分，了解了水分，以后再报很长时间，就直接给他工期打折就行，记住语气要怂，内容要狠～
（2）大项目一般都是领导会关注的。开发需要做任务拆解表然后做汇报的，如果领导没发现也没要求上线时间，各开发组也没内卷把时间缩短，那你就安心的按照他们的任务拆解表跟进，看最终他每一项的时间和最终的完成质量，基于此了解开发的能力和水分；

说实话其实不懂技术问题并不大，逻辑清晰会沟通就行。

1、产品自己要能理清楚功能相关的逻辑，比如要做网站的数据统计分析，自己要清楚这些数据是不是已有的，如果是没有的数据那么该怎么获取到，把详细的方案给到开发，开发去执行就好了（不建议去命令开发哈。），另外研发觉得太复杂，需要做很多工作的情况下，可以详细的了解清楚主要是什么地方复杂，需要做些什么工作，目前存在的阻碍是什么？对应的把前置问题解决了就好了。

2、如果是无法好好沟通的研发，那么你就找上级反馈你遇到的困难就好了，上级会帮你想办法协调解决的。

#产品经理挑战赛# day1 

不懂技术的产品，那就变成懂技术的产品。技术这个概念太大，我计算机出身的产品，但是也经常被研发说的技术内容搞懵。“懂技术”并不是一个什么高大上的门槛，完全可以靠自己的一些习惯和做事方法去改善。和研发沟通需求时，研发如果有说出一些不理解的技术概念，你可以依据研发态度去处理。

1、如果研发不耐烦比较排斥沟通。那你就结束无意义的拉扯，避免被忽悠，告知研发“你说的这个我不太理解，我需要去上网了解下再和你同步”，然后去网络上寻找一下其他大佬的类似做法，相关的实践案例等。在对实现的方案和技术难点有了一定解后，再进一步沟通；

2、如果研发态度好，也有时间和你解释。那可以让其拆分细化一下，讲解下其中的难点在哪，以及如何才能解决。搞清楚后，再理性的评估成本和方案可行性。

一来二去，在你下次处理类似场景时，这些已经有所了解的技术知识，也会帮助你更好地进行需求评估。

对“技术”的抗拒，在我看来很没必要。你从产品小白到产品大牛，期间不也是在不断学习不懂的知识么？这个过程可远比“懂点儿技术”要难太多了。“懂点儿技术”在我看来，区分的不是谁懂技术谁不懂技术，而是谁更积极学习，谁更畏惧学习。

1、搞好关系，让技术大佬从情感上信任你；

2、每个给开发的需求，自己先想清楚业务、数据逻辑，以及会受影响的点，目的是提高效率、减少返工，让开发大佬从能力上信任你；

3、跟开发提出需求时，态度要软，阐述要清晰；

4、开发说不能做，要问清楚原因，听不懂的地方要追问，明确原因后仍无法解决就告知上级，要协调资源还是其他什么。

最后还是建议产品懂点技术，跟用户沟通需求时可以快速评判难易，并且如果是做B端产品，对接的客户一般也是技术出身，所以产品懂技术可以让用户更信任你。有面向PM讲解技术的公众号或书籍，学习成本很低滴~

对于技术来说产品的所有需求都是他们未来的工作量，所以肯定是能砍则砍，能不做则不做；

面对题中所述的问题，仅一项其实整体工作难度不大，但量可能会比较大，技术反驳的理由大概只会是数据量大、影响服务器性能之类的云云，产品如果能够明确该需求的价值大于数据和服务器带来的影响，那尽管让技术做就好了；若无法衡量，纯粹是头脑发热的需求，那被拒了也是一件好事情。

总而言之，纯软件上其实很难有实现不了的事情，只有花多长时间才能实现的问题，所以只要能分析的出ROI建议无需过多讨论，只管做就是了

#产品挑战赛#Day1

起初完全不懂技术的产品本人（其实现在也没懂多少），自认为跟研发合作的过程中还是很少被忽悠的，积攒的几点经验如下：

• 需求阐述：产品一般是早于研发接触到需求的，对于需求的背景、价值、用户群体和使用场景等在需求分析阶段也都能获知。那么跟研发沟通需求的前提，我认为是要把这些点讲清楚，首先让研发知道为什么而做、再讲做成什么样；
• 方案输出：产品可以不用知道研发的表结构要如何设计、但最好知道多个系统之间如何交互更合理。这一点在输出方案的阶段，是产品需要关注的一个问题。基于业务流程、梳理清晰合理的多系统交互流程，可以帮助研发进行框架的设计，并且让研发觉得你是懂架构的！!
• 需求实现：产品不用干预研发如何写代码，但要能双向顺畅交流。基础的开发术语、在日常工作过程中，可以有意识的多积累，下一次就不用再纠结程序员小哥到底在说啥了；甚至下次碰到萌新程序员，还能基于过往经验给点实现建议。

以上，多沟通、多学习、多积累，让研发觉得做你的需求体验感很好，就自然不会忽悠你啦~毕竟，大多数人还是真诚待人的~

理论上没有技术上实现不了的需求，这些都是技术大大说的，只是成本和周期的问题。这也是为什么有需求的地方技术进步都是最快的。

所以，回到问题本身，给你3个建议：

1、需求评审核心不是评审方案，主要是讲价值，顺便告诉一下研发该怎么实现，主次要清楚。越大的公司越是共用资源的公司越是这样。

2、如果第一个点都讲清楚了，还存在做不了，那就细细的问清楚，只要能掰扯清楚，你也可以如实向需求方反馈，一定是转述，目的是通过合理的方式找到更懂的人来看看 （当然如果有竞品更好）

3、产品技术实现的方案可以去搜搜，现在已经成熟了，能找到很多例子

4、建议自己还是去简单了解一下技术实现一个需求的基本框架，还有一些常用的术语，目前学习成本很低

#产品经理挑战赛# day3

不懂技术的产品是如何与研发沟通需求才不被忽悠的？

关键词拆解：不懂技术  沟通  被忽悠

1、不懂技术怎么办？

• 主动去学习，不需要学的很深，能理解WBS下就可以
• 举栗子：例如你要做一个微信的聊天功能，那么需要一个通讯录列表、历史沟通列表、沟通对话框（发送信息）、人员信息等等，这样拆解下来就有了页面，那么你可以结合你之前团队开发列表的时间？提交需要的时间？详情需要时间进行大概估算

2、如何沟通？

• 沟通是门学问，可以多看点书或者得到上可以进行学习（没打广告哈）
• 与研发人员搞好关系（请喝个下午茶，吃个饭，聊一些共同话题，比较直接又不想太花钱就是看他们是否打游戏陪打）
• 善用技巧，不要总是说我认为、我以为（我认为这个开发很简单，被打死），多用你认为，你觉得（你觉得这个功能会有什么难点？你认为这个有没有新的方案）

3、被忽悠？

• 当你学会如何沟通，那么你就不会被忽悠了。
• 即使会你可以借力找项目经理或熟悉的开发人员评估一下，做一下对比，这样你就知道大概的开发时间及难点在哪里了。

#产品经理挑战赛# day4

先说我的观点：一定是没有实现不了的需求，但前提是成本足够。

我之前看了一个文章说产品的诞生不是产品一个人的事，而是销售、运营、技术等大家一起来完成的。我觉得说的很对，什么点奶茶啊，讨好啊这一套我觉得当下是有用的长久来看并没有改变你是「孤胆英雄」的现状。

我的做法：强调价值和roi，大家的对价值的认同只要一致，那么很多事情就迎刃而解了。我也会去学习一些基本的技术知识，但是那我不是我的主要工作内容，因为在技术框架下设计出来的产品，真的不好用。

如果公司充斥着这种不行，不可能的声音，先找上级说明下吧，无法解决还是看钱说话吧因为这种无意义的内耗真的很累。

#产品经理挑战赛#day7

问题：不懂技术的产品是如何与研发沟通需求才不被忽悠的？

答：很难。

就算是懂技术的产品有时候也会被研发忽悠，更别说你确实一点技术都不懂，那么你别忽悠的概率很高，且不被忽悠的概率很小。

想要不被忽悠，有两个办法。

1、和研发搞好关系，从情感上减少被忽悠的概率。

2、打铁还需自身硬，提需求前简单的了解需求是否能够实现，以及实现难度如何。

搞好关系确实是很重要的事情，我感觉大多数产品和研发的关系不好。但我和研发的关系确实是不错....所以基本上他们都没咋忽悠我，哪怕是不想做，只要给我说了原因，我也会考虑是否延期或用其他方式验证后再做。

第二个就是需要自己百度，自己Google，简单的了解一些技术基础就行。。。。记住所谓的技术基础不是让你直接看java的基础，而是实现的基础。 

如果你跑去看java或js 的基础，等你从holleword看起，看完整本书后，你可能还是懂不起....

#产品经理挑战赛# day2

不懂技术？这个问题对于大部分的产品来说都算是个问题。前阵子，有人说产品只要会说就行了；有的人说产品应该是技术大佬，能产品的业务逻辑和算法都熟悉透彻；又有人说懂一点即可。对于说产品经理是否懂技术？会不会被研发忽悠的问题，我认为大可不必考虑这么多。

首先，产品小白，不懂技术在和研发沟通交流的时候，你面对的一般也不是领导层面的技术人员，基本不存在忽悠不忽悠的问题（对于跨行业转产品的同学来说，你真的一点技术都不懂，那么至少要知道一些基本的术语，交流起来也方便。）

其次，当一个产品成长到初级-中级时，多少对于技术框架、算法和逻辑能说出来个一二三，如果这时候你只会设计、沟通、做PPT，那么我想你需要反思自己能力或环境是否正确了。（不需要会但一定要懂）

最后，产品总监/高级产品经理（这个我不知道......）。但是，我认为这个位置的领导层应该不考虑被忽悠的问题吧。

个人观点，仅此！

其实不懂技术问题也可以很很好的跟研发进行沟通，就针对你这个问题而言

1、跟研发同步该需求的重要性，说明谁在关注这指标，该指标的用途是啥，如果没有该指标会有什么影响，做这件事件的ROI是多少

2、让研发提供数据分析功能的难点在哪？是相关数据没埋点？还是数据量太大处理不过来？我相信只要这两个不是问题的话，解析统计数据是很快的。产品可先了解整个数据流程再去跟研发讨论

3、是否有其他方案可以先看数据，比如让BI公司先T+1天提供离线数据，而非研发的实时数据。

4、如果最终还是无法推动，尽早反馈给上层，找老板推进。

首先，我觉得产品不应该考虑怎么不被研发忽悠，这个是公司内部管理的事。

但也是有方法能了解一些技术原理，加强与技术的沟通：

• 多问：碰到日常技术反馈争议，多询问原因，多了解技术无法实现的背后原因，同时技术方案（或叫概设）评审会时，多了解技术实现背后原理；在实战中增加了解
• 自学：可以简单学学语言，增加点了解

产品与技术的良好协作是顺利推进工作的必要环境，建议多改善与同事的关系。如果多次尝试无效，可以找他领导介入。