复盘:如何从 0 到 1 落地一个互联网产品(下)

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

对于具有一定技术门槛,且业内暂无成功先例的工具型产品,市场具有一定可行性,且不说挑战性,本文复盘并分享,笔者是如何落地一个带有互联网属性的工具型产品的,作为对《复盘:如何从 0 到 1 落地一个互联网产品》的补充和完善。

01

工具,是产品在用户使用时会反映出一种属性,这种属性与用户的目的性和对结果的预期明确度直接挂钩。当用户的目的越强,对过程和结果的预期越明确时,产品反映出的工具属性就越强。

这里,笔者想分享 5 个概念,定位、互联网思维、产品思维、全局思维 和 结构化思维,在产品的落地过程中,贯穿始终。

1. 定位

定位,是一个营销概念。简而言之,即锁定细分市场,描绘受众画像,攻占受众心智,在其大脑中牢牢地打下一块革命根据地。

打法,可以借鉴里斯特劳特前辈的定位策略,“不是植入全新的、不一样的东西,而是操控已有的认知,将已有的关联认知重新进行组合。”比如:每当拜访长辈,“今年中秋不送礼,送礼,就送脑白金”。

对于工具型产品的产品定位,5W2H同样适用,即要做一个什么样的产品,给谁用,达到什么样的效果。

2. 互联网思维

互联网思维,即用户至上的思维,以用户需求为驱动,并更好地满足用户需求。工业思维更多是从设计者出发,提现更多的是技术和功能,而互联网思维则是从用户角度出发,无论产品技术如何厉害,只追求用户使用的方便和愉悦,(引自郝志中)。

比如:小米系列的产品,从产品的设计到推向市场,每一环节都有用户参与,参与并提供有价值的leads,还可获赠 F 码,享受优先购买的专属权利。

水能载舟,亦能覆舟,得用户者得天下,是有一定道理的。所以,在工具型产品的需求收集及分析环节,要与产品的最终使用者,做到充分的沟通,真正了解用户的需求,并全力满足用户的需求。

再如:CRM,核心的使用对象是销售,是“吸引并保持有经济价值的客户,驱逐并消除缺乏经济价值的客户”,在 ISO 9000族标准 2000 版对1994 版标准的重大改良是提出“以客户为关注焦点”。

3. 产品思维

产品思维,也可以叫做玩具思维,即在满足基本的功能需求外,赋予用户感官刺激、情感享受,满足其玩乐诉求的产品战略观,这里,笔者不再赘述。

4. 全局思维和结构化思维

全局思维和结构化思维,需要自己把控,这里笔者不做过多陈述,推荐读芭芭拉明托的金字塔原理。这里,笔者摘述一些基本概念。

基本结构:结论先行,以上统下,归类分组,逻辑递进。先重要后次要,先总结后具体,先框架后细节,先结论后原因,先结果后过程,先论点后论据。

具体做法:自上而下表达,自下而上思考,纵向总结概括,横向归类分组,讲故事,提炼思想精华。

02

Step 1:研究业内已有的业务流程

以DMS系统为例,其业务流程为:

  • 对于纸质类,档案归档——档案管理——档案入库(对于纸质类)——档案使用;
  • 对于电子类,电子文件产生——分散或集中存放——拷贝共享。

仍以地产行业的 CRM 为例:

先导期(纸媒/传媒/互联网,广而告之)——拓客期(小蜜蜂、全民经纪人、置业顾问等获取客户资源,并邀请至案场)——跟进期 (定时跟进客户,关注客户的购买意向,洗客)——销售期——业主管理。

再如保险行业:主顾开拓——约访——销售面谈——成交面谈 ——服务与转介绍——定期维护。

Step 2:业务调研,收集问题

根据已确定的业务流程,针对每一关节,准备问题,进行调研。

通常,这是一个相对比较辛苦的过程,需要浸泡在一线实际业务场景中,亲身体验,如果实际业务的开展中用到的有其他工具产品,那么,需要研究并掌握工具的基本使用方法,如此有助于发现痛点,形成思路闭环。具体不再详述。

Step 3:问题整理,分析痛点

以DMS 系统为例,通过调研,可以总结出 5 类问题,如下:

  1. 安全问题:丢失、泄密、越权、损坏等;
  2. 效率问题:找档案的时间比看档案的还多,想必大部分童鞋应该都有过此番经历,这里笔者不再举例实际的场景;
  3. 兼顾问题:电子和纸质档案的管理,比如:投标文书,通常是兼具电子和纸质版,参加招标——中标——签合同,相关的电子和纸质版资料,均会存档,为使电子版与纸质资料一一对应起来,这样在项目交付时,便可有迹可循;
  4. 协作问题:归档、借阅的过程存在障碍;
  5. 分散问题:电子或纸质档案越来越多,而且分散;比如:对于一家 Base 在城市 A,而在城市 B  城市 C 均设有 branch 的公司,就会存在文档分散的问题。

Step 4:针对痛点,确定定位,再借助产品思维,输出产品架构图

根据 Setp 3 的产出,将确定需要解决的痛点,转化为产品,即,转化为一种可以通过可视、可操作的功能的集合,解决痛点。接下来,对功能进行归类,形成功能模块,确定模块的定位,并划分层级。

这里,即是对全局思维和结构化思维的运用。在确定产品架构图的时候,也要对研发的实现方式有一定的认知,并且,要明白该产品需要与哪些已有且在使用的工具型产品进行数据层面的交互,这样有助于产出具有前瞻性的产品架构图,可参考下方DMS系统的产品架构图。

以 CRM 为例。

美国的Burghard 和 Galimi 教授认为:

“CRM是一个围绕客户需要和需求、重新设计企业及其业务流程的信息技术(IT)驱动的概念,它将一系列方法、软件及互联网接入能力同企业的以客户为核心的商业战略相结合,致力于利润、收益和客户满意度的提高。”

这里,分享下 CRM 的产品架构图,对于客户满意度的考量方式,业内有很多成熟的教科书式解决方案,这里笔者不做搬运工,请自行查阅。

图一

以 DMS 系统为例:针对调研已发现的问题,可以通过 DMS 从档案的采集、归档、整理、展现、使用到借用等方面进行一站式管理,进而实现档案资料的一体化、标准化、规范化和共享化管理。

这里,可以再加上统计相关的功能,方便查看某一时期,采集到的文档的数量,从哪里采集,采集到的文档的类型(.doc、.cad、.wmv 或者其他)等。

图二

Step 5:输出脑图

上一篇文章中,笔者分享,通过对接竞品售前、试用竞品的方式来输出脑图,但是,对于业内暂无成熟产品案例的工具型产品,就不能那么做了。

此时,在 Step 4 中,需要根据产品架构图,进行角色梳理,并加上信息流走向,再运用结构化思维,以上统下,逻辑递进,对功能模块进行细化,即要使该功能模块实现定位,需要哪些子功能模块或功能来进行支撑,逐一列举,如此,便形成了脑图。

如果不同角色对应各自独立的产品体系,则有几个角色,就需要出几张脑图。

以CRM中的置业顾问和销售经理为例:

CRM_地产行业_置业顾问(请关注脑图的颗粒度及形式,做到清晰即可)

CRM_地产行业_销售经理(请关注脑图的颗粒度及形式,做到清晰即可)

Step 6:画原型

该步,略。Practice makes perfect.

Step 7:补流程图

对于一款业内暂无成熟案例的产品,在完成 Step6 中的原型规划后,需要补一些核心的状态机图和功能流程图,便于在 Step 8 中,与大家沟通。

工具型产品的规划,需要一条能够根据业务流程将各功能模块串联起来的线(也即形成闭环),而这条线的业务模式设计,需要从核心受众的业务痛点出发来做规划,进而吸引核心受众,愿意使用产品,并从使用中获得快乐。

比如:笔者实战的项目,是通过状态机图的设计来完成闭环,出发点是解决一项笔者认为的核心痛点,在后来评审环节的头脑风暴中,得到了大家的认同,并集思广益进行了完善(Ps. 这张图不便分享,掌握状态机图的画法,根据实际业务场景,灵活贯通,即可)。

笔者认为:这里和电影剧情的策划,异曲同工,比如黄渤的一出好戏,有2条线,一条是故事主线一场灾难,一座荒岛,一群人,在一个全新的世界,重置生存规则,上演了一出好戏,还有一条线是马进与女一号的感情线,为影片增添了一丝柔和的色彩。

对于功能流程图,这里,笔者以 CRM 的一个痛点为例。

业务场景:

假使某案场有一客户 A ,属于置业顾问小组 G1 中的甲大锤。如果自添加之日起,15 天内,甲大锤没有以任何形式联系A(即没有维护跟进记录),则客户A的信息将流转给G1的甲大棍。

同样,如果15天内,甲大棍也没有以任何形式联系 A,则客户A的信息,将流转给 G1 的甲棒槌,如果甲棒槌也在15天内没有以任何形式联系A,则该客户的信息将流入公海。

解决办法:

以甲大锤、甲大棍和甲棒槌在 15 天内是否录入跟进信息为判断依据,根据一定的规则来对客户 A 的信息进行流转,最终流转至 公海。

相关的功能流程图如下:

Step 8:组织评审,头脑风暴

在大型的外包项目中,通常组织评审的是项目经理,组织评审是一项基本技能,提前告知各干系人时间、地点、时长和评审主题,将大家组织到一起即可,因情况而异,灵活把控,注意沟通技巧就好。

对于一款业内暂无成熟案例的工具型产品,头脑风暴是一个很重要的团队协作过程,尤其是需要核心调研对象参与,让其对解决方案进行审查,流程设计是否贴合其实际操作业务的模式,各关节的信息是否有遗漏。

根据实战情况,头脑风暴的过程一般很长,而且需要轮番作战,即一轮评审结束后,根据会议纪要,对原型和相关的 flow 图进行修改和完善,然后二轮评审,三轮评审… 直至大家达成共识,对解决方案均一致认可。

笔者推荐芭芭拉明托的金字塔原理,对于沟通效率的提升有帮助。

Step 9:输出需求规格说明书/PRD,确定里程碑,交付研发

Step 8 结束后,即可开始写需求规格说明书,直观高效,并补充相关的功能流程图、数据流图(笔者认为,以表格的形式,写清楚也可)和状态机图等。确定里程碑,交付研发,日常跟进即可。

Step 10:测试,验收,部署上线

知己不足而后进,望山远歧而前行。当接触到不同类型的产品到一定量后,即使是面对不曾涉足的领域的产品,也会触类旁通。

仅复盘分享,如有不到之处,请轻喷。

 

本文由 @白鸟 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
4人打赏
评论
欢迎留言讨论~!
  1. 不错!整个过程描述得很清晰,不过就是没啥可以落地的干货,sigh

    回复
    1. 这是一篇方法论,也有例证,落地的干货,挺多的呀。

      回复
    2. 谢。请问,你希望得到哪些落地的干货呢?:)
      ps. 本文所提及的项目,是性能测试领域的一个工具平台,偏技术层面,不方便讲,所以,文章是以之前的实战经历作为案例来展开的。

      回复