产品经理,在小公司做产品的三两感悟

初来乍到,请多指教,今天,我会将产品设计流程、SaaS 产品和创业公司这 3 个元素结合起来,谈谈我的理解,希望能对你有所启发。

产品经理,在小公司做产品的三两感悟

在入行产品前,我对整个产品设计流程的理解是这样的:

产品经理,在小公司做产品的三两感悟

直到今天再来看这部分内容,可以说它的颗粒度细、流程明确,但只能作为一个大方向。

毕竟每个公司的模式不一样,每个类别的产品经理也不一样。

1、业务分析

要知道,我们常见的产品大多偏 C 端,产品经理可以通过共情来挖掘需求,所以会叫做「需求分析」。

而对于 SaaS 产品来说,我们需要的是理解企业已有的运作流程,梳理并提炼将结果映射到系统中,完成整个业务的闭环。

因此这里用「业务分析」作为开始更为贴切。

可不要小看了业务这两个字。

不能解决业务问题的 SaaS 产品,对对方没有任何价值。

因此,我们需要对业务时刻保持高度敏感。

01、梳理业务关系

SaaS 产品提供的是业务解决方案,是作为企业提效降本的工具。

因此产品经理需要先明确客户的问题,基于问题去制定方案。

从角色和工作流的角度思考,明确上下游关系、行为边界、利益关系等信息,做到先发散后收敛,最后做出产品决策。

02、评估需求的价值及优先级

我们都知道,需求价值分为「用户价值」和「商业价值」。

而对于 SaaS 产品来说,更应该关注的是「商业价值」。

做到每个功能都能解决对方的业务问题,才能够引导对方使用,从而才有签单的可能。

具体的评估和优先级排序的方式,我在文章《处理需求的几点建议》有详细说明。

03、是否需要需求筛选?

也许你会有疑问,需求筛选不是一定要做的吗?

对于 SaaS 产品来说,这个套路可能不适用。

这是因为对方提出的问题,一定客观存在于业务场景中。

他可能描述的不全,但不会不对。

产品经理要做的是挖掘其中的信息,找出共性并作出价值评估。

2、产品方案

在完成业务分析并明确地将问题转化为需求,并根据需求的价值排好优先级后,就可以将需求转化为可落地的解决方案。

这部分会涉及到如何在系统内实现,也会涉及到具体的产出。

从目前的流程上来说,分为这么几步。

(1)信息架构,先用脑图整理思路真的很关键;

(2)业务流程,我现在不纠结到底是先画原型,还是先出流程,总之怎么简单怎么来;

(3)界面布局,简单说就是画页面;

(4)逻辑说明,围绕业务流程,补齐产品逻辑;

(5)用户用例,模拟用户的操作路径,体验自己设计的交互是否合理;

从这里面,单独说说我认为要特别注意的。

01、业务流程

在创业公司里,prd 的形式大多都是原型图 + 备注,不仅产出速度快,而且开发看起来也方便。

我们要做的,是能将逻辑详细且明白地写清楚,最好配上流程图。

要知道,画流程图是一个很好的习惯,不仅能够帮助自己捋顺思路,而且对于开发和测试来说,接受度高且能够降低沟通成本。

而如果是复杂的功能逻辑,不光是流程图,有时还需要用举例的方式说明。

产品经理,在小公司做产品的三两感悟

02、交互与逻辑自查

通常我们在上传原型之前,都会检查一遍自己写的逻辑是否有问题,但毕竟我们很难做到不出现纰漏。

为了同一错误不犯第二遍,做一个「逻辑与交互自查表」就很有必要了。

写 PRD 的时候只需要照着落实到每个组件上,这会大大提高我们的工作效率。

产品经理,在小公司做产品的三两感悟

3、需求评审

接下来,就需要拿着你的方案组织开发过评审了,这也被戏称为产品经理批斗大会,我们通常会被问的怀疑人生。

01、组织评审

可以说在这一点,非常锻炼产品经理的沟通和组织能力。

首先我们需要提前告知技术 leader ,让每个开发都了解这次的更新点,最好附上业务背景和用户场景描述。

很多人都会忽略这一点,这会导致后面开发对方案的理解产生偏差。

然后就是提前收集问题,解决并达成一致,避免会上尴尬。

最后就是会上要做到控场,重点强调设计背景和逻辑决策的原因,团队要达成一致。

02、技术评估,定排期

很多创业公司,包括我所在的公司,产品经理不需要了解这些,我们等上线通知就好。

说实话,我们要有对产品的 leadership 和 ownership ,多去了解与技术相关的事情。

对产品经理来说,我们只需要了解技术的大致原理和实现方式,也就是有技术思维即可。

这样做的好处是在以后做版本迭代的时候,可以进行初步预估,做到心里有数。

4、功能开发

功能开发属于程序员的工作范畴了,毕竟产品经理能做的事情不多,但并不是说产品经理就无事可做了。

01、定期检查,保证彼此需求理解一致

每个人对于需求的理解都会存在偏差,这属于不可预知的问题,毕竟就算你写的再清楚,对方也有可能没有注意到。

那么作为产品经理,能做到的就是阶段性的与开发沟通,出现问题及时作出调整。

当然,有的时候就算你不去看、不去问,开发自己也会来问你,“这里你文档里没写到,要怎么处理?”

但要注意一点,不要让对方觉得你像是监工一样在催他,或者是打扰他的思路。

这个平衡点需要产品经理自己去探寻,毕竟每个程序员的脾气都不一样。

02、测试流程

产品经理作为设计方案的人,需要亲自参与功能测试。

不要怕,这里说的不是代码层面的测试,而是说功能流程上的测试。

通常来说只需要测试单独开个环境,App 开发人员打个包给你,你就可以做了。

无非就是在时间节点上,最好是在第一轮测试后,且 Bug 数量不多的情况下去做。

毕竟跑流程的过程中如果都是 Bug ,也是在浪费你的时间。

5、发布验证

一个功能上线了如果得不到验证,那么实际上是在做「实验室产品」,没有任何意义。

01、使用情况

这对于 SaaS 产品来说是最容易判断的,可以通过数据库、登录超级管理员账号等方式的查看,这些都可以办到。

对于 SaaS 产品来说,通常是对方不知道你上了这个功能,也就是说通知没有做到位。

当对方用起来并开始跟你抱怨的时候,不要怕,这很正常。

将注意力集中在挖掘对方不满意的原因上,不过通常来说可以分为这么几类。

(1)不可用,通常是业务闭环上出现了问题,需要反思在业务调研上面出现的问题;

(2)不易用,对于高频功能项,客户会希望能高效操作,所以步骤设计上要能少则少;

(3)不好用,往往会伴随着个性化要求,通常不会被提出来,但 SaaS 产品经理要做到理解;

02、有效反馈整合

除了使用情况之外,我们需要对客户进行分类,便于将对方的问题进行整合。

毕竟 SaaS 产品面向的是一群客户,我们需要优先做通用性方案,在此基础上满足客户的个性化需求。

6、产品运营

好的产品一定离不开运营,只有这样才能获得更多的问题反馈,而这些才是产品经理设计的源泉。

01、业务部门做推广试用

这里需要结合产品的定位,尽可能选择大企业作为推广目标,最好能够是标杆企业。

因为这类企业运作流程规范,可复制性强,之后做案例分析和推广的时候,也能当做素材。

毕竟对于 SaaS 产品来说,从头部复制到腰部容易,而反过来就相当难了。

02、不要骚扰客户

过度的接触客户,就会变成一种骚扰。

说一句自嘲的话,做 SaaS 产品的我们就是个卖软件的,你需要提供的是产品服务,而不要去期望对方要配合你打磨产品。

因此在向客户要反馈之前,准备好问题和重点,把握好时间,要让对方感受到重视的同时,但又不会觉得你烦,而你又能获得问题反馈。

写在最后

作为创业公司的产品经理,要做到每个节点都去参与,但需要做到有的放矢。

在这个过程中不断复盘,优化自己的执行习惯,提高自己的产品能力。

只有这样才能培养出我们对产品细微的体感,而这恰恰也是我们成长的源泉。

希望你我能在这个过程中不断精进,不断成长。

本文由 新媒体之家 作者:小木盒产品记 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
0

发表评论