人人都是产品经理2.0——7
第七章 执行：立项组队与研发生产
7.1 从想清楚到做出来
本章的开始，先说说产品项目执行前最后的验证——评审立项。以为必须找到一群人完成执行，接着会聊聊组队的话题，最后再讲讲执行过程中有哪些注意事项，以确保通过合理、准确的研发生产把产品做出来。
7.1.1 源性炎症与NPS
确保有的放矢，不要努力做错误的事，这是产品立项前要做出的最重要的判断。因为，；立项就意味着研发资源的正式投入。在这个节点的验证，叫原型验证。之前的验证，主要目的是验证用户需求抓的准不准，而本次验证则是考察用户是否认可解决方案。
有的公司把这个环节叫作POC，产品概念测试。在这一环节，需要用尽量低的成本，作出某种形式的产品原型或DEMO，来让用户试用。
NPS指的是净推荐值，是一种计量用户将会向其他人推荐某产品可能性指数，作为一种流行的用户忠诚度分析指标，他专注于用户口碑，在产品早期验证用户价值时，尤为重要。
净推荐值的计算公式：
NPS=（推荐者数-批评者数）/样本总数*100%
确定净推荐值时，可以直截了当地问用户一个问题：“您是否愿意将某某产品推荐给您的朋友或者同事？”然后让用户根据愿意推荐的程度，在0到10分之间打分，最后根据打分情况把用户分为推荐者、被动者和批评者。
然后，在根据推荐者和批评者的人数来计算NPS的数值。
NPS的得分值在50%以上就已经比较理想，如果达到70%-80%，这说明产品拥有一批忠实粉丝。而实际情况是，很多产品的NPS值远远低于50%，甚至是负数。如果你的产品还没有测试过NPS，那么赶紧测试一下吧，这个测试永远都不晚。如果分数太低，建议马上推广甚至生产停下来，回过头来好好想想产品定位。产品上市后，NPS也应该定期测试，以指导后续策略。
对于验证用户是否认可解决方案这件事，没经验的产品经理可能会去问用户：这个产品做出来你会不会用，会不会买？这个时候，用户通常会给出毫无意义的敷衍回答：我可能会用会买，所以一定要用净推荐值这种方式来问，这一步骤是产品生产生命周期早期的一个关键特点。
7.1.2 产品***会关键节点
从想清楚到做出来，再到推出去，每逢关键节点，都需要判断接下来对此产品是应该加大投入。那么由谁来判断？答案就是“产品***会”
一个团队里，总会有某种形式的“产品***会”存在，他们通常是由各个相关团队的Leader组成，或者说得更直白一点，由手里握有资源的人组成。因为资源投入方向要阶段性地作出判断，所以产品***会在每个关键节点召开产品会议。经过筛选，以下四个关键节点是必不可少的。
>>概念筛选
根据各种背景信息，判断要不要对某个产品概念进行细化、展开。如果认为可行，就要启动全方位的需求采集工作。
>>立项组队
对产品进行原型验证，判断需要投入多少研发生产资源，有多少风险及如何应对等，如果立项获批，就要启动项目、组队开干。
>>上线发布
产品完成开发后，千万不要因为怕浪费而仓促上线。这是还是要先用真实产品找种子用户验证，如果没有通过验证，就不要上线，以免浪费更多的客服、销售、运营维护资源。
>>营销推广
为提升用户量，上线之后马上就开始推广，也是常见的错误。应该先花一段时间考察用户是否活跃，是否会再次使用产品。当这些指标达到预期后，才可以大力推广，否则就是浪费资源。
在大公司，这四个节点是申请资源的关键节点：在创业公司，这四个节点是引入外部投资、关键岗位人才的重要节点。产品经理们只有把自己的视野拓宽一下，站在老板或投资人的立场去想想他们到底想要什么，才不容易理解获取资源更有效的途径。接下来讲立项时具体需要搞定哪些资源。
7.2 立项:搞定各种资源
对于初级产品经理来说，这些事往往不用自己搞定，但是随着能力的提升，这也成为了份内的事。
7.2.1 关于人：团队、组织
一群人到底为什么要聚在一起做一件事情？只有想清楚了这个问题，才能真正搭建一支有战斗力的团队。我们从组织形成的三种原始动力说起。
>>权利：强力组织，比如国家***，用“枪杆子”保证“绳之以法”。
>>利益：商业组织，比如公司企业，用“钱袋子”支撑“诱之以利”。
>>共识：松散组织，比如公益社团，用“笔杆子”达成“晓之以理、动之以情”。
这三种原动力，在人类发展的不同阶段，所起到的作用各有不同。资源匮乏时容易形成暴力组织，随着资源越来越丰富，组织越来越倾向于用利益和共识这些力量来维系。
7.2.2 关于物：政策、资金
“物”的范畴，包括公司内外各种政策、流程、资金等的支持。举个例子，在大公司，需要其他部门配合时，有没有大老板的一句话，就可能产生巨大差别；做创新业务时，能否不走集团统一的决策流程，也许是一个关键要素；作为创业公司，这一次可以融资多少钱，恐怕能决定生死。
Why为什么要做这个产品
我们有很多"动之以情"的素材、比如可以把需求采集环节的用户故事包装一下，放在MRD文档的开头，让受众一开始就感受到需求之强烈，问题之严重.但更重要X放在\LRD文档的开头、、'，但更重要的是"晓之以理"——在产品概念筛选阶段做的内部能力、意愿的分析，以及外部价值
成本的判断，就可以用上了，最后还可以"诱之以利，做一个R0I(Return On Investme，投资回报率)的预估，当然、这里的RoI是广义的、回报不一定是金钱.还可能会用户数、市场占有率等其他指标。
What：产品MVP包含哪些功能及要做什么
我们通常会筛选出功能列表中第一版产品要做的哪些功能、将其到在MRD里，但老板们更喜欢看图，所以，把这些功能用产品架构图的方式表述出来、更加重要，如果可以在现场演示某种形式的DEMO，那绝对不要错过这个加分的机会，这里也可以考虑下产品的用户角色、重要的产品原则，方便老板们进一步理解我们要做到事情。
How：项目计划及风险对策等
这一部分，要说清楚项目计划、需要多少资源做保障，让老板们知道要花多少时1司、多少资金，以及要用多少各种岗位的人。如果你做过竞品分析，可以把可能碰到的风险及其对策等也放在这里。还可以针对具体业务，说说打算如何获取用户、上线后怎么运营、做什么市场动作、如何评估这些动作的效果等。
如果是创业公司融资，在这部分还可以加上核心团队的背景介绍、当前股权结构和融资预期等信息。
MRD写得好，意味着各种准备工作做得到位，最终能获得各种支持就是自然而然的事。本节的最后，再分享一些创业公司融资的注意点。
首先，有些情况下的钱不能拿一是只出钱却想控股的、会使得团队陷入打工心态二是不懂行的暴发户，没法提供资源支持，还喜欢指手画脚三是给了钱却附加各种条件的(相信我，你肯定玩不过投资人)，建议有融资计划前、尽量多和有过融资经历的创业者交流，
其次，投资人给钱时，不同轮次的关注点不同，基本上、种子轮只看团队、只要团队靠谱，就算还没确定方向。拿个几十万到一两百万人民币是没问题的天使轮、就要看产品了，产品做出来且通过了早期的用户验证，就能拿到大几百万到一两千万人民币，可以用于继续发展，投资业内有个说法、大公司里出来的、或者已经有过翥谱创业经历的明星创业者，刷脸就能拿两轮、说的就是种子轮和天使轮再往后、产品进入市场运营、销售及品牌积累阶段，就要看数据增长、能否找到商业模式、收入、盈利、市场份额等这些指标和因素，这时候再拿钱就是ABC轮。所以，作为一个创业者，在早期最需要关注的是团队和产品。
7.3 组队：聊聊初创团队
7.3.1 如何快速知己知彼
以下故事、皆为亲历，如有雷同，真是巧合。
不管怎样，事情只要已经开始，就说明已经凑齐了一支看起来可以开干的团队。大家并不是很熟的时候，做起事来总会一团和气，但过一段时间，每个人都会发现，过程、结果并没有想象得那么美好。于是，团队进入频繁吵架的阶段，大家都在找台适的当口发泄自己的失望和不满。吵架的原因，往往是一些底层的东西并没有达成一致，导致观念冲突，团队成员之间不信任、不理解、没有默契。当出现这种情况时、就说明有些统一思想的事情漏做了。我们要花最少的时间，让大家感觉到彼此已经熟识多年，互相很清楚对方想要什么。
大公司里的专业HR可能会更早意识到这一点，然后提醒业务人员。但对于创业团队、只能靠老大自己发现，然后决定团队成员是不是需要聊聊，以及在什么场合下聊场合很关键，找到一个大家都很想聊聊的场合，是达成默契的第一步，所以，在团队里比较和谐的场景是，某天下午大家又因为一个具体的业务问题、从讨论逐步发展到争吵，继而开始对彼此的思维模式、做事套路不认同。。。。正当大家精疲力竭的时候，老大问了一句。晚上都没事吧了一起去吃饭、我请客——这就是一个良好的开端。
7.3.2 小团队的沟通协作
本着“工欲善其事必先利其器”的概念，团队组建前就研究过很多协作工具。但并没有一个工具被坚持采用下来，因为随着一个个队友的加入，前一个工具总是很快被与团队规模更加匹配的新工具所取代。
7.3.3 小团队与大公司的区别
对于初创公司，组织架构应该以目标为核心，按需设置部门，而不是像大公司一样以流程为中心。而组建公司之前，应该以机会为中心。
7.3.4 借助第三方力量做产品
因为绝大多数初创团队都很弱小，如果任何事都要自己搞，那前进的速度肯定会慢下来，所以必须要学会借助外力。初创团队、产品遇到的所有问题，最终都可以归纳为：找钱、找人。
7.4 研发生产时，我们做什么
简单的讲，原型验证完成、产品***会评审通过以后，然后要立项、需求、开发、测试、发布几大环节，然后再拿着做出来的产品找用户验证，最后做项目总结。
7.4.1 产品经理要不要懂技术
产品经理到底要不要懂技术?这是一个经久不衰的问题，因为在研发生产过程中，产品经理要经常和技术人员讨论细节，如果完全不懂技术，似乎很难沟通。所以，这本质上是一个沟通的问题，标题中的"技术"换成"设计、运营、市场"等也是适用的。下面，说一下我的理解。
第一，底线是可以和技术人员无障碍沟通，并不要求你会写代码。具体点说，技术人员可以直接用平时和同伴说话的方式与你交流，而不用刻意翻译。如果对话过程中经常出现听不懂&至解释了还是不明白这类情况，很容易让彼此间失去信任，直至没法沟通。当然，和高水准的技术人员配合，会轻松很多，他们更会换位思考，尽量用通俗一点的语言进行沟通。此外，良好的沟通能力和理解能力，也可以弥补专业知识的不足。
第二，多向技术伙伴请教，自学一些技术知识。如果你懂一些术语或者会说一些。黑话。，让技术人员觉得。你即使不会写代码，但也是懂的。，会拉近彼此的距离，建立一种自己人的信赖感，这在沟通、协作过程中会有很大的帮助、，所以，对于技术出身的产品经理，这点确实是天生的优势，但他们要注意的是不要滥用技术，越俎代庖。一方面自身应该把更多的时间精力用在思考产品层面的事情；另一方面也不应挫伤技术人员对产品的"责任感与参与感。
第三根据所负责的产品，决定要懂哪些技术，懂到什么程度。做技术驱动型的产品，比如Baidu搜索，那必须是特定方向的技术出身，否则很难胜任，而如果你要做一个导购类的App，就相对容易一些。所以，要补哪方面的技术常识,最好能先明确将来你要做什么产品，可能碰到哪些技术。
7.4.2 如何做一个让Ta们讨厌的人
本章的最后，继续聊聊在研发生产过程中与他人沟通和配合时的注意事项、下面以与技术人员沟通为例，分享一些简单易学、通俗易懂，能让产品经理在各种配合方眼中迅速变得很讨厌的做法。
开始实施之前
>>不说清需求价值。技术问，为什么要做时支支吾吾，或者说这是老板(运营)要的，假装自己是个传话筒，或者说，我接的是二手需求，什么都不知道。而不是去追溯这个需求的初衷。相反，面对老板时，则一定不要有理有据地顶撞，那会让大家喜欢上你。
>>不去想功能细节。技术问细节(当然，是涉及业务的细节，不是技术实现细节)时，装作自己之前完全没想过，需要现想：那就这样做，可能那样做也可以，要不你来定吧。······这时你能看到的是技术同学的白眼，听不到的是他们心里的三字经。
>>帮技术评估工作量。特别是技术出身的产品经理，最容易这么干、他们的潜台词就是"希望加活.我评估过了，这些都能做掉的，不要偷懒、不要忽悠我，我都懂。
>>逼着技术团队承诺。任何时候只知道公事公办，技术承诺了却做不到、自己就没责任丁，很多事情不像接力跑的交棒，更像踢足球的传球，一开始没人知道下一步法干什么，如果对方基于此对你说。大家在一条船上。直渡同舟共济时你只要回：我不管，我不管，就好了。
实施过程之中
>>做了一半改需求。经常在某个迭代周期内做非受迫的需求变更，这招太狠了，技术同学肯定很难忍受，俗话说，没有变更就没有伤害。如果是因为产品经理没想清楚而导致无谓劳动，碰到性子烈的技术就要直接干架了，这时候要注意保证自己的人身安全。
>>开发过程中消失。你可以多安排点出差、多开开会，注意手机尽量关机、开要响应技术的问题，要不然，责任就回来了。让技术同学为了赶进度，按厞他f门自己的想法做下去，关键是要在验收的时候跳出来说"这不是我要的，再次提醒注意人身安全。
>>过度关注实现细节。帮技术决定技术方案，技术出身的产品经理最爱干的事儿就是变着法儿地越俎代庖。一定要把技术从积极主动的小伙子，打击成个个纯打工心态的“资源”(这个词听起来就有杀伤力)。
#产品#
7.1 从想清楚到做出来
本章的开始，先说说产品项目执行前最后的验证——评审立项。以为必须找到一群人完成执行，接着会聊聊组队的话题，最后再讲讲执行过程中有哪些注意事项，以确保通过合理、准确的研发生产把产品做出来。
7.1.1 源性炎症与NPS
确保有的放矢，不要努力做错误的事，这是产品立项前要做出的最重要的判断。因为，；立项就意味着研发资源的正式投入。在这个节点的验证，叫原型验证。之前的验证，主要目的是验证用户需求抓的准不准，而本次验证则是考察用户是否认可解决方案。
有的公司把这个环节叫作POC，产品概念测试。在这一环节，需要用尽量低的成本，作出某种形式的产品原型或DEMO，来让用户试用。
NPS指的是净推荐值，是一种计量用户将会向其他人推荐某产品可能性指数，作为一种流行的用户忠诚度分析指标，他专注于用户口碑，在产品早期验证用户价值时，尤为重要。
净推荐值的计算公式：
NPS=（推荐者数-批评者数）/样本总数*100%
确定净推荐值时，可以直截了当地问用户一个问题：“您是否愿意将某某产品推荐给您的朋友或者同事？”然后让用户根据愿意推荐的程度，在0到10分之间打分，最后根据打分情况把用户分为推荐者、被动者和批评者。
然后，在根据推荐者和批评者的人数来计算NPS的数值。
NPS的得分值在50%以上就已经比较理想，如果达到70%-80%，这说明产品拥有一批忠实粉丝。而实际情况是，很多产品的NPS值远远低于50%，甚至是负数。如果你的产品还没有测试过NPS，那么赶紧测试一下吧，这个测试永远都不晚。如果分数太低，建议马上推广甚至生产停下来，回过头来好好想想产品定位。产品上市后，NPS也应该定期测试，以指导后续策略。
对于验证用户是否认可解决方案这件事，没经验的产品经理可能会去问用户：这个产品做出来你会不会用，会不会买？这个时候，用户通常会给出毫无意义的敷衍回答：我可能会用会买，所以一定要用净推荐值这种方式来问，这一步骤是产品生产生命周期早期的一个关键特点。
7.1.2 产品***会关键节点
从想清楚到做出来，再到推出去，每逢关键节点，都需要判断接下来对此产品是应该加大投入。那么由谁来判断？答案就是“产品***会”
一个团队里，总会有某种形式的“产品***会”存在，他们通常是由各个相关团队的Leader组成，或者说得更直白一点，由手里握有资源的人组成。因为资源投入方向要阶段性地作出判断，所以产品***会在每个关键节点召开产品会议。经过筛选，以下四个关键节点是必不可少的。
>>概念筛选
根据各种背景信息，判断要不要对某个产品概念进行细化、展开。如果认为可行，就要启动全方位的需求采集工作。
>>立项组队
对产品进行原型验证，判断需要投入多少研发生产资源，有多少风险及如何应对等，如果立项获批，就要启动项目、组队开干。
>>上线发布
产品完成开发后，千万不要因为怕浪费而仓促上线。这是还是要先用真实产品找种子用户验证，如果没有通过验证，就不要上线，以免浪费更多的客服、销售、运营维护资源。
>>营销推广
为提升用户量，上线之后马上就开始推广，也是常见的错误。应该先花一段时间考察用户是否活跃，是否会再次使用产品。当这些指标达到预期后，才可以大力推广，否则就是浪费资源。
在大公司，这四个节点是申请资源的关键节点：在创业公司，这四个节点是引入外部投资、关键岗位人才的重要节点。产品经理们只有把自己的视野拓宽一下，站在老板或投资人的立场去想想他们到底想要什么，才不容易理解获取资源更有效的途径。接下来讲立项时具体需要搞定哪些资源。
7.2 立项:搞定各种资源
对于初级产品经理来说，这些事往往不用自己搞定，但是随着能力的提升，这也成为了份内的事。
7.2.1 关于人：团队、组织
一群人到底为什么要聚在一起做一件事情？只有想清楚了这个问题，才能真正搭建一支有战斗力的团队。我们从组织形成的三种原始动力说起。
>>权利：强力组织，比如国家***，用“枪杆子”保证“绳之以法”。
>>利益：商业组织，比如公司企业，用“钱袋子”支撑“诱之以利”。
>>共识：松散组织，比如公益社团，用“笔杆子”达成“晓之以理、动之以情”。
这三种原动力，在人类发展的不同阶段，所起到的作用各有不同。资源匮乏时容易形成暴力组织，随着资源越来越丰富，组织越来越倾向于用利益和共识这些力量来维系。
7.2.2 关于物：政策、资金
“物”的范畴，包括公司内外各种政策、流程、资金等的支持。举个例子，在大公司，需要其他部门配合时，有没有大老板的一句话，就可能产生巨大差别；做创新业务时，能否不走集团统一的决策流程，也许是一个关键要素；作为创业公司，这一次可以融资多少钱，恐怕能决定生死。
Why为什么要做这个产品
我们有很多"动之以情"的素材、比如可以把需求采集环节的用户故事包装一下，放在MRD文档的开头，让受众一开始就感受到需求之强烈，问题之严重.但更重要X放在\LRD文档的开头、、'，但更重要的是"晓之以理"——在产品概念筛选阶段做的内部能力、意愿的分析，以及外部价值
成本的判断，就可以用上了，最后还可以"诱之以利，做一个R0I(Return On Investme，投资回报率)的预估，当然、这里的RoI是广义的、回报不一定是金钱.还可能会用户数、市场占有率等其他指标。
What：产品MVP包含哪些功能及要做什么
我们通常会筛选出功能列表中第一版产品要做的哪些功能、将其到在MRD里，但老板们更喜欢看图，所以，把这些功能用产品架构图的方式表述出来、更加重要，如果可以在现场演示某种形式的DEMO，那绝对不要错过这个加分的机会，这里也可以考虑下产品的用户角色、重要的产品原则，方便老板们进一步理解我们要做到事情。
How：项目计划及风险对策等
这一部分，要说清楚项目计划、需要多少资源做保障，让老板们知道要花多少时1司、多少资金，以及要用多少各种岗位的人。如果你做过竞品分析，可以把可能碰到的风险及其对策等也放在这里。还可以针对具体业务，说说打算如何获取用户、上线后怎么运营、做什么市场动作、如何评估这些动作的效果等。
如果是创业公司融资，在这部分还可以加上核心团队的背景介绍、当前股权结构和融资预期等信息。
MRD写得好，意味着各种准备工作做得到位，最终能获得各种支持就是自然而然的事。本节的最后，再分享一些创业公司融资的注意点。
首先，有些情况下的钱不能拿一是只出钱却想控股的、会使得团队陷入打工心态二是不懂行的暴发户，没法提供资源支持，还喜欢指手画脚三是给了钱却附加各种条件的(相信我，你肯定玩不过投资人)，建议有融资计划前、尽量多和有过融资经历的创业者交流，
其次，投资人给钱时，不同轮次的关注点不同，基本上、种子轮只看团队、只要团队靠谱，就算还没确定方向。拿个几十万到一两百万人民币是没问题的天使轮、就要看产品了，产品做出来且通过了早期的用户验证，就能拿到大几百万到一两千万人民币，可以用于继续发展，投资业内有个说法、大公司里出来的、或者已经有过翥谱创业经历的明星创业者，刷脸就能拿两轮、说的就是种子轮和天使轮再往后、产品进入市场运营、销售及品牌积累阶段，就要看数据增长、能否找到商业模式、收入、盈利、市场份额等这些指标和因素，这时候再拿钱就是ABC轮。所以，作为一个创业者，在早期最需要关注的是团队和产品。
7.3 组队：聊聊初创团队
7.3.1 如何快速知己知彼
以下故事、皆为亲历，如有雷同，真是巧合。
不管怎样，事情只要已经开始，就说明已经凑齐了一支看起来可以开干的团队。大家并不是很熟的时候，做起事来总会一团和气，但过一段时间，每个人都会发现，过程、结果并没有想象得那么美好。于是，团队进入频繁吵架的阶段，大家都在找台适的当口发泄自己的失望和不满。吵架的原因，往往是一些底层的东西并没有达成一致，导致观念冲突，团队成员之间不信任、不理解、没有默契。当出现这种情况时、就说明有些统一思想的事情漏做了。我们要花最少的时间，让大家感觉到彼此已经熟识多年，互相很清楚对方想要什么。
大公司里的专业HR可能会更早意识到这一点，然后提醒业务人员。但对于创业团队、只能靠老大自己发现，然后决定团队成员是不是需要聊聊，以及在什么场合下聊场合很关键，找到一个大家都很想聊聊的场合，是达成默契的第一步，所以，在团队里比较和谐的场景是，某天下午大家又因为一个具体的业务问题、从讨论逐步发展到争吵，继而开始对彼此的思维模式、做事套路不认同。。。。正当大家精疲力竭的时候，老大问了一句。晚上都没事吧了一起去吃饭、我请客——这就是一个良好的开端。
7.3.2 小团队的沟通协作
本着“工欲善其事必先利其器”的概念，团队组建前就研究过很多协作工具。但并没有一个工具被坚持采用下来，因为随着一个个队友的加入，前一个工具总是很快被与团队规模更加匹配的新工具所取代。
7.3.3 小团队与大公司的区别
对于初创公司，组织架构应该以目标为核心，按需设置部门，而不是像大公司一样以流程为中心。而组建公司之前，应该以机会为中心。
7.3.4 借助第三方力量做产品
因为绝大多数初创团队都很弱小，如果任何事都要自己搞，那前进的速度肯定会慢下来，所以必须要学会借助外力。初创团队、产品遇到的所有问题，最终都可以归纳为：找钱、找人。
7.4 研发生产时，我们做什么
简单的讲，原型验证完成、产品***会评审通过以后，然后要立项、需求、开发、测试、发布几大环节，然后再拿着做出来的产品找用户验证，最后做项目总结。
7.4.1 产品经理要不要懂技术
产品经理到底要不要懂技术?这是一个经久不衰的问题，因为在研发生产过程中，产品经理要经常和技术人员讨论细节，如果完全不懂技术，似乎很难沟通。所以，这本质上是一个沟通的问题，标题中的"技术"换成"设计、运营、市场"等也是适用的。下面，说一下我的理解。
第一，底线是可以和技术人员无障碍沟通，并不要求你会写代码。具体点说，技术人员可以直接用平时和同伴说话的方式与你交流，而不用刻意翻译。如果对话过程中经常出现听不懂&至解释了还是不明白这类情况，很容易让彼此间失去信任，直至没法沟通。当然，和高水准的技术人员配合，会轻松很多，他们更会换位思考，尽量用通俗一点的语言进行沟通。此外，良好的沟通能力和理解能力，也可以弥补专业知识的不足。
第二，多向技术伙伴请教，自学一些技术知识。如果你懂一些术语或者会说一些。黑话。，让技术人员觉得。你即使不会写代码，但也是懂的。，会拉近彼此的距离，建立一种自己人的信赖感，这在沟通、协作过程中会有很大的帮助、，所以，对于技术出身的产品经理，这点确实是天生的优势，但他们要注意的是不要滥用技术，越俎代庖。一方面自身应该把更多的时间精力用在思考产品层面的事情；另一方面也不应挫伤技术人员对产品的"责任感与参与感。
第三根据所负责的产品，决定要懂哪些技术，懂到什么程度。做技术驱动型的产品，比如Baidu搜索，那必须是特定方向的技术出身，否则很难胜任，而如果你要做一个导购类的App，就相对容易一些。所以，要补哪方面的技术常识,最好能先明确将来你要做什么产品，可能碰到哪些技术。
7.4.2 如何做一个让Ta们讨厌的人
本章的最后，继续聊聊在研发生产过程中与他人沟通和配合时的注意事项、下面以与技术人员沟通为例，分享一些简单易学、通俗易懂，能让产品经理在各种配合方眼中迅速变得很讨厌的做法。
开始实施之前
>>不说清需求价值。技术问，为什么要做时支支吾吾，或者说这是老板(运营)要的，假装自己是个传话筒，或者说，我接的是二手需求，什么都不知道。而不是去追溯这个需求的初衷。相反，面对老板时，则一定不要有理有据地顶撞，那会让大家喜欢上你。
>>不去想功能细节。技术问细节(当然，是涉及业务的细节，不是技术实现细节)时，装作自己之前完全没想过，需要现想：那就这样做，可能那样做也可以，要不你来定吧。······这时你能看到的是技术同学的白眼，听不到的是他们心里的三字经。
>>帮技术评估工作量。特别是技术出身的产品经理，最容易这么干、他们的潜台词就是"希望加活.我评估过了，这些都能做掉的，不要偷懒、不要忽悠我，我都懂。
>>逼着技术团队承诺。任何时候只知道公事公办，技术承诺了却做不到、自己就没责任丁，很多事情不像接力跑的交棒，更像踢足球的传球，一开始没人知道下一步法干什么，如果对方基于此对你说。大家在一条船上。直渡同舟共济时你只要回：我不管，我不管，就好了。
实施过程之中
>>做了一半改需求。经常在某个迭代周期内做非受迫的需求变更，这招太狠了，技术同学肯定很难忍受，俗话说，没有变更就没有伤害。如果是因为产品经理没想清楚而导致无谓劳动，碰到性子烈的技术就要直接干架了，这时候要注意保证自己的人身安全。
>>开发过程中消失。你可以多安排点出差、多开开会，注意手机尽量关机、开要响应技术的问题，要不然，责任就回来了。让技术同学为了赶进度，按厞他f门自己的想法做下去，关键是要在验收的时候跳出来说"这不是我要的，再次提醒注意人身安全。
>>过度关注实现细节。帮技术决定技术方案，技术出身的产品经理最爱干的事儿就是变着法儿地越俎代庖。一定要把技术从积极主动的小伙子，打击成个个纯打工心态的“资源”(这个词听起来就有杀伤力)。
#产品#
小鹏汽车AI面7人在聊