对产品经理而言，为什么要求懂技术？

                                                PM的工作是建立在团队信任的基础上的。建立信任是一个不断累积的过程，PM每做一次正确的决策可能才可以+1分的信任，但如果出现一个很低级的错误，可能直接就-10分了。

好久没有写产品相关的话题了，今天说一个老生常谈的问题：产品经理需要懂技术吗？「知乎」上这个问题有高达 9,236 个关注者，1,067,445 次的浏览。
为什么这个问题那么受关注？
因为这确实是一个 PM （非技术转型过来的）成长过程中会遇到的困惑。当我设计了一个功能，但由于忽略了很低级的技术原因被打回，这种挫败感就算是时隔多年之后回想起来都让人很不舒服。
更糟的是这个事情危害不单单是情绪上的，它还会破坏 PM 在团队中的信任。PM 的工作是建立在团队信任的基础上的。建立信任是一个不断积累的过程，PM 每做一次正确的决策可能才可以 +1 分的信任，但如果出现一个很低级的错误，可能直接就 -10 分了。
所以，产品经理真的需要懂一些技术。成为一个懂技术的产品经理，我们最少需要解决三个问题：
[ol]

产品经理要懂的技术是什么？

对于技术需要懂到什么程度？

如何提高产品经理的技术能力？
[/ol]
1、PM要懂的是用程序解决问题的思考方式
首先，PM 懂技术不是说从发现需求到设计解决方案的过程中一个人包圆了，而是 PM 需要了解程序解决问题的思考方式，这样可以帮助 PM 更好的和工程师沟通，也帮助 PM 更好的找到解决问题的切入点。
程序解决问题的思考方式通俗可以理解为：流程的分层思考，最少需要考虑：数据、服务端、接口、前端 这四个环节。

例如之前网上有个最不靠谱的产品需求：根据手机壳的颜色自动匹配手机主题壁纸（一开始我以为只是段子，后来发现锤子手机居然实现了）
如果分层来看简单的可以这么分。

那么如果我们真的需要设计「根据手机壳的颜色自动匹配手机主题壁纸」至少需要解决几个问题：

如何采集用户更换手机壳这个行为，以及手机壳的主题？

手机壳的主题按什么形式传递给服务端，照片？还是定义主题的 Tag ？

服务端得到手机壳的数据后和现有数据库的壁纸怎么匹配？

得到匹配的壁纸之后通过什么方式展示给用户，自动替换（有么有权限）？提醒用户（什么时机）？

这样分解下来，这个需求至少在实现阶段也并不是那么的不靠谱。
注：之前没想到锤子实现这个功能，我设想的是「淘宝」可以根据用户购买手机壳的数据来解决手机壳获取的问题，其他步骤相对比较常规。
2、了解技术是一个无止境的过程
该懂多少技术？答案显然是越多越好。如果一个 PM 有着技术专家一样的水平，完全就和流氓会武术是一个 level 。但这个事情的难度也是显而易见的，很少的人才能达到这个状态。
所以在这我想说，应该做的是抛弃「0-1」的思维方式，懂技术这件事情上，并不是只有「完全不懂技术」和「技术专家」两个选项。
在「完全不懂技术」到「技术专家」之间有着很宽阔的区域。在此之间任何位置对产品经理的工作都有帮助，稍微进步一些帮助就更多一些。
3、有两种办法锻炼技术思维
第一 在和工程师的沟通中学习
很多 PM 想必都有这样的经历：带着一个需求跑去问工程师能不能实现，然后被告知无法实现。
这其实就是一个锻炼技术思维的大好机会，如果在这个时候直接回头了，那就白白浪费了一个好机会。其实我们大可以根据上面的四环节，展开来和工程师沟通下是哪些具体问题解决不了。对于实现不了这个事情，是因为现有技术方案的限制，还是说超过了技术本身的能力极限。
像这样随着工作的时间越长，PM 也就越了解自己负责产品相关的技术思维。
第二 动手写点小程序
自己动手写点程序也是一种很好的锻炼技术思维的方法。其实写简单程序并没有太难，不需要买很多大部头书啃完才动手。只需要在网上找几篇简单的教程看看，然后直接定一个程序需要解决的目标直接上手就好了。
大概也这就几个简单的步骤：
[ol]

完成开发环境的配置；

了解最基本的语法，变量，if判断和循环的使用；

完成第一个程序：Hello world!

尝试完成一个小项目：例如抓取百度阅读的电子书内容。
[/ol]
如果不知道学习什么语言，我比较推荐 Python ，Python 语法相对简单，第三方库的使用也更方便，比较容易上手。