2

动态时局下如何做好工具产品

 1 year ago
source link: https://www.woshipm.com/pd/5735576.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

在如今的动态时局下,如何不受单个产品维度的局限,适应好不同的场景,做好过渡和承接呢?本文作者以工具产品为例,分析工具产品如何立足,希望能给你带来一些帮助。

vuEVqA4bcH8sAM5yePIG.png

近期很多朋友聊天交流时候提及如何拓展自己的产品领域,不受单个产品维度的局限,动态时局下适应好不同的场景,做好过渡和承接。这样在公司转型转方向时候仍然有一席之地,不至于被裁掉,可以处于一个比较舒服的状态。那确实,今天就以工具产品为例,来说一说工具产品怎么立足。

01 工具产品的职责和范围

一般而言,工具产品主要是对某一个工具平台负责,对工具的从0到1建设,从1到N的版本迭代负责。本文主要讨论的是B端工具,工具产品是大体的一个方向,通常也都是有固定的流程和机制所配合,在工具上实现某一流程的系统化,自动化,来达到规范的目标。

通常工具平台是有明确的场景和明确的目的性,解决一个特定的问题。工具的诞生主要是2大作用:1是商业化平台(俗称赚钱平台),2是降本增效(俗称提效工具)。

第1类在公司里有比较清晰的商业模式,咱们平台主要是实现确定的流程,引导用户怎么了解平台,怎么使用和怎么计算费用,只要用户顺利把流程走下来就可以拿到对应的收益。比如语音、视觉类算法服务的开放平台,就是算子包装成API服务,按QPS来收费。通常平台的易用性可用性是重要,但是更重要的是算法本身的能力,比如A公司的人脸识别效果和性能比B公司的好,但是A公司平台不如B公司的好用,那么用户大概率还是会选择A公司。

关键的决策点不在平台本身,而是平台背后的服务和能力。当然也可能涉及到实际的收费情况,每一个服务的成本。但是如果AB两家能力、价格相差不大,B公司的平台流程更顺畅,平台售后服务更佳,那B公司是有优势的。

第2类主要是公司内员工提效工具,在固有流程上简化人力,让平台代替人做了重复工作,并进行自动化流转,比如审批流、搭建活动网页、调用某个通用服务。这类工具做起来界限比较不明确,最基本的是走完一遍流程即可,量化收益主要是根据节省人力PD,节省机器成本、电力成本、GPU卡来衡量到金额,为公司也省下一笔费用,提升效率。

这类衡量工具好坏的标准也多样化,不同场景工具指标不一,也看响应速度。整体对工具的满意度会从NPS(净推荐值)来看。

提效工具其实严格来说也有公式,是相当于Value= 无工具状态的平均总成本-工具产研开发成本-完成工具后的平均总成本,如果仍然大于0,那就是达到预期的。比如一年花在原有流程的人力100PD,改进后流程的人力是40PD,设计开发工具是20PD,那结余40PD就是真正拿到的收益。机器成本也是诸如此类折合计算。

所以工具产品还是比较稳妥的,职业发展路径也比较清晰。那么什么时候危险呢?就是在整个业务线没有了,在流程都不需要的时候,那平台也有点鸡肋了。第2类工具产品也在往第1类去转型了,因为疫情当下的卷心菜时代,增加收入是第一要素。

02 搜索领域的工具产品挑战

比如原来做AI工具的方向因为公司转型被派到搜索流量领域,那就直接得去做更普适化的工具平台了。如果一旦到业务场景驱动的工具平台,那产品的重要技能点就变成理解业务,结合业务流程和用户体验问题进行建设优化了。和原来AI平台需要一定的技术理解,算法策略的思维完全不同了。

拿搜索来说,一般公司的搜索业务都是流量入口,做流量变现,很常用的一个工具就是广告位申请审批平台。那么搜索这里有多少个资源位(广告位),每个可以开放多少个位置,怎么控制频率,不同位置的量化价值是什么样的,怎么计费,怎么衡量效果。前期这些业务调研都是必经之路,对于新开始的平台最好的方法就是对标。

工具产品的介入调研,可以从类似领域的类似平台进行入手,如果有公开的数据可以加以参照,特别是大的流程机制可以借鉴,保证稳妥。以及衡量不同广告资源位的价值,对比多个平台相对来说有一定标准的,其实可以直接拿来用,结合当下公司的情况稍作调整。

如果是习惯做B端平台的产品同学,会在确定的问题上有明确的答案,可以定向优化和迭代。但是对于搜索场景的B端流程,可能要结合C端的体验和功能性进行及时调整,相对来说即使是做B端平台也不会那么确定。如果有对应的C端产品跟你对接,那还能省一部分工夫,如果缺少这个角色,只有运营同学对接,那显然还需要把C端这里链路补全想清楚,那就工作难度进一步增加。

但是对于本身的工具产品,沿用B端的方法论还是有一席之地的。

1)把需求点收集,进行归纳分类,哪些是解决可用不可用问题,哪些是体验易用性问题。

2)根据业务流程重要度,把功能进行拆分依赖关系,哪些一期得先做打地基。

3)如何衡量这些功能建设后的价值,从0到1的作用量化,可以根据指标监控。

当然节奏也需要根据业务紧迫度,资源稀缺性进行调整。

03 淡定对待变化,时刻做好准备

当然了,在互联网公司变化莫测的当下,多做些准备还是多多益善的。我们需要积极面对领域的变换,产品岗位的调整,业务的变动,我们也可以把原有岗位的亮点进行继承,迁移到新领域中。

互联网号召“拥抱变化”,也流传着“唯一的不变就是变化”这样的俗语。的确高收益也伴随着高压力高风险,在时局变化时候多一些信息的互通,多一些技能的尝试,未尝不是一件好事。

B端产品从大趋势来看是很有市场竞争力,很有方法沉淀和可复制性的。只是在公司领域波动时候会更宽泛,涉及调整,但也不用慌。只要耐得住性子,坚持把B端产品做踏实,兼顾新知识点的吸收,后面的路一定会越来越广。祝福在互联网各自领域耕耘的彼此,会见证更好的时代,更多元的未来。

作者:一丁,“数据人创作者联盟”成员。

本文由@一个数据人的自留地 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK