06 | 精益创业：产品经理不靠谱，你该怎么办？

Jan 7, 2019

06 | 精益创业：产品经理不靠谱，你该怎么办？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

06 | 精益创业：产品经理不靠谱，你该怎么办？

2019-01-07 郑晔来自北京

《10x程序员工作法》

课程介绍



讲述：郑晔

时长12:03大小11.04M



你好，我是郑晔。
前面谈到验收标准时，我们说的实际上是确定性需求，也就是说，我们已经知道了这个需求要怎么做，就差把它做出来了。而有时候，我们面对的需求却是不确定的，比如，产品经理有了一个新想法，那我们该如何应对呢？
今天，我们从 IT 行业一个极为经典的话题开始：程序员如何面对产品经理。我先给你讲一件发生在我身边的事。
有一次，我们一大群人在一个大会议室里做一个产品设计评审，来自产品团队和技术团队的很多人都参与到这个评审中。一个产品经理正对着自己的设计稿，给大家讲解一个新的产品特性。
这个公司准备将自己的服务变成了一个云服务，允许第三方厂商申请，这个产品经理给大家讲解的就是第三方厂商自行申报开通服务的流程。听完前面基本情况的介绍，我举手问了几个问题。
我：这个服务会有多少人用？
产品经理：这是给第三方厂商的人用的。
我：我问的是，这个服务会有多少人用。
产品经理：每个第三方厂商的申请人都会用。
我：好，那你有预期会有多少第三方厂商申请呢？
产品经理：呃，这个……我们没仔细想过。
我：那现在给第三方厂商开通服务的具体流程是什么。
产品经理：第三方厂商申请，然后，我们这边开通。
我：好，这个过程中，现在的难点在哪里？这个审批过程能让我们的工作简化下来吗？
产品经理：……
我：那我来告诉你，现在开通第三方厂商服务，最困难的部分是后续开通的部分，有需要配置服务信息的，有需要配置网络信息的。目前，这个部分还没有很好的自动化，前面审批的部分能够自动化，对整个环节优化的影响微乎其微。
我的问题问完了，开发团队的人似乎明白了什么，纷纷表示赞同我的观点。这个审批流程本身的产品设计并不是问题，但我们的时间和资源是有限的，关键在于，要不要在这个时间节点做这个事。准确地说，这是优先级的问题。
此刻，作为开发团队一员的你，或许会有种快感，把产品经理怼回去，简直大快人心。好吧，作为一个正经的专栏，我们并不打算激化产品经理和开发团队的矛盾，而是要探讨如何做事情才是合理的。
之所以我们能很好地回绝了产品经理不恰当的需求，是因为我们问了一些好问题，但更重要的是，我们为什么能问出这些问题。
产品经理是个新职业在做进一步讨论之前，我们必须认清一个可悲的现状，IT 行业中大多数人的专业程度是不够的。
IT 行业是一个快速发展的行业，这个行业里有无数的机会，相对于其它行业来说，薪资水平也要高一些，这就驱使大量的人涌入到这个行业。
也因为这是一个快速发展的行业，很多职位都是新近才涌现出来的，比如，在 2010 年之前很少有专职的前端工程师，之前的工程师往往要前后端通吃。
产品经理便是随着创业浪潮才风起云涌的职位。既然这是个“新”职位，往往是没有什么行业标准可言的。所以，你会看到很多行业乱象：很多人想进入 IT 行业，一看程序员需要会写代码，觉得门槛高，那就从产品经理开始吧！这些人对产品经理岗位职责的理解是，告诉程序员做什么。
这和郭德纲口中外行人“如何认识相声”是一个道理，以为会说话就能说相声，殊不知，这是个门槛极高的行业。产品经理也一样，没有良好的逻辑性，怎么可能在这个行业中有好的发展。
如果你遇到的产品经理能给出一个自洽的逻辑，那么恭喜你，你遇到了还算不错的产品经理。多说一句，这个行业中专业度不够的程序员也有很多，人数比产品经理还多，道理很简单，因为程序员的数量比产品经理的数量多。
这么说并不是为了黑哪个职位，而是要告诉大家，我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数。
回到前面的主题，我们该怎么与产品经理交流呢？答案还在这个部分的主题上，以终为始。我们是要做产品，那就需要倒着思考，这个产品会给谁用，在什么场景下怎么用呢？
这个问题在 IT 行业诞生之初并不是一个显学，因为最初的 IT 行业多是为企业服务的。企业开发的一个特点是，有人有特定的需求。在这种情况下，开发团队只要把需求分析清楚就可以动手做了，在这个阶段，团队中的一个关键角色是业务分析师。即便开发出来的软件并不那么好用，企业中强行推动，最终用户也就用了。
后来，面向个人的应用开始出现。在 PC 时代和早期的互联网时代，软件开发还基本围绕着专业用户的需求，大部分软件只要能解决问题，大家还是会想办法用起来的。
但是随着互联网深入人心，软件开始向各个领域蔓延。越来越多的人进入到 IT 行业，不同的人开始在各个方向上进行尝试。这时候，软件开发的主流由面向确定性问题，逐渐变成了面向不确定性问题。
IT 行业是这样一个有趣的行业，一旦一个问题变成通用问题，就有人尝试总结各种最佳实践，一旦最佳实践积累多了，就会形成一套新的方法论。敏捷开发的方法论就是如此诞生的，这次也不例外。
精益创业最早成型的面向不确定性创造新事物的方法论是精益创业（Lean Startup），它是 Eric Ries 最早总结出来的。他在很多地方分享他的理念，不断提炼，最终在 2011 年写成一本同名的书：《精益创业》。
看到精益创业这个名字，大多数人会优先注意到“创业（Startup）”这个词。虽然这个名字里有“创业”二字，但它并不是指导人们创业挣大钱的方法论。正如前面所说，它要解决的是面向不确定性创造新事物。
只不过，创业领域是不确定性最强而且又需要创造新事物的一个领域，而只要是面向不确定性在解决问题，精益创业都是一个值得借鉴的方法论。比如，打造一个新的产品。
精益创业里的“精益”（Lean）是另外一个有趣的词。精益这个词来自精益生产，这是由丰田公司的大野耐一和新乡重夫发展出来的一套理论。
这个理论让人们开始理解价值创造与浪费之间的关系。创造价值是每个人都能理解的，但减少浪费却是很多人忽略的。所以，把这几个理念结合起来，精益创业就是在尽可能少浪费的前提下，面向不确定性创造新事物。
那精益创业到底说的是什么呢？其实很简单。我们不是要面向不确定性创造新事物吗？既然是不确定的，那你唯一能做的事情就是“试”。
怎么试呢？试就要有试的方法。精益创业的方法论里，提出“开发（build）- 测量（measure）- 认知（learn）”这样一个反馈循环。就是说，当你有了一个新的想法（idea）时，就把想法开发成产品（code）投入市场，然后，收集数据（data）获取反馈，看看前面的想法是不是靠谱。
得到的结果无非是两种：好想法继续加强，不靠谱的想法丢掉算了。不管是哪种结果，你都会产生新的想法，再进入到下一个循环里。在这个反馈循环中，你所获得的认知是最重要的，因为它是经过验证的。在精益创业中，这也是一个很重要的概念：经过验证的认知（Validated Learning）。
既然是试，既然是不确定这个想法的有效性，最好的办法就是以最低的成本试，达成同样一个目标，尽可能少做事。精益创业提出一个非常重要的概念，最小可行产品，也就是许多人口中的 MVP（Minimum Viable Product）。简言之，少花钱，多办事。
许多软件团队都会陷入一个非常典型的误区，不管什么需求都想做出来看看，殊不知，把软件完整地做出来是最大的浪费。
你为什么要学习精益创业？或许你会问，我就是一个程序员，也不打算创业，学习精益创业对我来说有什么用呢？答案在于，精益创业提供给我们的是一个做产品的思考框架，我们能够接触到的大多数产品都可以放在这个框架内思考。
有了框架结构，我们的生活就简单了，当产品经理要做一个新产品或是产品的一个新特性，我们就可以用精益创业的这几个概念来检验一下产品经理是否想清楚了。
比如，你要做这个产品特性，你要验证的东西是什么呢？他要验证的目标是否有数据可以度量呢？要解决的这个问题是不是当前最重要的事情，是否还有其他更重要的问题呢？
如果上面的问题都得到肯定的答复，那么验证这个目标是否有更简单的解决方案，是不是一定要通过开发一个产品特性来实现呢？
有了这个基础，回到前面的案例中，我对产品经理提的问题，其实就是在确定这件事要不要做。事实上，他们当时是用一个表单工具在收集用户信息，也就是说，这件事有一个可用的替代方案。鉴于当时还有很多其它需求要完成。我建议把这个需求延后考虑。
总结时刻程序员与产品经理的关系是 IT 行业一个经典的话题。许多程序员都会倾向于不问为什么就接受来自产品经理的需求，然后暗自憋气。
实际上，产品经理是一个新兴职业，即便在 IT 这个新兴行业来看，也算是新兴的。因为从前的 IT 行业更多的是面向确定性的问题，所以，需要更多的是分析。只有当面向不确定性工作时，产品经理才成为一个行业普遍存在的职业。所以，在当下，产品经理并不是一个有很好行业标准的职位。
比较早成型的面向不确定创造新事物的方法论是精益创业，它提出了“开发（build）- 测量（measure）- 认知（learn）”这样一个反馈循环和最小可行产品的概念。
当产品经理让我们做一个新的产品特性时，我们可以从精益创业这个实践上得到启发，向产品经理们问一些问题，帮助我们确定产品经理提出的需求确实是经过严格思考的。
如果今天的内容你只记住一件事，那请记住：默认所有需求都不做，直到弄清楚为什么要做这件事。
最后，我想请你回想一下，你和产品经理日常是怎样做交流的呢？欢迎在留言区写下你的想法。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 38

提建议

05 | 持续集成：集成本身就是写代码的一个环节

07 | 解决了很多技术问题，为什么你依然在“坑”里？

 写留言

精选留言(54)

Xunqf
2019-01-08
当你很产品理论的时候，他往往会拿出来一个现有的产品给你看:“人家怎么就能做到，人家能做到说明技术上是可行的，做吧。”时间久了你会发现他的需求全是抄的的别的APP，然后就觉得别人能做到的我们也一定能做。
作者回复: 你需要分清楚两件事，技术与需求。要做什么是需求，能不能做是技术。与产品经理要确认的是需求是否合理，技术上能不能实现是技术团队要考虑的问题。如果需求合理，技术上难以实现，或成本太高，就把决策上升一级，由上一层领导帮忙确认，此时此刻，在现有资源约束的情况下，是不是要做这么做，同时，最好提供一个可替换的简单方案，让领导有选择。
68
西西弗与卡夫卡
2019-01-07
有的产品经理会使出必杀技——这是老板的需求😃
作者回复: 好啊，我们一起到老板那里去，看看老板的需求是不是你给我解释得那么不明就里。这只是与产品经理交互的第一集，后面还有。
共 8 条评论
55
阿信
2019-02-26
前6讲，内容自我总结作者视角：程序员为主、产品经理为辅专栏目的：了解高效程序员如何思考的，让我们借用他们的思维方式，以提升自身的工作效率。前6讲，主要是对以终为始原则的介绍 *** # 现状 * 偶然复杂度太高。如选择了不合适的工具，或者框架等 * 目标问题 * 目标错误。拿登录为例，在需求不明确的情况下就动手了，成果不满足需求，没有价值。 * 目标含糊 (边界不清晰) # 目标选择 ## 目标的定义输出可执行的程序给用户使用，让客户能达到预期的目标，为他们带来价值 ## 目标的确认以需求来举例，如何识别需求是不是ok的 1. 多问几个为什么。产生这个需求的背景是什么，解决了什么问题，谁在什么场景下会来使用他。没有这个功能时，用户是怎样完成这个事情的，有没有其他方式可以达到目的。忌讳在需求不明确的情况下动手开发 2. 反过来做事情，或者借鉴精益创业的思想，快速试错。得到用户的反馈，让需求渐进明细 3. 确认边界。 # 如何缩短到达目标的路径 ## 减少非必要支出上的时间消耗以持续集成举例，能让工具做的事情不要让人做
展开
作者回复: 非常棒的总结！
共 4 条评论
25
七年
2019-01-07
我觉得说得都没错，但是我觉得开发得是总监级别的，不然普通开发根本没有这样发言权，在我们公司开发真的就是需求实现机器，特别弱势，就算是总监也没办法影响需求，项目经理更是屁都不敢放一句
作者回复: 你不管理他，你就很难受
共 3 条评论
25
虢國技醬
2019-01-07
打卡：以前我总是：不问为什么就接受来自产品经理的需求，然后暗自憋气这个样子，我始终不敢拒绝产品的需求，我担心领导会觉得我怠工，我担心产品会用客户来压我；后来我有一点点经验了，不敢拒绝不敢怒怼，是自己没有对某个需求有深入的思考，没有足够的反驳理由和一针见血的问题。产品提出的需求，我们程序员一定要好好看需求，仔细想每个需求的正真解决目标问题，紧急度、优先级、验收标准等等，这句心里话：默认所有需求都不做，直到弄清楚为什么要做这件事得有足够底气
展开
共 1 条评论
24
雷小鸿
2019-01-07
对我触动最大的一句话：不管什么需求先做出来看看。殊不知，把完整的需求做出来才是最大的浪费。最后真是看看而已。
共 1 条评论
18
丁丁历险记
2019-10-31
读书笔记如何干趴产品经理（玩笑） 1 洞悉全局，利用逻辑能力优势碾压产品。 2 让产品出数据（放心，测不准原理这里也适用，产品一预测就进坑了）我举个例子，王煜全老师，著名风投，强大技术背景，大家以现在视角看看他几年的预测，一读完，相信大家会说，这哥们太鬼扯了。而我想说的是，当时读的时候，我满眼看到的都是洞见。 3 多消耗产品经理，当他能讲清时，给点甜头，做一些，讲不太清的，拖着让他讲清细节。why 有何意义，预期是啥，战略意图。（再说点黑暗的，他说得清不清和开发的引导有很大关系。专栏作者，用的就是常见的刁难手法。这类手法很多，换着用。一个大方向，往细节，往宏观，往预期结论上去丢（挖坑产品背锅）思考部分招术是双刃剑，我在工作之时，偶尔会用刻意挖坑产品，甚至boss，来把一些不那么重要的需求优先级调低。但我可以负责任的讲我的初衷是希望多一些时间，把重要的事做好。太多的技术债要还了（尤其是前人的坑），而这个时间的投入很难得和他们详细的说明白。别做无意义的努力，（例如改变别人的世界观价值观），也是一条非常重要的效率之道。最后我想说的是。实力才是王道，占据技术制高点，你是可以用技术来做寻租的，你不管是想用来做好的或不好的。这个猪确实可以给你带来很大的方便。（租这个概念有一点点复杂，建议去听薛兆丰的经济学课。）
展开
16
书生
2019-01-07
产品经理——别人有的我们都要有😂
作者回复: 让产品经理先弄清别人有的到底是什么，他们为什么要有呢。
12
pyhhou
2019-01-07
想问下老师，在寻找其他检验方案替代当前的解决方案那块，是不是得需要团队里面有些个经验较为丰富的程序员？有些情况是知道当前方案很难，但是想不到更好的其他替代方案，还有就是团队里面又没啥人可以给自己建议。。。
作者回复: 搭配一个团队，一般是经验丰富和经验浅的人都要有，如果一个团队的经验都不足，那就和学生做项目一样，基本上是过家家的水平，掉到坑里就在所难免了。如果团队内部不能有足够的思考，那就去外部寻求帮助。现在有很多结交高手的机会，参加大会，参加社区活动，只要自己主动，机会总是有的。
共 2 条评论
12
Jerry.hu
2019-01-25
产品在北京……我的小伙伴们都在上海，每一次需求移交之前都会提前让小伙伴们reciew一遍将所以疑惑的地方记下来，并在移交之前先做一次评审，直到pm完全能够解惑我们后才开始移交
作者回复: 这是一个不错的做法，事前多思考，事后少后悔。
10
SA
2019-01-07
郑老师，精益创业用到软件开发过程中本质上是否就是原型开发模式呀？我们项目组在实现一些较大的系统架构优化时，比如引入新技术时也经常用这个思路去实现，就是先以最小的成本（最省时省力）做出一个最小化的可行产品，其实就是原型，然后快速用起来，在用的过程中持续观察，持续完善，直到最终满足客户需求，最小化可行产品是下限，刚刚满足客户需求（刚刚好）是上限。
作者回复: 原型和MVP最大的区别在于，原型是要丢弃的，而MVP真的就是一个完整的产品，能提供完整的用户服务，后面还会进一步讨论MVP，敬请期待。
9
冰糕不冰
2019-01-08
让我最头疼的不是技术问题，而是产品经理自己都搞不清楚要怎么做。还要技术去提醒他！不过没办法，只能按照老师说的，开发前同他一起协作完成具体需求！
作者回复: 早头疼还是晚头疼的差别
7
sam
2020-06-28
曾经在一家小公司，我们也无比推崇精益创业，进入迅速试错阶段，到留下来的是一堆堆的坑，没有去总结经验得出认知。
作者回复: 精益创业不是为了快，是为了验证想法。
6
狼
2019-04-17
目前接触过的有三个产品经理，第一个接触时间较少，但是能提供较完整的产品思路，但有的功能加班做完了，用的人很少；第二个感觉有时候提需求是灵感闪现，为了一个用户改功能，而影响了其他大多数用户；第三个基本是只有个大概，问细了就卡住了；但这些都可以沟通，主要的是领导，产品刚说需求，领导就答应下来了，说这个好做那个好做，然后发表一下自己的观点，根本就不知道目前项目代码具体结构是怎样的，按他的想法是不是容易实现，直接就定版了，当场提问题吧，第一可能当时没有想那么全面，第二领导面子，等具体做的时候反馈吧，给不了具体意见，东拉西扯，还是一套理论建议，感觉是说了很多，但事后一想，跟没说一样
展开
作者回复: 遇到一个好的产品经理，概率并不高。
共 2 条评论
5
蓝色天际
2019-03-15
在讨论业务时，我们用精益画布，可以在《精益创业实践》中找到。
作者回复: 很好的做法！
共 2 条评论
5
Pray
2019-01-07
没有产品经理，直接面向老板。别人有的我都要，没有的容我再想想。
作者回复: 不靠谱的经典姿态
5
何处似樽前
2019-01-07
郑老师，经过这段时间的学习感觉收获颇丰，非常庆幸能看到这么好的分享。我是神州数码的，跟您应该是在同一个大厦，如果有机会希望能当面多请教。
编辑回复: 赞😋
5
段启超
2019-03-18
今天听到产品和经理聊天：要不就先做出来看看吧，不行再改。听着都想象到了下一轮混乱开发的开始。我觉得还得自己主动一些，多跟他们讨论下需求的合理性，容忍这种放羊式的开发流程，是浪费自己的时间，也是在浪费团队的时间。
作者回复: 不专业的产品经理和糊涂的开发团队共同塑造了混乱的开发过程。
4
Sch0ng
2020-07-20
产品经理漂亮妹子多，研发男同胞多。有时候遇到事情不由自主地宽容起来。不要替她扛事，出了问题让她自己扛，助其成长，是对她好，也有助于产研关系和项目长期可持续发展。
作者回复: 男产品经理的日子不好过啊！
3
helloworld
2019-02-17
要经过严格的分析论证后才提新需求，可悲的是，目前新需求大多数就是屁股决定脑袋
作者回复: 先要意识到这种做法是不对的，然后再想办法改变。
3

