把事情做好,直到最后一刻

作者: 叽歪黄油小面包 | 来源:发表于2017-08-08 13:17 被阅读184次

    我参与了“来简书聊聊你的产品之路|@产品专题征文”。

    这是一位产品经理的所想,里面包含了自己走过的很多坑、对新人的方法建议,也是一段难忘的项目回顾。

    张艾嘉谈《念念》

    01  愿景

    产品愿景里面有没有瞎猜跟直觉的成份?有!

    我是不太相信全年规划的,用已知去定位未来,多少有点无稽之谈。只有不断的实践,掌握不同角度与更高体量的信息,才有机会不断验证自己的直觉,这简直跟游戏一样,Poker is about using your chips to gather information faster than everyone else.(扑克的本质就是利用你的筹码,比对手更快地获得信息。)

    由此说来,盲目堆砌不切实际的计划是产品大忌。但是无计划地工作也不行。我们在愿景阶段,时常需要一份看上去还过得去的产品大纲,让愿景得以落地。

    产品大纲究竟是什么呢?

    1、大纲不仅仅是功能列表。功能列表往往记录的是需求任务,功能模块,但它们并不能阐述或者描绘产品方案。

    2、大纲不仅仅是MRD,特别是设计、研发与测试,他们是产品团队的战略合作伙伴,而不是马仔,他们需要一张蓝图,更需要加强对产品的认可与信任。

    3、大纲没有绝对模板,Word,PPT,Excel,甚至手写稿,无非是你所在团队习惯什么风格,哪种形式更利于沟通。但是书面的效果一定会比口头来的好。

    大多数时候,“客户”跟“目标用户”都是被混为一谈的。我的主观经验是:目标用户的定义细度与产品经理的方案靠谱度成正相关。

    可以把UX设计大纲与战略地图混搭着使用。

    UX设计大纲并不非得用户体验人员,产品经理可以成为直接的撰写者,这份任务清单里会包括:

    ① 项目背景和项目描述:项目背景介绍和项目市场环境描述。

    ② 类别/行业综述:市场竞争、行业趋势,品牌和旗下品牌的定位,产品和服务的推广策略、营销策略等。

    ③ 目标用户综述:对产品和服务的目标用户进行全面的讨论,比如希望哪些用户会对方案感兴趣,会如何使用。

    ④ 公司作品集:理清公司所有的产品或它提供的所有服务。这个项目和其他产品与服务的关系是什么?它如何体现公司的品牌定位?

    ⑤ 商业目标和UX设计策略:根据具体的商业目标制定相应的设计方案与开发策略。

    ⑥ 项目规模、时间表、预算:项目时间表。

    ⑦ 研究数据:总结一些关键的研究数据。

    ⑧ 附录:比如竞争对手的产品截图、研究数据报告等。

    而战略地图常被用于上市公司的战略规划,本质上同样适用于大型的产品项目。

    ① 一句话提炼产品目标或者愿景,这是可以全员记得的一句话。

    ② 如何达到这个目标?明确方法与策略1、2、3。

    ③ 各个部门/细分领域围绕目标,各自拆分后有哪些子任务,如何做?

    所谓“梳理”,不是罗列功能、汇总页面或者标记负责的对应部门,而是全局上把各个方向的业务整合成脉络。

    最终目标是整体上形成一个总分结构,让业务之间能够整合到一起。但是输出给业务部门的,又会是另一份具有销售语言的业务说明与介绍,摒弃计算机用语或者框架背后的逻辑,只关心——客户要什么。

    随记与火花:冯唐的一期《搜神记》,日本天妇罗之神早乙女者哉与他的中国弟子雪崴斗法炸天妇罗,美食家蒙眼试吃后评比。相同的锅、相同的环境、相同的评鉴者,徒弟有主场优势,但还是输了。

    师傅的年龄、阅历,岁月所积累的东西被包含在小小的天妇罗里。早乙女者哉通过技术所表达出的周正、完整,短短20秒的煎炸,克服了心里的杂念,把工作做到极致的意念,是最后胜出的深层原因。

    当时我就在想,一个工作若干年的产品经理跟一个新人处理相同的需求,使用相同的PRD模板,参考相同的老规则,都有或者都没有数据可以参考,两个需求的差别在哪里?

    “好”不光是需求文档本身清晰、严谨与可阅读,更重要的是体现在Ta所负责的事情。

    “好”不仅仅是一次性的做好,而且是长期的、一次又一次的做好。结果背后凝结方法与理念,并没有所谓的运气。

    02  团队 

    罗马不是一天建成的。信心建立信心,成果孕育成果,简单的、独立的小模块之间滚雪球一样组装起来,方案有体系的呈现。

    肖恩埃利斯:创业增长金字塔模型

    这套思路不仅仅在产品方案上得以强化,项目采取的亦是去中心化的分布式管理。

    团队成员高度自治,个人负责的模块之间并行,彼此会有连接,但是这种连接是对等的,没有强制性的“领导”。产品人员在自己的领域自主决定,但是自身需要根据全局规则与项目情况作出及时的反应。

    对于必须绝对控制的全局规则,为了保证其不垮。但在个人独立负责模块,反而需要一个“失控”的状态,团队宁愿去损耗效率,也要鼓励这样的复杂性,不能形成行动按钮用红字还是绿色都需要领导去确认,这是组织僵化,并不是对事情负责。

    新人在专业方向上的成长路径,均是从低到高的包容架构。

    ① 先做最简单的事情:面对某个模块下的简单需求,知道如何下手。

    ② 保证类似简单的需求:独立处理,不出错。

    ③ 从点到线:基于处理过的独立需求,去考虑它从属的上一级模块/功能应该如何改进。

    ④ 从点到线:在步骤3的过程中,会有很多矛盾,不要改变这个简单的需求。

    ⑤ 从线到面:面对不同的、新增的模块,能像步骤2一样,独立处理,不出错。

    重复以上步骤。出错不可怕,每一次级就算有较大的瑕疵,对于更高的一级来说,只相当于一个小故障,可以被总体架构所包容。

    随记与火花:

    K.K《失控》里提及的“蜂群思维”,也有人类似的“间接通信”的概念。

    古人对蜜蜂的认识几乎都是错的,蜂后并不是统治者,甚至蜂群离巢涌出时,蜂后在团队中也只是跟随。团队中究竟是如何做决策的呢?工蜂负责侦查地点,向上一级汇报备选地点,更多的成员在备选地中再次探查,确定这个地方好或者不好,但是很少再去探查其他地点。最后收益递增,最大的蜂群决定了团队的方向。

    甚至蜂后是谁选出的呢?也是蜂群本身。蜂群是彻底的母权制,而且是姐妹关系,等于说蜂后不过是普通人,只是被姐妹们喂了蜂王浆,因缘际会成了太后。

    在蜂群中,没有一只蜜蜂可以控制整个团队,但是无形中,团队中有一股力量引导了整个群体,量变引起质变,最后改变了整个团队的走向。

    03  运营

    前期靠愿景,中期靠团队,后期靠运营。

    产品经理的本质是在做服务,而不是追求个人满足。作为出厨子,你端出一道菜,只让顾客觉得这道菜味道不错,这样就已经刚刚好。

    在面向企业的运营问题上,时刻提醒着得把自己隐藏起来。

    企业型的产品,跟我作为普通消费者接触的 to C 不一样。

    1、与 to C 的消费者投票不同,to B 完全是商业行为,更贵的产品会卖给更少的客户,销售在线下业务中承担了很关键的作用。所以也很能理解,销售会偏爱更多的功能,而不是去评估这个功能是否是每个人都需要的,但是如果得不到销售的支持,极有可能这款产品都不能呈现给客户。

    2、传统展会上遇到的10个客户,在消费者领域不过是海量客户群中的沧海一粟,对 to B 来说,可能真的就是10个实打实的客户,真金白银的天使。

    3、消费者喜欢新奇特,而企业更倾向于维持现状,让企业选择你的产品或服务,不仅仅是线下功能转到线上这么简单,另个角度说,客户推荐、口碑相传会比你呕心沥血的宣传页面更有用,这也是为什么平台愿意免费为行业标杆提供产品或服务,以树立示范作用。

    4、稍有规模的公司都希望产品能高度适配自己的内部流程与工作方式,而不是自己做出改变,包括你精心设计了FAQ或者视频教学,甚至上门培训。

    5、为你产品买单的,通常不是产品的直接使用者,这意味着采购阶段的目标用户≠使用阶段的目标用户,销售团队服务的人,与产品实际服务的人,可能对不上且这个概率很高。

    ……

    在运营问题上,细分真的是在所难免,特别是平台需要在业务上得到扩张,而不是限于生存。这套思路跟经典的波士顿矩阵是差不多的道理。

    举例,对客户细分

    随记与火花:

    1、从一件小事做起,可以增加商业价值、能够进行验证,同时又被忽略的点切入。

    2、借用一切机会宣讲自己的目标。保证团队内的人理解你要做的事情,大家的目标一致。

    3、相信自己的直觉。依靠直觉并不可怕,怕的是没有办法验证自己的直觉是否正确。

    4、一头扎进去,陷入自己方案,做自己认为正确的事情,很简单。但是能放一放,冷处理几天,回头问问自己为什么是这个方案,反而难很多,更难的是有勇气推翻自己、校正自己,甚至是很多人已经帮你评审过的方案。

    5、会议不是明星真人秀,能1分钟解决的事情不需要十几个人共同讨论,1人1分钟的总成本是惊人的;而对于能力不够的人,开多少场会都是一样的结果。

    相关文章

      网友评论

      • 简钻拾贝:尊重自己的工作 把他当做一回事 做好它 学习了谢谢
        叽歪黄油小面包:@y115 很多时候我在想,如果离开现在的岗位可以做什么?可见,「产品经理」真不是一个给人安全感的选择。

      本文标题:把事情做好,直到最后一刻

      本文链接:https://www.haomeiwen.com/subject/nultrxtx.html