6

AI2.0 时代“TPF”模式为什么会提升PM的核心竞争力?

 8 months ago
source link: https://www.woshipm.com/zhichang/5963095.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.
neoserver,ios ssh client

前两天跟朋友讨论了“在极客公园创新大会中,王小川认为在AI 2.0 时代,PM应该具备 TPF 能力”这一话题。TPF:Technology - Product - Fit,即:技术产品契合度。

52817d8e-d9de-11ed-bd5e-00163e0b5ff3.jpg

本文小编将对以下三个话题进行较为详细的观点阐述,同时也欢迎更多有思考的业内朋友给小编提出宝贵建议。

  • 在AI 2.0 时代,为什么大模型厂重提 TPF ?
  • 在AI 2.0 时代,大模型厂的TPF模式是怎样进行的?
  • 在AI 2.0 时代,AI应用厂的PM应该具备“TPF”能力吗?

一、在AI 2.0 时代,为什么大模型厂会提 TPF ?

小编作为一个产品人在遇到新鲜事物时,通常会在历史中寻找它的影子。AI 2.0的开启是由于OpenAI发布的chatGPT3.5 对中国的互联网生态产生了巨大冲击而导致的。而最近一次类似的场景是产业互联网爆发(2019年)。在当时,王淮(线性资本)也提出了一个相似的概念:Technology-Problem Fit(技术与行业现存问题相契合度)

1. 创业就是从一开始的Technology – Problem – Fit转换为最后能够变革到有效Product – Market – Fit的过程。

2. 当创业公司提供的不再是一款消费品或是 App,而是依托于新兴技术的一项解决方案或企业服务。这个时候,Technology – Problem – Fit 可能会比 Product – Market – Fit 更适合当作突破口,来指导技术创业项目的冷启动。

3.这样的产业变化对人才提出了什么要求?第一个是懂技术,原来搞技术或者做有技术 Sense的产品经理,都要是非常好的人才,这是一个必要条件;

我们可以发现这两个场景有非常多的相似之处:

  • 都是依托于新兴技术,提供一项解决方案或企业服务;
  • 都认为项目创业初期,应从技术角度出发,而非市场角度出发;
  • 都认为产品经理需要懂技术,或具备技术Sense。

从王淮和王小川的分享中,小编得到的结论是:

以技术驱动增长的团队在创业初期,团队需结合自身的技术特点能力和市场需求,不断打磨平衡两者之间的契合点,从而解决用户痛点,形成市场规模。

那为何两位行业KOL大佬,都是站在以技术为核心的角度,但却提出两个不同的观点呢?

因在 “产业互联网” 爆发时:

  • 5G等技术是相对成熟的,技术能力领先于市场痛点。
  • 大多数产品人对5G、大数据、云计算等非全新技术的能力优势和缺陷都有足够的认知能力;

而在 “AI 2.0 时代” 爆发时:

  • 大模型技术不够成熟的,大模型技术能力落后于市场痛点。
  • 大多数产品人对大模型的能力优势和缺陷都没有足够的认知能力;

如果让小编用大白话说差异:

  • Technology – Problem – Fit:典型的锤子找钉子;我(技术)是高富帅,你(PM)按我的标准帮我找个白富美吧~~
  • Technology – Product – Fit:我(技术)就是只青蛙,你(PM)就说怎么穿搭,能让我吃到天鹅肉吧~

通过这样的复盘,就不难理解在AI 2.0时代,作为国内模型厂赛道KOL的王小川为什么会对AI产品人提出在“PMF”之前要具备“Technology – Product – Fit”能力要求,而非“Technology – Problem – Fit”能力要求。

二、在AI 2.0 时代,大模型厂的 TPF 模式是怎样进行的?

王小川:TPF 首先对产品经理有要求。

第一,一定能把需求转化成测试集,测试集能让技术工程师在满足需求时发现「手感」在进步。以及把 Demo 往外推出的时候,用户提的需求分布正好和产品经理提的评测集分布一致,评测集里的结果能满足用户需求。

第二,推产品的时候会提到 PMF,看市面上的 Marketing Fit(市场契合度)分布是否一致,用户是否满意。

首先小编先基于王小川的描述,对在大模型厂工作的产品经理的“TPF”环节进行流程梳理。

5ae8dd0a-9fa9-11ee-8fc4-00163e142b65.png

在上述的流程图中,涉及到模型训练的术语,这里小编就请Kimi Chat进行名词解释:

7bb2381a-9fa9-11ee-9167-00163e142b65.png

在王小川的分享中,多次提到了“评测集”这个名词。评测集(即:测试集)对于传统产品经理的需求设计流程中其实就是“需求实现的效果评估标准”的含义。

那王小川为什么如此在意产品经理对“评测集”定义的能力呢?因为王小川是站在如何设计一款用得爽AI-Native角度来思考这个事情,而非如何设计一款用得好Native+AI的角度。

这里你可能又有疑问什么是用得爽的 AI-Native?什么是用得好的Native+AI ?

小编举个例子:

  • AI-Native:ChatGPT、Claude、Midjourney;
  • Native+AI:Adobe-Firefly、通义听悟;

在小编理解,AI-Native 解决的是一个多维度的领域需求,而Native+AI解决更多是一个单维度的场景需求。

可能这样的描述比较抽象,那小编用一个类比的方式:AI-Native 是在构建一个小说的世界观,而Native+AI是构建小说中的某个章节或场景;

当作为产品经理的我们,面对一个单维度的场景需求时,定义痛点解决的效果评估标准相对较为轻松。而当面对一个多维度的领域需求,定义痛点解决的效果评估标准就变现不那么轻松了。

由于目前的大模型的不完美性,在生成过程中缺乏可解释性;在结果输出方面的诸多缺陷(如:幻觉、灾难性遗忘、局部最优解困局等)。

评测集的合理性定义是作为产品经理,在当下为数不多可以控制大模型输出效果的解决方案。

王小川提到在需求推向市场进行验证时,期望产品经理定义的评测集可以覆盖用户的需求场景。同时也印证了小编的观点。

到这里,不知道小编是否表达清楚:为什么大模型厂会重视“TPF”,以及在大模型厂的产品同学如何运用“TPF”完成需求设计呢?

三、在AI 2.0 时代,AI应用厂的 PM 应该具备TPF能力吗?

1. 有大模型自研能力的互联网大厂

前两天跟@Super黄讨论这个话题时,Super黄引用了李彦宏分享的一段内容:

张鹏:这个也引发一个话题,你看过去移动互联网的时候,我们要做一个开发,大概知道是个什么流程——要有产品经理画出原型,前端、后端实现。在 AI 时代,基于大模型做 AI-Native 的开发,我们到底开发的是什么?

李彦宏:我觉得从应用的角度来讲,倒没有什么特别的,就是你要解决什么问题、给别人带来什么样的价值,这个跟过去时代的开发相比是一样的。

但是使用的方法确实不一样,对产品经理的要求,对于研发人员的要求,对于一个公司的组织能力,可能都是跟以前不太一样的。

今儿小编在写这篇分享前,仔细阅读了李彦宏的全部发言后,对这个@Super黄的论点有一些不太一样的思考。

首先我们先看一下上文中的后半段内容:

但是使用的方法确实不一样,对产品经理的要求,对于研发人员的要求,对于一个公司的组织能力,可能都是跟以前不太一样的。今天在百度的话,PM(产品经理)和 R&D(研究与开发)的比例是发生变化的。过去我们一个PM要对很多 R&D,今天可能是 1:1 了。或者说很多做法在前期进行测试的时候不太需要 R&D 介入,PM 自己攒一个东西就可以做到,这是跟以前比较不一样的地方。

李彦宏虽然没有提到“TPF”这个概念,但字里行间内又表示,在很多idea(需求)的前期测试阶段:不太需要 R&D 介入,PM自己“”一个东西就可以做到。

作为产品人,咱们都知道在MVP阶段,PM自身具备开发能力,且能够独立完成需求测试的人是少数的。所以小编理解,这个“”就是PM自己完成的了“TPF”阶段。

李彦宏的另一句话 “过去我们一个PM要对很多 R&D,今天可能是 1:1 了。”在小编看来也有可能在一定程度上印证了小编的猜想。

2. 有大模型微调能力的垂类头部公司

在小编的上一篇《如何跨界成为AI 2.0 PM?》中提到AI 2.0领域可以分为以下四类公司:

82763e28-989f-11ee-8fc4-00163e142b65.png

大模型厂和有模型自研能力的互联网大厂,小编都已经聊过了。接下来还有一类公司(有大模型微调能力的垂类头部公司)也涉及到模型训练工作。

那在这类公司里,“TPF”模式对产品经理有帮助吗?

答案是有的!

从业务层面考虑,在上文中小编已经阐述了“TPF”模式的作用及价值。虽然垂类头部公司大多发力于Native+AI方向,评测集定义的难度远小于另外大模型厂。但不可否认的是,好的评测集定义对需求的最终输出效果的将产生了质的提升。

从个人层面考虑,“TPF”模式似乎已经成为 AI2.0 产品经理(与模型训练有交集的)工作中必不可少的一个环节。可能同业的你已经在或多或少的进行这一个环节的流程,但自己还没有感知。

在AI 2.0 时代,“TPF”中的测试集定义能力,可能会逐步演变为:产品力的一个基础能力要求,并且是一个极具竞争力的能力项。

3. 为什么说“TPF”中的测试集定义能力会是AI产品经理的核心竞争力呢?

“TPF”能力对于AI-Native场景的重要性就不再赘述了;

在Native+AI场景中,产品人“通过TPF不断优化评测集解决了一个场景需求”的经验,就可以归纳总结为这个场景的AI产品能力的一个技能点(知识),当你解决的场景需求数量达到一个量级后,就变成了你的一项方法论(智慧,亦或者 神性)

9956f8b0-9fa9-11ee-a222-00163e0b5ff3.png

基于TPF的分享就到这里了,期待各位AI 2.0 的产品同行者提出自己看法。

  • 对话王小川:大模型创业核心,是想好技术如何匹配产品
  • 李彦宏:卷 AI 原生应用才有价值,别卷大模型了!
  • 线性观点|当我们说“灰科技”时,说的是用前沿科技解决产业升级中最痛的问题
  • 杨植麟、王小川、李彦宏激辩:TPF vs PMF

专栏作家

杨三季,微信公众号:杨三季,人人都是产品经理专栏作家。7年互联网经验的高级产品官,深耕内容电商,互联网保险领域,擅长产品增长、数据分析、中台架构等内容。

本文原创发布于人人都是产品经理。未经作者许可,禁止转载。

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK