1、寻求产品发布的PUF状态
新开发一个功能，需要多长时间？
1周？ 10天？1 个月？嘿嘿...
立项一个新功能之前，产品人员和开发人员首要需要明确的问题是：什么时候上线？通常的做法是：产品让研发提前预估时间。据我所知，让开发人员预估时间，是一件及其不靠谱的事情，即使最信守诺言的程序员，在面对精细化功能的时候，大概率，是不能按时完成的。
我自己目前的经验做法是：采取一种叫做PUF的发布状态。
PUF(Product/User Fit)，即：产品与用户相切合。（PUF这个词汇，来源于我对另一个硅谷词汇PMF的演化，PUF这个叫法更适合我目前的处境）
寻求产品可发布的PUF状态，并不是要追求功能的大而全，并不是把所有功能都开发到面面俱到之后才发布，而是说，得追求精、准、快，以配合前端打动用户为第一目标，以追求切中用户痛点为开发要务，务必、务必不能盲目去追求功能的完整性和全面覆盖，蛮干或大干一场只会延误上线时机，整个开发过程中，要坚持分步完善，不要试图一口把用户需求吃光。
团队代码一定要沿着切中用户最急需、最迫切、最不可舍去的那些需求点精进，一些边边角角的玩意，会累死或拖死开发人员，边角料功能会占据开发人员大量的琐碎时间，对待这些非核心功能的态度，可以通过版本迭代或采取战术性来延迟。
团队开发需要明白一个道理：代码之中，仅仅只有20%的代码，有机会成为内容付费的价值代码，剩余80%的功能和业务，都只是铺垫。
在小团队，有一个办法，可以快速帮你检测哪些是价值代码，你可以试着问问自己：如果我是用户，我做的哪些代码功能，能打动我，能令我掏钱....
我自己坚持的一些PUF小招数：
a、兼容旧版本，新版本是对旧版本的高阶推广；
b、功能是可固化的最小单位，不可向下再拆解，满足最基本业务即可发布；
c、快速迭代，把问题留在后端；
2、试错-----------小幅度印证产品主线
优秀的代码功能，是设计出来的吗？
让产品和研发坐在一起，是否就能规划出完整的用户需求？
据我观测，仅仅只有小部分站在行业最顶尖、最前沿的那波业务高手，才拥有那种抽刀断水的产品能力，这样的人，我身边还是有的，嘿嘿！
但是，对大部分人来说，要做出优秀产品的方法，最通用的模式，我觉得，只有一个：试错！
要真正去实现产品的PUF状态，需要经历多次产品试错、印证、调整，甚至需要开发团队从0开始去累积经验，只有当内部经验值累积到达燃点之后，业务开发主线方向，才会像圆锥的顶部那样，逐渐凸显出来，开发团队只有找到业务顶部最核心的价值点，通过试错的方式，团队成员才会知道下一步该怎么走，用户真正需要什么，又对什么东西感冒，一旦拿捏到用户需求跳动的脉搏，剩下的事情，就是利用你手中的代码利剑，向下深挖、改进，去细心打磨，做精！做透！做绝！一定要不断强化你已找到的小优势和概念，直到用户付费。用户付费，是你代码功能达到PUF状态的标志！
在没有找到PUF状态之前，产品人员和开发人员都将陷入无边的泥潭和黑暗，返工、推倒、事故、甚至废弃，不要灰心噢！PUF的支撑点，很可能隐藏在一些不经意的地方，产品和研发自以为不重要的点，很可能是用户关心的，当撤销一个功能，或一个功能突然不可用，而用户的反应瞬间变很得强烈或愤怒之时，这样的功能，你可能需要引起重视。因此，产品和研发很有必要得混迹于自己的用户群和社区，去切身感受功能上线之后用户的心声，从用户的感受中，去吸取开发养分，避免自己沦为工具和轮子，研发最悲哀的事情：莫过于，你做的功能，没有人用，而你，失去了开发的动力和激情！
试错之中，还有一种特殊情况：低级别失误！
低级别错误，这种情况，防不胜防，会令开发人员备受打击。但是，越重要的功能，出现低级别失误的概率，也会变大！我总结出来，出现低级别失误的原因，源自于大脑的聚焦点偏差，俗称：灯下黑！！！
当出现低级别失误时，你的救命小脚本，得像毛驴一样，可以帮你快速修复问题和还原数据。
总结起来：并没有人，一开始可以完全预测用户需求的走向！如果需求可以完全被预判，嘿嘿，程序员自己也可以创业发财了，不是吗？研发人员真正要做的，是通过试错和试探，抓取到用户需求中最拔尖的功能，一旦你辨明方向，要尽量、尽快的去释放产品形态。
3、怎么对待刚需功能？---------避免非连续性增长陷阱
科长君，目前身处教育行业，深深地明白：书、题、直播就是刚需，是真正的硬刚需！
是不是只把这几个硬刚需做完，研发人员就歇菜了呢？这个问题，困惑了我很久！最近也是别的高手，解答了我的困惑。
诺基亚手机，抗摔、信号好，鼎盛时期，诺基亚就是手机的代名词，但是，刚需，最后还是败了！！一去，不复返...
你觉得真的是刚需败了吗？不是，是用户的需求变了，这个例子，只是向你说明：用户，会变！会变！会变！如果你只盯住那几个硬刚需，一旦刚需功能成为全行业的标配，或刚需被竞品快速跟进，用户对刚需的需求就变得不那么强烈了，而产品即会遭遇传说中的非连续性增长陷阱。
因此，产品和开发人员的视野，需要比用户快一步，需要通过不断的产品玩法和模式，去捕捉到用户需求的变化，不断刷新对用户的理解，跟上用户对产品的变化，顺应走势。你只需记住：刚需不可靠，用户会变，就像，你也会变，嘿嘿！
4、用户的诉求，是你继续深挖的源泉
创意是不会枯竭了！会枯竭的，是你对待客户需求变化的懒惰，雷军有句话是说：不要用战术上的勤奋来掩盖战略上的懒惰！
创意不会枯竭，本质的原因是：用户愿意继续体验更优质的产品和服务！
但是，如果没有了对用户的反馈和调研，开发和产品都会两败俱伤，一旦开发和产品思路尿不到一个壶里，开发人员就会对产品充满深深的怀疑，开发人员会怀疑产品做的东西有没有意义，而产品人员也会对开发最终的呈现充满失落和妥协，失落于这不是我要的产品，产品和开发会形成对立体，遭遇传说中的：“幽灵堵车”。
当你所做的东西，看起来别扭、难受、不通用，最好的办法是：求助于你所在行业中的那个业务高手，他会指明你面临的困境，避免走弯路和闭门造车。但是多半时候，你得学会自救，程序员需要去集思广益，需要聆听别人的声音和想法，尤其是内容付费这种产品功能，最需要听取的，是内容原创者的想法，需要及时回应内容输出者的预判。
在微创公司，并没有那么大的技术架构问题或高并发难题，拥抱云之后，真正的问题，并不是技术问题，而是产品业务流程、用户响应、进度管控，是你的产品或功能，以一种什么样的业务组合或创新模式与用户见面...
5、开发致胜的关键
精诚、有责任心的伙伴
前、后端分工合作，有独挡一面的同事
敏捷开发，小组讨论，结队编程，长期跟踪..
....
PS:下图，是我养的兰花，已经开花了....
