人人都是产品经理-7
执行:立项组队与研发生产
7.1从“想清楚”到“做出来”
7.1.1原型验证与NPS
原型验证:考察用户是否认可解决方案,产品立项前做出的最重要的判断。也称产品概念测试(POC),以尽量低的成本做出产品原型或Demo.
NPS:净推荐值,计量用户将向其他人推荐某产品可能性的指数,用户忠诚度分析指标。
NPS=(推荐者数-批评者数)/总样本数×100%,在0~10分之间打分。
>>推荐者:打分在9~10分之间,是具有狂热忠诚度的人,他们会继续使用产品并将其引荐给其他人,可以帮助产品成长。
>>被动者:打分在7~8分之间,总体满意但并不狂热,会用但不会传播,可能考虑其他竞争对手的产品。
>>批评者打分在0~6分之间,使用后不满意,或者对你的产品没有忠诚度,可能有负面口碑,会阻碍产品成长。
NPS达到50%以上比较理想,产品上市后,定期测试NPS,并且做出相应改善。
7.1.2产品***会与关键节点
产品***会:判断对产品的投入成本,通常由手握有资源的人组成。有以下四个关键节点。
>>概念筛选:根据各种背景信息、判断要不要对某个产品概念进行细化、展开。如果认为可行,就要启动全方位的需求采集工作。
>>立项组队:对产品进行原型验证、评估需要投入多少研发生产资源,有多少风险及如何应对。如果立项获批,就要启动项目、组队开干。
>>上线发布:产品完成开发后,千万不要因为怕浪费而仓促上线。这时还是要先用真实产品找种子用户验证,如果没有通过验证,就不要上线,以免浪费更多的客服、销售、运营维护资源。
>>营销推广:为提升用户量,上线之后马上就开始推广,也是常见的错误。应该先花二段时间考察用户是否活跃,是否会再次使用产品。当这些指标达到预期后,才可以大力推广,否则就是浪费资源。
7.2立项:搞定各种资源
需要获取的资源:人和物
7.2.1关于人:团队、组织
组织形成的三种原始动力,任何组织的凝聚力都是这三种原动力的混合,只是配比不同:
>>权力强力组织,比如国家***,用“枪杆子”保证绳之以法。
>>利益商业组织,比如公司企业,用“钱袋子”支撑“诱之以利”
>>共识松散组织,比如公益社团,用“笔杆子”达成“晓之以理、动之以情”
7.2.2关于物:政策、资金等
包括公司内外各种政策、流程、资金等的支持。
本节描述做哪些事,才能获取到关键物。这些准备可以通过MRD文档表达。
>>MRD:市场需求文档,除了描述问题,解释为什么么要做这个产品,还要给出解决方案。这个文档比较像产品规划和商业计划书(BP,Business Plan),是写给资源拥有方看的。
>>PRD:产品需求文档,是在项目过程中写给开发、测试、设计师看的,仔细描述产品功能要怎么做。
以Why、Wnat、How三部分来谈MRD要包含的内容
>>Why:为什么要做这个产品
“动之以情”的素材,让受众感受到需求之强烈,问题之严重;用ROI(投资回报率)来“诱之以利”。
>>what:产品MVP包含哪些功能及要做什么
在MRD中列出,用产品架构图表达。
>>How:项目计划及风险对策等
7.3组队:聊聊初创团队
7.3.1如何快速知己知彼
在非工作时间、地点,进行沟通。讨论一些问题,比如:为什么要来这个团队,对一年后收获的底线预期,个人对团队的帮助,自己能做什么?自己想做什么?项目失败最可能的原因是什么?在和谐的气氛中通过批评和自我批评来暴露一些问题。
最终可以结合以上问题,由团队共同提出非业务层面的改进方案,但方案的核心要点最好不要超过三条。比如,其中一条有可能类似——将决策机制从原来的核心团队共同讨论,直到达成二致,改为核心团队共同讨论,最终由老大拍板后执行,或是核心团队每周必须聚餐之类很具体的举措。
对提升早期核心团队的战斗力非常关键,问题的具体答案是什么其实不重要,重要的是共同参与。
7.3.2小团队的沟通协作
简单地说,实时沟通在需要各方参与讨论时的效率高于延时沟通,但对沟通发起者有利,被动方正在做的工作往往会被打断。所以,加个简单的预约行为会更好。延时沟通用于单向传递信息时的效率更高,无须协调双方时间,紧急情况下加个通知提醒即可。线下沟通的信息传递效率高于线上,因为除了文字、语音、图片等,还可加人表情、手势等辅助形式,但缺点在于对沟通各方的地理位置有要求,视频会议也只能解决部分问题线上沟通组织协调各方时间的成本低于线下,如今更可以通过手机随时随地讨论事情。
我们可以根据事情的重要和紧急程度,灵活使用各种沟通协作方法。
7.3.3小团队与大团队的区别
大公司一样以流程为中心,对于初创公司,组织架构应该以目标为中心,按需设置部门,而组建公司之前,应该以机会为中心。因为在最早的阶段,运气的确更重要。
7.3.4借助第三方力量做产品
在旧模式下,缺钱则募资,缺人则招人;在新模式下,缺钱则众筹资,缺人则众包。
利用非全职员工来解决问题,更常见的说法是众包、外包、顾问
众包服务又分两类:一类是帮助现有的人节省时间,第二类是借助外面的人力。
这种人才的专业能力众包,分成四个层面:
>>第一个层面:分享,就是我说你听,借的力只是一个想法和做法,我并没有帮你做事,而且针对性也不是很强。
>>第二个层面:座谈,可以有针对性地进行讨论,给出一些有针对性的建议。
>>第三个层面咨询,给你指导,带着你做。
>>第四个层面外包,直接上手,帮你搞定。
7.4研发产品时,我们做什么
立项到产品发布期间,原型验证完成、产品***会评审通过以后,要经历立项、需求、开发、测试、发布几大环节,然后再拿着做出来的产品找用户验证,最后做项目总结。
为了保证整个过程的顺利进行,产品经理还要把控三件事。一是文档管理,二
是流程管理,三是敏捷方法。
7.4.1产品经理要不要懂技术
>>底线时可以和技术人员无障碍沟通,并不要求会写代码。
>>多向技术伙伴请教,自学一些技术知识。
>>根据所负责的产品,决定要懂哪些技术,懂到什么程度。
>>要特别关注技术方案与业务场景的关联。
分别看一点开发、测试、设计、运维等方面的专业知识。
7.4.2如何做一个让Ta们讨厌的人
1实施之前:
>>不说清需求价值
>>不去想功能细节
>>帮技术评估工作量
>>逼着技术团队承诺
2实施过程之中
>>做了一半改需求
>>开发过程中消失
>>过度关注实现细节
3产品发布之后
>>发布后没有反馈
>>任务无节奏感
4全程适用
>>优柔寡断无决断
>>报喜不报忧
>>不要把他们当人
以上内容均是正话反说,产品经理在产品过程中应该避免以上事件,关注研发生产过程中与他人沟通和配合的注意事项。
#产品#