2019-02-11这篇可以说是精益创业的姊妹篇，现在在做的项目也基本是按照MVP的思路来做的，只是任务分解方面还不够细，有点贪全～～
总的来说，小步快跑。先弄清客户想要什么，整理后再用自己的语言复述一遍，后面拿着原型+业务交互给客户确认，同时把自己的设计理念植入进去和客户探讨，有些点对方之前也没有想清楚，尤其是实现方面需要专业的软件意见去参考，而我们再从探讨中更新自己的认知，如此往复几次，大方向上就不会有偏差，后面在实施过程中再局部调整。个人认为尤其是对于不确定性很高或者从零开始的工作，这是个可操作的方式，也希望能从大家的分享中获得灵感！作者回复: 你理解了！
1 10
2019-02-17之前做了一个类似TodoList的项目，有个功能是“历史任务”。
当时由于时间紧急，与产品经理商量，在第一版上线时，其实并没有上线“历史任务”这个功能——因为历史任务的定义是一个月之前的任务。
在接下来的版本中再实现“历史任务”这个功能，与老师处理问题的思路如出一辙。作者回复: 多谢分享！
6
2019-02-11补充一个和MVP有关的话题。前阵子有个关于产品技术的段子，讲的是技术问产品，开发某个功能预计会有多少人用；而产品说，不上线不知道会有多少人用。其实产品要有一种意识，即开发程序是代价高昂的解决方案，特别是开发某个不确定的特性。所以他需要花许多力气琢磨，找出方案的关键点，构建MVP去验证，而不是先做一个完整的产品方案让开发去完成。虽然这会导致产品经理多做很多工作，但对于团队来说整体代价反而是小的。更进一步说，产品经理的职责本来就是找到最经济有效的解决方案，而不是画一个原型让开发去完成作者回复: 糊涂的产品经理到处都是，程序员不反抗，他们就意识不到自己的糊涂。
6
2019-05-22最小可行性产品 也就是用最小的代价去找到一条给用户完整体验的路径，这种完整不是指模块做得有多完整，而是这条路径，用户的体验是否通畅。 1
2019-03-24总结如下：1.MVP的核心是最小可行产品。是指团队在Deadline前推出一个客户最小可行的产品。作者回复: MVP 就是最小可行产品，Deadline 是形式，MVP 是内核。
1
2019-02-12公司比较老，并且是to b的那种，目前对于新项目主要还是瀑布式的开发一个基线，后续再迭代。看了本文受益匪浅。不过有一个问题：像文中举的p2p的例子，这样开发会不会风险太大?利益与风险的权衡是由老板做决定吗？谢谢作者回复: 好问题，当时老板给的要求是尽快上线，这是我们找到的一条通往目标的路径，而且我们给出了一个合理的推理，老板并不反对。
所谓风险是不确定的，当你看到一个几乎是确定的路径，你就不会那么担心了。很多团队是用胆子大来做事，这才是风险很大的。 1
2019-11-12如果全篇就记住一句话。那么就是开发的成本很高很高，不要烂用。
2019-10-14文章说，得益于原型工具的快速发展，我们用一个原型工具做出了相对完整的...
这样的原形工具是指什么啊？有推荐的吗
2019-07-23举例太精辟了
2019-06-27如果做的产品是面向大众的怎么办，不同客户理解和需求不一样，怎么做这个需求呢作者回复: 前行到26
2019-05-09嗯……郑大大每当你讲到需求管理时候，我总是没那么满意😄😄😄- 2019-05-09我们第一期还做了提前还款！
用户不可能一个月还款，但是能提前还款呀哈哈哈哈哈哈 1 
2019-03-29好多互联网公司都是做的创新型产品，不断去尝试新想法，to B还好说，to c恐怕无最终实现还是不好说，此时就因该如作者举的最后例子，寻找用户立即使用的和一个月后才会用的去排档期。作者回复: 越是 to C 这种不确定性的产品，越要在前期多试。
- 2019-03-28学得很受用，不愧是thoughtwork出来的。
2019-03-24原来还可以这样。谢谢老师分享
2019-02-13MVP最小可行的产品，之前对"最小"理解成了功能最小，原来是"最小代价"。作者回复: 道理挺简单，就怕走错路。