起点学院课程

从0到1搭建B端产品,我的总结与体会

10 评论 2.8万 浏览 281 收藏 15 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

本人作为一枚初入产品领域的小白,在加入公司后,有幸参与了一个从0到1的项目(B端工单系统,涉及微信H5及PC管理后台),短短几个月时间,对如何做产品有了一点自己的想法以及理解。

本文重点描述产品从需求收集到上线过程中注意事项,如何避免踩坑类似的经验总结,以下内容以B端产品为例,献给同样是小白的你。

了解项目,熟悉业务流程及背景

当你接手了一个项目时,先不要去着急了解这个产品的功能,它的用户体验好不好。首先最重要的是了解这个产品属于B端产品还是C端产品,它的受众人群是广大C端用户还是合作公司?因为二者的本质还是有比较大的差别。

使用B端产品的用户,希望通过这款产品可以将自己内部管理混乱的流程标准化,最最重要的就是可以提高人效,为了提高人效也许不会那么注重用户体验,更不会有一些很炫酷的交互,正如张小龙大神所说的:用完即走。因为作为B端产品不需要对用户增加什么粘性。

其次需要熟悉为什么要有这个产品,打造这个产品的初衷是什么?为了解决当时的什么问题?有和没有这个产品对实际业务有什么影响?提高人效是否可以量化(如:没这个产品办一件事需要1小时,有了这个产品后,办相同的事只需要1分钟。)?整个产品的未来规划是什么?尤其是B端产品,要紧跟公司的战略发展,必须熟悉了解公司当前的战略发展是什么,最重要的战略合作伙伴有哪些,这个产品在公司战略发展中起到什么样的地位。

相信对这个产品有了以上的了解后,在日后的产品需求优先级的判断,及产品设计中会更游刃有余。

需求收集

通过对以上内容对产品的历史及未来有了一定的了解后,接下来就要进入整个产品的初始阶段:收集需求。既然是一款紧随公司战略发展的B端产品,那么高优需求一定是来自业务部门以及相关战略合作公司。

首先收集最高优紧急的需求,也就是与当前公司战略发展最密切相关的,根据关键需求梳理mvp主流程,同时产出流程图。然后确认该流程图中所涉及的角色有哪些,每个角色应该有哪些最基本的功能,才能使整个流程不阻塞,走的通。

有些B端产品不仅涉及到公司内部的多个部门,还涉及到公司战略发展的合作伙伴,这时你就会发现每个部门或合作公司,都会对这个产品都会提一些自己的需求。

这时最重要的两个问题出现了:

1、需求提交流程规范化。

当有很多部门或合作公司同时对你所负责的产品提需求时,作为PM,我们是需求的收集方,同时也是需求的过滤方,更是善于梳理流程的专业户。可以让每个部门选出一个负责收集该产品需求的负责人,每个部门人员的需求统一提交至需求负责人处;同时,每个部门的需求负责人,再选出一个总的需求负责人,由总的需求负责人收集所有部门负责人的需求,同时过滤掉一些提交重复的需求,最后以正式的形式(邮件)交至pm手中。接到需求后,pm线下和各部门需求提交人积极沟通,了解需求背后的逻辑,需求产生的原因,自己再过滤一些伪需求。

2、需求优先级判断要明确。

当非常多的需求到pm手中后,不可能所有需求都在一个版本做完,就算pm产品设计能做得完,但是也得问问天天加班加点的程序员哥哥愿不愿意啊。所以,要制定重要的需求优先级排序,明确下一个版本要达成什么目标,需要什么功能,在不影响大版本发版的情况下,可以对哪些小的功能进行优化。明确了需求优先级后,便可以进入到下一个环节— 产品设计。

通过以上行为收集了需求,并且明确了需求的优先级,对下一个版本的迭代目标有了更深的理解之外后,再补充一下需求收集中,尤其是迭代目标需要注意的几个重点,避免踩坑:

  • 无论任何需求传递到PM手中,都要与提这个需求的人直接沟通,而不是层层传递,拒绝接收二手需求。(如:运营中心市场部门员工A提交需求至本部门需求负责人B手中,B再将需求汇总传递至运营中心总需求负责人C手中,C将需求传递至pm,pm需要对需求进行核实了解,应直接找到A,而不是B或C。)
  • 当PM收集了很多需求后,自然要结合公司发展战略,总结出下一个版本需迭代的高优需求。既然是公司战略层面的问题,自然少不了开会。每次开会,会议的决策人最好在场,避免以后将本次会上的所达成的结论推翻。需求高优不高优,有时就是老板一句话的事儿。并且在会议结束后,要将会议纪要同步所有相关人员,做到信息一致。

产品设计

Axure是PM吃饭的家伙,你可以不会PS,不会编程,但是Axure你必须得会。我非常享受画产品原型的时候。因为这个时候,才是PM真正发挥创造力的时候。此阶段最重要的两个产物是产品原型和prd文档,产品原型决定了你的产品长什么样,而prd文档决定了你的产品规则逻辑。

作为产品小白,刚开始画产品原型的时候,面对一大片空白区域,真的不知如何下手,这一点我深有体会、此时不妨去看看别的产品是怎么做的,竞品也好,还是当今最流行的产品也罢,真的会帮助你少踩不少坑,最好多看几款产品,取其精华去其糟粕。

作为一款B端产品,要本着提高人效的心态去完成这款产品,似乎不需要多么炫酷的交互。因为这个产品的用户是上来工作的,不会因为你一个超炫的视觉效果而爱上这个产品,从而多加加班。但是最基本的交互是必须要的,如什么时候用浮层,什么时候用弹窗,什么时候打开一个新页面,筛选是用下拉还是点击,完成一件事的操作流程是否足够简洁等等。

界面样式,只是这个产品的表现形式,应该对任何一个细小的功能有更多的联想。例如一个工单列表页,涉及到很多信息:工单提交人、工单实施人、提交工单时间、工单状态、工单完成时间、工单所在地、工单名称等等等等。这里就涉及到信息展示的问题,要联想到谁会用到这个页面?可能是管理者要登录后台看自己公司的工单信息,那么他希望看到什么?可能要看看自己哪个员工又签单了,什么时候签的单,工单的进展如何了,并且看到这些信息之后有什么样的操作?可能要对已完成的工单操作一下服务成功,或者把某一个进展不顺利的单重新分配给自己其他员工,他希望的达到怎样的效果?所以要对如此多的信息进行筛选,列出操作此功能的人最关心的信息,将其不关心的信息弱化,或者在工单详情页去展示,并且配上可能出现的场景操作。

在产品设计中,一定要注意产品设计的细节,任何细节都不可想当然。因为研发会根据你所有的需求描述去实现产品,可能会因为一个小细节的变动,牵一发而多全身,有时只是PM的一句话,但是却是研发工作的一整天。

PRD文档的书写要细心,尽量要多考虑产品的边界值,如:设置密码,密码的长度控制在多少位,是否需要特殊符号,大小写是否有区分,对输入不规范的报错形式是怎样,文案怎么写能让用户知道自己输错了等等。一些技术难题,可以抛给研发去处理,但是对于产品需求,一定要自己去构思完成。

产品开发

终于到了将自己的构思实现出来的重要一步,交付研发。其中自然少不了评(si)审(bi),我们现阶段的产品评审流程为:组内评审—设计评审—和业务部门评审—研发评审—项目启动。

如果想着研发哥哥会按照自己的产品原型和需求文档,任劳任怨的实现出来,那你就大错特错了。正式启动研发后,还会发现之前评审没有发现的种种问题。项目正式启动研发后,有以下几点总结:

  • 每天最好以站会的形式和大家同步彼此的工作进展,因为有些研发会有多项目并行的情况,如果有影响上线时间的情况出现,那么也好做出调整,而不是后知后觉。
  • 需求和研发成本如何取舍,根据当前项目紧迫程度做好评估。如某一个需求,研发成本比较高,那此时需判断此需求是否影响主流程,是否属于MVP功能,如果会影响主流程,非做不可,但是做了会影响上线时间,那么就要及时协调研发资源,如果又没有多余的研发资源可供协调,那么就要考虑变更需求或听取研发的其他建议了。如果不是影响主流程的需求,那么就要根据当前项目紧迫程度做好评估,是否可以将此需求延迟至下一个版本。
  • 如有延期上线风险,合理调动研发资源。
  • 尽量考虑周全所能遇到的场景,以便研发设计技术框架。
  • 我所用到的项目管理工具是jira,会在每一次的项目启动后建立相关的用户故事和任务,任务分配给各自负责的研发就好,用户故事可以存放原型和prd文档。

测试环节

辛苦的程序猿哥哥通过加班加点的写代码,终于通过了联调,将自己的代码部署到了测试环境,那么就该测试和pm上场了。

测试评审尽量叫上相关研发人员,可以作为产品实现是否正确的二次确认。并且评审要细致,将各个功能的不同操作所导致的结果考虑情况全面,归根结底还是prd文档要书写全面,因为测试同学会根据prd文档来写测试case。没错,一切都是产品的锅。

每一次新版本的迭代,不仅要测试新增加的功能是否有bug,还是测试产品的主流程是否受到本次迭代的影响。

关于bug,我认为两种非常紧急且重要:

  1. 阻塞性bug
  2. 影响业务的bug

阻塞性的bug自然不用多说,例如你用微信聊天,信息发不出去;用携程买机票,没法儿出票。而影响业务的bug是指,用携程买机票,本来机票1000块,但是用户1块就买到了,这个bug不属于阻塞性,但是却影响重大。

产品上线

我们产品上线的流程为:研发提交上线申请 — 测试回复测试通过并且展示bug处理情况—产品验证是否通过—产品上线—产品发release邮件周知老板们及项目成员。

产品上线意味着两件事:

  1. 可以进入到下一个版本迭代的工作当中了。
  2. 对本次上线的产品功能负责。

在此主要整理一下产品上线后的注意事项:

  • 尤其是一款B端产品,一定要在产品上线前几天,对公司内部用到该产品的所有部门进行相关培训,并且编写产品功能使用手册及时同步大家。
  • 线上回归测试,收集bug,严重bug紧急修复;影响不大的bug可以考虑到下一个版本迭代修复。
  • 收集用户的使用反馈,对体验不好的功能进行优化。
  • 数据监测,最好通过线上数据,可以给业务部门一些指导性的建议。

我每天都会自己写日报,记录项目的的进展,以及某些会议达成的重要结论。并且也会记录自己在工作中认为重要的产品体会,每天没事儿看一看,相信看的多了会有更深的领悟。

 

本文由 @不过我喜欢 原创发布于人人都是产品经理。未经许可,禁止转载

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 一个正在找pm实习的应届生看了,表示很清晰,很棒!!! To C和To B都蛮适合的

    回复
  2. 写的很好,逻辑清晰!

    回复
  3. 加油少年

    回复
  4. 感谢分享,同是产品小白一枚,目前也正在做B端产品经理,希望可以看到你更多的分享哦

    回复
    1. 你们口中的产品经理是几年工作经验?

      回复
  5. 新人受教了

    回复
  6. 哈哈,和我们现在工作的流程一样

    回复
  7. 不错不错!希望作者多分享此类文章!顶作者!

    回复
  8. 基本上产品经理涉及到的工作都写清楚了,这样梳理下真的很清楚 :mrgreen:

    回复
    1. 非常不错!!仰视

      回复