1704234395
问:“那我们的功能有没有和推广挂钩,比如和淘宝直通车做整合,直接让它来做投放的优化?”
1704234396
1704234397
这个问题我们还没有想过,但立刻意识到可能是一个方向。当时的对话还有很多,这里就展示到此,事后我们进一步思考了上述问题,感到对产品的帮助确实很大。
1704234398
1704234399
通过问答的方式,可以提升思考的深度。同样,还可以通过演练的方式来提升规划的实战技能。
1704234400
1704234401
8.2.3 提升规划能力的实践
1704234402
1704234403
下面分享一个淘宝某些团队的简单实践。
1704234404
1704234405
►让产品团队每个人做一份自己产品的规划,规划周期可以限定为3个月。重点是每个月要拿出1天时间,每个人轮流宣讲,听众是团队其他人。
1704234406
1704234407
►每个人讲完以后,听众轮流说一点“好”与一点“可以更好”(其实就是“不好”的委婉说法),不许重复。可以针对规划本身,也可以针对PPT制作、演讲技巧等。
1704234408
1704234409
►主讲人自己在白板上记录大家的发言,等所有人发言完毕后统一进行回复和讨论,会后优化产品规划PPT以供下次讨论。
1704234410
1704234411
一般半天时间(4小时计)可以讨论3个人的规划,假设是一个6个人的团队,一天时间正好全部讨论完。最终每份规划可以得到5点“好”与5点“可以更好”,全组就能得到30点“好”与30点“可以更好”。相信3到6个月下来,每个人的产品规划、PPT演示能力都会有显著的提升。
1704234412
1704234413
熟练之后,对现场点评的内容还可以进行约定和细分,比如从产品规划的Why、What、How几个层面分别给出评价。
1704234414
1704234415
还有一个小技巧:如果团队成员比较温和,不愿意互相批评,可以用评选最优评论员与最差评论员并适当奖惩的措施来加以刺激。
1704234416
1704234417
这种在实战中互相学习的模式,可以推广到“如何写出一份好的PRD”“如何做竞品分析”等诸多产品经理技能提高目标,成败不论,贵在坚持。
1704234418
1704234419
1704234420
1704234421
1704234423
人人都是产品经理2.0:写给泛产品经理 8.3 迭代:再理解敏捷
1704234424
1704234425
说完规划再说迭代。
1704234426
1704234427
提到“迭代”一定绕不开“敏捷”这个词。敏捷是一个偏技术的概念,是指以用户的需求变化为核心,采用循序渐进的方法进行软件开发。敏捷最重要的不是那些具体方法论,反而是底层的价值观、宣言和原则。对此先说说自己的理解,然后再分享一些实践。
1704234428
1704234429
8.3.1 价值观、宣言与原则
1704234430
1704234431
首先结合敏捷的五个价值观,谈一谈我自己的体会。
1704234432
1704234433
沟通
1704234434
1704234435
团队中绝大多数的问题,问五次为什么之后,都会归结于人的问题,或沟通的问题。团队配合过程中,开始就约定好明确的“沟通计划”和“沟通原则”是很有必要的,比如“工作日每天18点开站立会议”“最新信息及时同步给相关人,不要藏着、掖着”等具体约定背后的目的,是要实现团队成员之间真正的互相信任、互相认可。
1704234436
1704234437
简单
1704234438
1704234439
简单强调一切按需,遵循的是Less is more(少做就是多做)原则。随着技术发展,各种基础设施越来越完善,有很多任务都可以由更小的团队来完成。小团队在做产品时,要努力做一个爆一个,不要堆砌功能。在团队管理、文档、流程等方面也要力求简单,切忌为了显得“正规”而增加一些不必要的规范。
1704234440
1704234441
反馈
1704234442
1704234443
及时获取反馈,用反馈来拥抱变化。阿里的价值观里面有一条“拥抱变化”,让所有人印象深刻。因为我们所在的这个行业实在变化太快,只有适应变化才能够生存下去。及时变化的前提是不断地收到各种反馈,所以信息透明、共享是整个团队必须做到的。Teambition公司的前台有一块很大的屏幕,实时展示整个公司的各种运营数据,供全公司同事甚至外部参观者随时了解,这种信息公开的力度可不是每个企业都能做到的。
1704234444
[
上一页 ]
[ :1.704234395e+09 ]
[
下一页 ]