惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
博客园 - 司徒正美
博客园 - 三生石上(FineUI控件)
博客园_首页
IT之家
IT之家
The Cloudflare Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
酷 壳 – CoolShell
酷 壳 – CoolShell
爱范儿
爱范儿
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Y
Y Combinator Blog
A
About on SuperTechFans
Microsoft Azure Blog
Microsoft Azure Blog
美团技术团队
S
SegmentFault 最新的问题
T
Tailwind CSS Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
M
MIT News - Artificial intelligence
WordPress大学
WordPress大学
B
Blog RSS Feed
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园 - 【当耐特】
小众软件
小众软件
有赞技术团队
有赞技术团队

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
【摹客RP测评大赛优秀作品】精一技or擅百技?——协同时代下的...
雨灰 · 2022-09-19 · via 人人都是产品经理

#本文为2022摹客RP原型工具测评大赛优秀奖作品

当前时代下,原型工具的竞争日益激烈,各大品牌也从中找到自己的擅长打法脱颖而出。那么在协同时代下,如何才能够降本增效提高自己的命中率?作者以摹客RP作为体验对象,将精一技还是擅百技作为话题切入点展开分析,企业该如何选择,这是一个需要考虑的问题。

写在前面

大家对原型工具应该不陌生,无论是设计师还是产品经理,或多或少都接触过原型图的工具,比如较为大众熟知的Axure,国内运用较为广泛的墨刀和摹客,以及一些较为小众的产品。不难发现,大多数工具类产品的运作模式几乎都如出一辙:先免费使用一段时间,养成了用户认知和习惯后,逐步开始投放广告或者收取费用变向商业化——原型工具产品自然也脱离不了这种运作模式。

所以在这个内卷时代下,各大原型工具相继脱颖而出,前段时间体验了一下摹客RP,这次就结合摹客RP这款原型工具产品来聊聊:内卷时代下工具到底应该怎么做?

一、精一技or擅百技?

要说怎么做一款产品,首先先确立这款产品的定位和方向,如果定位和方向上不对,自然后续铺垫的功能还是需求都是在错误的事情上继续做错误的事情,相信这是每一个产品人都不愿看到的。

但往往理想很丰满,现实却很骨感:结合自己的从业经历,很多时候产品定位和方向是很难先做到清晰,然后才开始铺设功能的;一般情况都是跟从竞品功能,快速拿到结果,才开始结合自身业务特效慢慢摸索产品定位和方向的。

众所周知,作为B端属性的工具类产品,最为重要的无非就两点:降本和增效,这两点向来是B端尤其是偏工具类产品的核心目标;那么如何降本和增效呢?有人说降低操作成本啊,降低认知成本啊,降低学习成本啊,那到底降的是什么本?增效又是增的什么效?

从上图可以看出,无论是降人力成本、认知成本等等,还是增加学习效率、体验效率等等,所有对象都指向了用户群体。有人就会问了:你这不是废话嘛,工具不就是给用户用的嘛?诶~还真不一样!用户群虽然特指一个群体,但是隶属不同目标下,自然而然也有类别区分。

为什么这样说,因为不同的用户群有不同的功能诉求;用户A通过产品想达成目标A,用户B通过产品想达成目标B,那么用户A和用户B从根本的目标不相同,那么他俩的体验路径和信息传达也是需要有不同的区分的,简单来说就是用户达成的目标不同,想看到的页面和功能也不相同。

把工具产品比喻成一个小中台来说,所有用户都是中台的需求方,不同需求方的目的不同,但是作为小中台来说都是需要同时满足的。以摹客RP来举例,作为一款协作产品,用户群可大致分为产品经理、UE设计师、研发等,而针对不同的用户群目标来看,产品经理的核心目标是快速通过原型具像化产品功能,而UE设计师则是通过产品经理的思想以图形化的形式表达出来,而身为研发的核心目标是快速了解业务逻辑,以便构思开发结构。

二、擅百技?

综上所述来看,无非就是针对不同的用户群体的需求都满足嘛,我都把功能给你做上去不就好啦?表面上的确满足了所有用户群的需求,可事实上无形将各类的成本分摊给了各个用户,怎么理解呢?大家可以脑补想象自己作为一名维修工,此时你急需把一颗梅花口的螺丝给取出来,这时候你来到工具间,你最希望看到下图中哪个场景?

毋庸置疑大家肯定都会选择右边那个工具间,因为功能排列整齐有序,不管你维修工是水电维修还是建筑维修还是网络维修,都能在这个工具间找你能帮你完成你的目标。这便是所谓的擅百技——基于用户群的需求全部将功能一一实现。

还是以摹客RP举例,当不同用户群进入平台,功能排列整齐有序,都有足够的区域和节点帮助用户群实现各自的目标,产品经理能通过组件库、模板等快速输出原型图,UE设计师则能通过多样的图形、动效等实现高保真交互稿,团队方面则有快捷拉起会议、在线留言等功能;所谓是将目前市面上几乎所有原型工具功能,结合自身的发展沉淀做出的平台

可是,擅百技就足够了么?换句话说,当你在找梅花口的的起子时,你会希望看到平口起子在眼前对你进行干扰吗?

三、精一技?

既然你说擅百技不好,那么接下来你是不是以为我会走极端,那就只针对产品经理做一款原型工具精一技不就好了?大漏特漏!虽说术业有专攻,互联网时代咱们包容性广,咱不走极端,在每个用户群的功能需求上更聚焦精细化不就行了,精一技不够,咱们就精百技,每一个功能打磨透透的,卷到极致这样够不够了?

这样做OK,内卷时代下大家都是这样做的,但是会带来一个新的问题:在多维全局视角下,体验成本实际上均是嫁接分摊于各个角色的。

怎么理解这个问题呢?可以看到下面一张图示意:

从二维视角下来看,各个角色以目标核心出发各司其职,通过工具平台功能都能很好实现目标;但是我们不妨拔高一层视角来看看:

以多维全局视角来看,虽然各个角色各司其职完成了自己的目标,但是基于产品使用层完全是由平台承载的,导致了各个角色的使用成本嫁接分摊给了其他角色,简答来说就是:

角色A完成对应目标时,存在角色B和角色C的信息干扰,那么角色A无形中分摊了角色B和C的成本。

举个例子:产品经理打开原型工具后,想直接拖动下拉框组件搭建一个产品原型,这时候选中下拉框组件想进行文案编辑,此时弹出了下拉框组件对应的编辑面板:字号、字色、字体、行高、字间距等等,然后其中部分功能则属于设计同学关注的,例如字体、字色、字间距等,但是此类成本则分摊给了产品经理,产品经理在整个搭建原型的过程中,增设了过滤这些信息的成本。

那有人就会说了,这很简单啊,可以直接做成个性化定制工具平台啊,根据每个角色身份不同进来设计师进来就只看到和设计相关的功能,产品经理进来就只看到和产品相关的功能不就好了?而且我把每一个角色对应的功能做到专精,是不是就精一技且解决问题了?

四、我要打十个!

看到这个标题大家可能会想到我们的咏春叶问老师,无论对手学的什么招数、有多少个人,叶师傅都能一人单挑全部,然后撂下一句霸气的:“我要打十个!”

收一收,继续回来我们的主题上来,是否将工具平台做成个性化定制平台并且其中功能都打磨细致,就能解决工具降本增效的问题了?其实不然,问题不能想得太复发,当然也不能想得很简单,都知道用户需求是分阶段而不同的,可能产品经理A不需要设置字号大小颜色,但是产品经理B为了今年绩效决定卷一卷同事,立志要出“高保真原型”,开始设置起了字号大小颜色,此时平台功能又被局限住了

那么究竟应该怎么做呢?不妨把眼界跳出同类竞品Axure、墨刀等,结合不同多角色并行的工具搭建类产品做竞品调研,得出两个不同的产品方向思路:

思路1是像叶师傅咏春拳一样,见招拆招:平台以通过不同身份拆分成不同时间段进行角色管理。

大致以上中下游角色进行功能分发,例如产品初期,上游的产品视角进入平台,基础的团队管理、项目管理、关联PRD等,然后进行聚焦产品原型搭建;之后流到中游由设计师进行二次加工,包括高保真原型稿、交互动效、串联页面跳转等;最后流到下游研发团队视角,研发通过已经二次加工过的高保真设计稿进行框架搭建、前后端接口串联等开发评估。

站在平台的视角来看,综上所述产品方向可拆解为:

时间维度:核心解决降本问题,包含时间成本、沟通成本,更加以维度追溯问题(产品问题追溯上游、设计问题追溯中游等等)。

角色维度:核心解决增效问题,减少信息干扰、提升操作效率、沟通效率和协作效率。

思路2则是基于前面个性化定制工具平台的思路上进行优化改造的,通过不同角色视角进入不同的工具平台,通过数据打通串联实现多角色同平台操作,减少时间维度上的强依赖关系。

例如产品进入平台,依旧是创建项目、管理团队等,然后开始进行产品形态输入和原型搭建,之后UE同学便能在同平台看到协作项目进行产出或者进行二次优化,最终通过管理员权限人员进行收口;其次针对平台来说,不断更新同步的数据,能间接丰富平台的多元化。

无论是思路1还是思路2,不难发现:将原型工具的核心目标降本和增效,往上抽象出一层就是围绕两个维度在解决问题:一个是具备时效性的时间维度,一个是具备多元性的角色维度。从上图可以感知到:不同时间节点,不同角色介入的时间随着时间维度的增加而变化。

因为整个项目周期,不同职能的角色一定会有先后顺序,那么有了这一层抽象以后,无论你的需求刻画多么具体,无论你的case多么边界,只要紧贴围绕这两个维度进行优化,都是从本质上解决工具平台的降本和增效问题。

五、再说两句

以上都是个人在体验了摹客RP之后,结合自己做搭建工具B端的经验进行的推导和总结,欢迎大家进行脑暴和讨论~

那么结尾回到我们最终的命题上:同处内卷时代,大家都在不停地卷功能、卷业务,原型工具平台到底应该怎么做?是勤勤恳恳专精一技还是遍地开花擅百技,我觉得都不是最好的出路。

应该先围绕降本增效核心目标找出并抽象出这个工具平台的核心本质,然后结合自身平台的优劣势扬长避短,紧贴核心本质进行优化、运营和推广,最后才可能在这个内卷时代脱颖而出。毕竟,市场上一直都存在着那些专而精、广而全的工具,但是真正站在用户视角出发,围绕用户核心目标准而快解决的工具产品,一向都是较为稀缺的。

本文为2022摹客RP原型工具测评大赛的测评文章,如对摹客RP感兴趣可点击体验链接:https://www.mockplus.cn/rp-event/?hmsr=woshipmhouyuhui

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

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

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