产品经理对于技术实现层面的考虑有哪些？需要如何考虑呢？

其实技术同样是团队成员，整个团队的目标和氛围与产品经理的主动营造很有关系。

1、目标。

要让团队成员和技术知晓一些重点功能背后的价值和目的。这才能让整个团队清楚重要性。团队成员每个人都可以对产品提建议，有的时候产品人员需要拿出各种方法来说服成员，包括使用客观的调查数据等；

重要功能轻易不能妥协。

2、梳理业务逻辑

技术在实现上本身就是一个逻辑活。

有的时候产品经理与技术沟通过程当中，很多就是因为逻辑的偏差导致需求无法实现。将自己的业务逻辑梳理给到技术很重要。

3、表示难度太大，搞不定？

原因1：技术不懂且是个不主动的人（态度问题）。——产品人员去谷歌、技术社区、找技术的领导一起讨论等，帮他一起找技术方案的资料。

原因2：技术方案可实现但难度大。——假若这个功能真的极其重要，一起讨论解决方案。短时间内有没有低成本的变通的方案；难度大的技术方案局限在什么地方；实现技术方案需要耗费多少时间成本和其他成本。

最后说一点，有时候花费大量精力做出来的功能也许真的与你之前的想象完全不同，所以在没有真正的定论之前，最好用最小成本先上去妥协版的，甚至是个demo，先测试。有数据都好说话。

从本质上来说，没有实现不了的需求，只是实现的代价有多大，价值高不高，打开需求的姿势对不对

这个问题要从几个方面看：

1. 从产品本身来看需要你确定这个需求的价值，可以从KANO模型，ROI投资回报率上来对需求重要性排序，优先做有价值的东西，时间来不来的及

2. 确定了价值，下面就是需求实现的问题，一般来说需求是有多种实现方式的。不仅仅是技术上的，还有其他表现形式上的。打个比方，用户说要可乐，基本的需求是因为渴了，而你如果提供矿泉水其实一样能解决问题，这个需要你从本质上理解用户需求；技术上，实现一个功能，可能写一个工厂方法就可以简化很多事情，而开发也可以己脑洞大开过度设计（这种对于入门没多久又有理想的程序员是比较常见的）。这个在提需求的时候，你提给开发的需求更应该说用户story，而不是描述解决方案：规定好他应该怎么做。同时尽量找开发领导提前沟通需求，这样有可能他会给你一种更加好的实现方案

3. 最后就是努力充实自己，面向对象的编程思维可以多了解了解。产品经理的UML工具其实就是面向对象的思考方式，你可以不用管这个方法具体是通过写了多少行代码实现的，只需要想通中间的逻辑是怎样的即可，这样又可以反过来促进你了解：你的设计中有没有遗漏什么，下一版功能可以往哪拓展；从整体逻辑的复杂性推算功能的实现时间，对整体开发时间的估算越来越有把握，避免被开发忽悠

在这个问题上，我是这么认为的。产品经理做事情肯定需要结合公司的资源，技术也是公司重要资源的一部分。如果公司最顶尖的技术都无法实现，说明此项功能不适合该公司实现。 
如果该功能是核心功能，那么只能招人来实现，如果不行只能说公司在这个问题上对产品规划过于冒进。 
如果不是，可以先以能实现的缺陷方式先实现，后期向研发反应，由专人研究弥补缺陷。

产品经理要帮助技术梳理清楚业务逻辑，要尽可能让你总结出得业务逻辑接近业务本质。

其实很多时候，技术实现困难或者成本高，是对业务理解有偏差所致。

其次，产品经理在构思产品逻辑和功能形态的时候，应该在一定程度上（特别是特定时间范围内）考虑避开技术瓶。或者技术评审后提出技术困难，可以考虑调整产品方案，以达到尽快上线推进业务的目的。

此外，如果技术团队能力薄弱（主要是小公司，或者技术投入小的情况）产品经理在了解到技术症结之后，可以去外界寻找一下解决方案（找人、找资料等等），给技术人员一些启发和思路。

对于技术无法实现的这个问题，我想说其实是正常现象，别人能做不代表你的团队就可以做到。当然，你得了解这一点，所以你需要对技术有一定程度的认知。而项目在确定的时候就应该把其中的一些技术难点列出来探讨可实现性，如果团队当前不具备实现的能力而进行了这个项目开发，最终项目失败的责任就是产品经理的。不要推卸给技术人员。