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 ]
[
下一页 ]