写在之前
今年年初给自己安排了一个任务,每个月写一遍感悟性的文章。促使自己沉淀并思考。 回望自己在软件行业的经历,总是感叹如果早知道某某事情多好。这篇文章主要写一些建议,如果这边文章有幸被你看到, 希望对你有帮助。
最近在“极客时间”看一些文章, 刚看完的课程叫硅谷产品实战, 主要写作者在硅谷工作时的感受, 有兴趣的朋友可以去集客时间看看文章 ,共36讲。其中有一些片段我比较有感触,增加一些思考记录下来。
1.最小化可行产品
精益创业代表了一种不断形成创新的新方法,它源于“精益生产”的理念,提倡企业进行“验证性学习”,先向市场推出极简的原型产品,然后在不断地试验和学习中,以最小的成本和有效的方式验证产品是否符合用户需求,灵活调整方向。如果产品不符合市场需求,最好能“快速地失败、廉价地失败”,而不要“昂贵地失败”;如果产品被用户认可也应该不断学习,挖掘用户需求,迭代优化产品。
“最小化”在这里的意思就是,没有任何一个功能是“加上去也挺好的”,但是少了任何一个功能都无法解决用户最基本的需求。最小化 = 降低试错成本,速度 > 完美
“最小化”的概念我觉得是这个行业从业人员都应该具备的。开发人员的“最小化”概念可能体现在某个功能上,在设计上做到功能可以最小化提交, 后续扩展可以不影响已实现的功能,也就是常说的开闭原则,项目经理的“最小化”概念可能体现在项目任务上如何取拆分,迭代提交都是完整可用的功能
2.产品经理权衡取舍
产品经理每天做得最多的事情就是砍功能:
- 删减产品需求文档上的功能,只保留最重要的功能;
- 已经决定了要加功能,但出现了突发情况,需要临时决定到底要不要砍功能。
在项目中很少有产品经理能做到筛选砍功能,时不时还会增加任务。 要么是客户要求必须完成;要么是领导要求必须完成。 整个项目就发生了变化, 发布时间是固定的,项目内容是增长的。项目成员都有挫败感
- 开发人员在抱怨任务超出预期,加班也完不成任务
- 项目经理在抱怨项目超出可控范围。无法预估关键节点
- 客户和领导抱怨怎么项目又延期
这种情况下,沟通变得愈发重要,需要有人站出来沟通,组织大家取舍。 我记得第一任项目经理叫宋春勇,他曾经跟我说过一句话:项目是谈出来的,不是做出来的
3.制定产品的成功指标
约翰 · 道尔(John Doerr)是硅谷最牛的风险投资人,是谷歌、亚马逊、网景、升阳电脑等公司的早期投资人,更在 1999 年投资谷歌时,教给了创始人成功指标(OKR)的概念,帮助谷歌达到了今天的高度。
2018 年 4 月, 约翰 · 道尔出了一本叫作《以你在乎的作为衡量指标》(Measure What Matters)的书,专门讲成功指标这件事。他在书中指出:指标是为了定义你想要完成的目标,需要表达清楚在什么期限之内、要达到什么具体的、可衡量的结果。 换句话来说,一个好的指标应该是像“2018 年底之前实现 100 万日活”这样的,而“让用户多花时间在 APP 上”、“争取用户规模达到 100 万”都因为缺少了关键信息不能算是一个好指标。
“OKR(Objectives and Key Results)即目标与关键成果法,是一套明确和跟踪目标及其完成情况的管理工具和方法,由英特尔公司创始人安迪·葛洛夫(AndyGrove)发明,2015年后,百度、华为、字节跳动等企业陆续推广
4.产品经理和设计师沟通
同样一份产品需求文档,有的设计师认为功能描述太具体,限制了他们发挥的空间;有的设计师却认为不够具体。这是我刚做产品经理时感觉非常苦恼的一个问题,在和设计师打了多次交道后,我才明白了“众口难调”的原因,以及怎么处理这种情况。在我看来,处理这种问题最直接、最高效的方式是,和你的设计师搞好关系,问问他们是喜欢文档中功能描述写得清楚些,还是只要给出策略性的建议就可以了。你可以在每个项目的文档中先写策略性的内容,然后对设计师说:“这是咱们产品的策略和大致想法,你先看看有哪些部分不够清晰,我来写得更具体一些。”只有多沟通,才能更高效
我觉得文章对设计师特点总结很到位,尤其是第三点
- 设计师是完美型人格,艺术家
- 设计师多数是没有产品设计能力的,他们的关注点在功能实现上而非功能使用上
- 设计师预估工期的能力比较差,并且多数是乐观预估