B端产品经理是一种什么样的存在?

 产品系列     |      2019-03-20 04:26

  什么是B端产品?B端产品经理是什么样的一个职位?应该具备什么样的技能呢?本文将从:“如何定义B端产品”、“产品各阶段的方法总结”,以及“产品经理所具备的产品力”三个方面来向大家详细介绍B端产品经理与B端产品。

  (投稿说明:文章第一部分和第二部分,总结整理自李宽:《B端产品经理必修课——从业务逻辑到产品构建全攻略》,第三部分是自己所写。文章投稿至人人都是产品经理,获得了作者李宽本人的授权认可。)

  作为一名产品汪,说来惭愧,接触过的产品书籍不多,而且大部分只是简单翻过。称得上整体翻看下来的,更是屈指可数,比如:

  这些书籍都在我的不同阶段,给过我不同程度的启发和指导。但因为我一直做的to B的产品,在我的当前阶段,感觉共鸣最多、解决了我许多疑惑、期待继续深入挖掘的,要属这本:

  怀揣着“将作者的产品干货学为己用”的初心,这份笔记心得,努力呈现书中20%的精益思想。相信你可以在这里,找到你想知道的B端产品经理那些事儿。

  B端产品可以为公司的管理服务,如:HR系统、OA系统;也可以为公司的运营服务,如:供应链系统、ERP系统的。

  不论哪种,其终局都是为企业流程效率服务,让分散的、低效的个体,更好地连接合作,发挥集成化的、系统化的更大作用。

  相较于C端产品,B端产品最大的特点是:面向特定领域用户,且数量少得多,但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强,与业务的结合更紧密。

  B端产品经理重点关注:如何解决业务痛点?在业务逻辑的基础上,如何调度各类角色,提升各角色的工作效率、以及互相配合的流畅度?

  正因为如此,做好B端产品经理的基础是:需要极其熟悉所属业务,否则工作容易浮于表面,甚至无从下手。

  要掌握的技能虽多,但不是每一种都需精通,可借鉴“二八原则”:真正重要的知识,或者在实践中被反复使用的知识,只占全部知识的20%。也就是说,20%的知识是需要反复修炼形成骨架的,剩下的80%在此基础上不断更新迭代。

  总的来讲,在我看来,产品的核心能力是:能抓住问题本质,可提出合理解决方案,并将之执行落地的能力。

  一般产品经理的职业发展路径这张表可以作为产品对自己当前阶段的参照比对,也可以作为迈向下一阶段的方向指引。

  产品经理的职业成功之路,是成为某个领域的产品专家,而做B端产品经理是一条成功率极高的路。

  因为进入某一领域做B端产品经理,需要具备某一领域的行业知识——即有入门槛。因此,B端产经理的职业发展容易形成护城河,更易成为某一行业的B端产品专家。

  通过试用渠道体验竞品。拓宽搜索渠道:百度、谷歌是首选,知乎、简书找文章思路,知网、万方找专业信息。

  竞品分析报告,应包括:行业发展状况,“有哪些竞品?”,竞品使用者和特性的描述,自己的产品与竞品之间的比较,通过分析得到的结论和信息等。

  商业需求文档,应包括:产品创意产生的背景、产品或解决方案介绍、产品规划、产品成本、产品收益、产品风险等。

  发现问题:你正在做什么申请?做的过程中有什么不舒服的地方吗?遇到了什么问题?

  探索机会:为了更好地解决这个问题,你认为有什么办法能帮到你?或者哪些地方可以优化一下?

  痛点:好的需求犹如根治用户痛处的良药。B端产品通过调研用户基本可提炼出痛点。

  明确、可行、简单的第一步:挖掘需求就是降低需求中的含混性,使之明确。如果在需求落地成型阶段才发现含混性,这个时候的改正成本实在是太高了。

  探索需求的重要方式是以数据驱动的思路去探索业务。因为行为产生数据,数据联系(指导)行为。比如:用户下单产生订单(数据),订单传递给库房的生成人员指导他们发货。

  识别干系人和角色:产品要与需求干系人和角色紧密合作,找到正确的人,非常关键。解决的办法就是了解所在公司及团队的组织架构。

  需求管理的模式:通过“化散乱为规律,化应急为预测”,破解那些被打上“越快越好”标签的需求。

  需求收集时间的把控:需求收集的开始时间和结束时间有一定原则性。产品经理要使用各种方法影响需求人,让他们不要赶在临近结束时间时提交需求。比如在结束时间前5天发提醒邮件。

  需求的重要性:为了区分同一优先级的多个需求,可以用重要性来辅助优先级管理需求。

  重要性就是对需求进行打分,分数范围是1—100分(根据5个优先级可以分成5等分),每个需求的分数是唯一的。优先做分数大的需求。

  优先级和重要性一旦确定,所有的资源将向这些需求倾斜。处理跨部门的需求时,使用优先级尤为重要,但重要性的分数不能跨部门比较。

  组织信息:最简单处理信息的思路就是根据时间、字母、数字等内容,对信息进行组织分类。B端产品经理要注意把实际业务中,已经存在的信息组织结构,如:现有组织架构、单据分类等,在系统中映射出来,满足用户的预计和操作习惯。

  给信息加标签:给信息加标签(取名),便于快速查询。注意取名需让用户易于理解。

  设置找到信息的路径:即设计导航,B端产品大多是工具型产品,三级菜单一般足够。

  搜索信息:B端产品的搜索场景中,精确搜索场景较多,因此,B端产品经理更多关注的是数据的结构。

  描述信息的特征:B端产品经理在设计产品方案时,要关注数据对象的属性,即元数据。比如:学生的元数据包括姓名、生日、成绩、学号等。因不同的角色由于工作需要对元数据的定义不同。对元数据的理解不同会影响报表和展示信息的设计。

  这四种页面类型,是基于用户行为而设计的的通用化的解决方案。依据这些页面类型提供的解决方案,基本能够结构化地组织信息,为用户提供可预期的操作。研究透彻并熟练掌握这四种页面,也可以更方便地产出原型。

  模式,是指:可以重复使用的方式和方法。这个概念源自《建筑模式语言》,它就像乐高积木一样,总结出了253种建筑模式。像乐高积木基础模块,,组合成为满足人们某一功能的建筑空间,比如厨房空间设计模式:

  厨房空间由四个部分组成:炉灶、水槽、事物存储区、操作台,以上四个部分的间距在3m以内。其中,操作台的范围大致在1.2-3.6m。

  厨房要满足人们做饭、储藏、清洗的活动。产品经理设计的每一个页面,也像设计厨房空间一样,要再一个页面上满足用户多种活动的需求,比如:信息的查看、搜索、下载等。

  每种活动都对应着一个解决方案,这个解决方案就是模式,而多种模式搭建在一起就是页面。

  高精度:详细展示原型中各个组件在不同操作下所展示的信息。(结构化输出文档)

  需求方把业务语言翻译成需求(需求文档),产品将需求转化为可以产品解决方案,转化为让设计师和研发工程师可执行的方案(产品需求文档)。

  当然,如果需求是业务逻辑的修改,不涉及界面操作,这时的需求文档其实等价于产品需求文档。

  产品需求文档包含的内容:需求、背景、目标、目标和收益、需求范围、功能需求、业务概念、流程展示、需求描述、产品需求说明、网站地图、产品原型。

  当然,并非所有需求都需包含以上元素。产品需求文档和原型的表述原则是一样的,不管产品需求文档以什么形式表现,只要能够清晰表达设计思路、便于沟通就是好文档。

  系统状态可见:用户能够随时获得产品反馈的信息,会让用户产生对产品的信任和安全感。

  一致性和标准化:让界面元素和操作形成一套让用户可识别、可学习的标准,并且在产品的任何地方都可以应用。

  帮助用户识别、诊断和解决错误:着重关注给用户反馈的操作信息,且尽可能以友善的态度表达。

  帮助和文档:需要在界面上提供必要的使用帮助,并整理出专门的产品使用文档帮助用户学习。

  主动学习设计知识,如:常逛逛Dribble、优设、站酷之类的设计网站,提高自己对设计的认知。同时,了解公司或团队的设计规范。

  明确指出设计重点,表达顺序。明确页面中重点功能是什么,使用者在什么场景下使用,以及希望用户重点使用的界面组件和信息有哪些。

  给出设计案例。可以找一些比较好的设计案例给设计师参考,指出案例中哪些元素可以参考。

  在研发阶段,产品经理需要承担起项目管理的义务,协助研发和测试同事,以推进产品开发。

  原则:不论采用何种手段,邮件、微信、电话、面谈,信息的发出方一定要保证接收方能够收到并且理解信息,做出反馈。

  产品经理可以将项目过程遇到的问题及处理方法、人员配合方式、项目流程等经验或文档分享给其他项目成员,推而广之,达成大家的共识。

  标准化可以避免项目再次陷入相同的错误中。沿用成功的工作方法、经验,让项目不断被顺利推进。

  而在研发日常跟进中,可以采用看板模式来记录和跟进。看板管理需要注意的就是:避免某个阶段的需求出现拥堵,或者是一旦发现拥堵,要及时疏解。

  产品上线时间是否合适。产品上线的时间点是否会影响其他业务操作,是否需要配合整体的运营计划。

  产品推广产品,可运用营销推广模型的核心思路:描述一个重要的问题,并让大家认同,之后介绍产品给出的解决方案。

  背景介绍:介绍所发布产品的背景信息,比如:时间、地点、任务、事件等信息,便于大家了解背景知识,从而减少认知负担。

  描述阻碍:描述用户目前会遇到的问题,并让大家认同该问题确实会给自己带来不便。

  点燃希望:向大家说明这个问题有解决方案,引起打击的期待和注意。产品经理客户可以介绍这个问题的解决方案,及概念或者同行业对这个问题的解决思路。

  展现价值:描述这样的解决方案和产品会给用户带来怎样的价值和收益,可以配数字,这样会更有说服力。

  给出诱惑:给大家送一些福利,让大家快来体验产品。这里可以根据实际情况来选择使用。

  发布一款产品或者介绍一个功能并不都需要发布会的形式,产品经理可以应用简单有效的演讲框架快速打动用户。

  数据监控应该监控什么才有意义,从黑箱、仪表盘和二律背反理论中我们可以得到一些启发。

  我们只能输入和输出,而并不知道事物真正运行的原理是什么,比如:电商网站的输入是用户进站浏览,输出是订单。那用户在浏览网页所做的行为和决策就是黑箱。

  通过汽车的仪表盘速度、耗油量等数据指标,随时反馈出汽车的状态。没有仪表盘的汽车随时都有失控的危险。对系统运行状态的监控也是,数据指标要尽可能覆盖全面,比如:出现问题的次数、加载时间、业务相关数据等。

  二律背反指规律中的矛盾,在互相联系的两种力量的运动规律之间存在的相互排斥现象——即两种事物此消彼长、此长彼消、相背相反。

  因此,我们除了关注数据指标之间的相关性,更需要找到这些处在二律背反的指标,然后进行指标配对。通过指标配对,防止过度监控或者提升一个指标而带来副作用,用另一个指标来辅助分析和监控,从而权衡出好的办法以解决问题。

  SQL可能是最容易入门的编程语言。因为他书写出来的代码,完全是按照英语语法,是初中语法中最简单的部分。只要学习非常少的SQL知识,或者说是几个英语单词,就可以快速在工作中使用。

  《SQL基础教程》,这本书内容实用且基础,适合零基础的人学习,且它描绘了很多使用场景。

  学习编程的网站,如,这里的教学内容简约便捷,可以当成SQL使用的工具字典

  纵观《B端产品经理必修课——从业务逻辑到产品构建全攻略》,会发现书里满满都是干货,作者产品力MAX。

  硬技能包括:用户调研、产品规划、需求分析与管理、产品方案设计、数据分析等。

  但在我看来,作者产品力真正的厉害之处在于:任何时候,你有问题,我有方案,而且是快速产出的、高品质的、切中要害的。

  拿本书作为产品来举例:作者可以被视为产品经理,读者可以被视为用户。书中内容几乎覆盖了B端产品经理工作场景、工作内容、工作方法、工作规划等读者可能有疑惑的方方面面,在每个层面,作者都给出了非常恰当、贴合实际的指导理论,也就是给读者提供了解决问题的工具。

  不难理解,在产品工作中,或是在其他工作中,这种迁移能力才是真正发挥作用的能力。

  因为B端产品经理的知识没有成型理论和体系,所以,作者立志填补这项空白。期望自己的总结和思考,为中国产品经理职业发展提供理论和实践的支持。

  为了写书,查阅大量现有的互联网、经管类书籍,还有大量的软件工程类书籍,以及学术论文。

  本书展示了作者对B端产品经理的理解,介绍了B端产品经理的工作流程、工作方法、工作场景,以及作者在工作中的经验总结。

  喜欢跟研发同事散步聊产品和设计,在无拘无束的畅谈中总结自己对产品的看法和观点。

  持续学习,知识内化,不断总结和输出。工作实践不断总结成经验和方法,形成自己的理论体系,揉碎成通俗易懂的生活例子阐释。

  相信这些品质不单只对B端产品经理,对所有职场中的伙伴,都是有益的启发,都可以借鉴成为我们不断提升的路径。

  最后,我想说:这篇文章可以成为B端产品经理工作的简版操作说明,遇到问题时可随时翻阅。当然,如需进一步拓展和了解,请看作者原著。