邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9923 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

05 | 如何当好AI时代的产品经理?(实践篇)

邱岳 2017-11-30
“纸上得来终觉浅,绝知此事要躬行。”——陆游
上篇文章,我讲到了如何学习成为一个 AI 时代的产品经理,这篇文章,我想结合我自己的工作,跟你分享一些我在做人工智能相关产品时的实践和思考。我进这一行的时间其实不长,而且目前的主要工作都集中在 NLP 领域,所以难免会有一些局限性,希望你批判地听。

1. 产品与算法的结合粒度要小

产品经理应当把大颗粒的整体性领域算法拆成小颗粒的算法单元,并在此基础上寻找产品化可能。这句话的意思是说,我们不能给算法团队提出一个很大的领域型需求,然后就坐等算法的突破,产品经理应当更小粒度地看待每个具体算法过程和环节,并评估是否有能够被产品化的成果。
比如,我们不能要求算法团队交付一个“聊天机器人”,这个需求粒度太大了,彻底完成会受制于各种因素,更是一个长期的过程。产品经理应该深入到领域内,比如看到自然语言理解(NLU),甚至看到其中本体库搭建和句子的语法树等等,可能部分完成的本体库已经可以包装为一个初级的人机交互引导产品。
我们在无码科技做 Readhub.me 时,产品经理会尽量避免提出像实现命名实体识别(NER)或实现信息抽取(IE)之类,这样大而化之的需求;而是尽量参与到算法过程中,分步去看过程产出。
比如命名实体识别过程中我们需要分词,分词作为一个中间算法,是否可以被直接产品化;再比如信息抽取需要先找到大信息量的文本片段,这个过程的产出,是否可以作为文章摘要或文本标签等等。
过去产品和技术泾渭分明,但在 AI 时代,我认为这个界限应该被打破,产品经理要融入到技术过程中去,不止关注需求,更要关注供给,这样才能做出真正的好产品。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 池建强 置顶
    谢谢反馈,留言、回复和通知的功能正在吐血研发中
    2017-11-30
    16
  • 二爷 置顶
    @安乐天 好问题!首先我觉得现在对 VR/AR 下结论还早,其次我觉得 AI 和 VR/AR 不同的是 AI 本身是底层技术能力的变革,也就是说随着算法成熟,不论是做社区还是做新闻阅读器,都可以用 AI 解决一些过去解决不了的问题。另外,纯以 AI 能力作为产出的公司在这一波里会有危险,但能结合场景和数据优势利用 AI 能力的公司会更容易享受到这波浪潮。
    2017-12-01
    9
  • 二爷 置顶
    @刘祯 谢谢你分享的案例,你的两个建议都已经私下多次反馈给极客时间团队了~ 据说已经在吐血进行中了
    2017-11-30
    4
  • 二爷 置顶
    @一行 1. 不太清楚你指的很多是多少,但我觉得对基础算法有个粗略的了解是必要的,其实数量没有想象的那么多,看论文也可以看到,很多时候都是通过去组合不同的基础方法解决问题。至于粒度,没法一概而论,只要别是不了解细节大而化之提需求,做到愿意深入细节里面去看算法,就很好。
     
    2. 数据清洗是个挺大的领域,我对它并不是非常了解,但我感觉想要有一招吃遍天的方法挺难的,因为源数据的不确定性导致了各种清洗和分析工作都需要针对具体问题做具体分析。
     
    3. 最后这个问题我没太看懂,有没有具体的例子可以详细瞅瞅 :P
    2017-11-30
    3
  • 刘祯
    感谢二爷的分享,看完今天的文章,第一个感觉就是,要学习的东西太多了,每个领域都有自己独立的名词与规则,要快速入门需要持续的投入。

    其次,关于了解算法的能力边界与未来规划,这一点我深有感触。

    上次大致介绍的 Glicko 积分算法采用积分和 RD(Rating Deviance),以区间的形式评定选手实力,相比于纯粹依靠积分来划分等级有一定优势。

    RD 用于衡量一个评分的不确定程度,RD值越高,评分越不可信。选手的积分仅根据对战的结果而改变,但 RD 值的改变取决于比赛结果和未进行比赛的时间长度。选手参加的比赛越多,关于选手能力的信息就越多,RD 值就会越低,评分的可信度就越高,反之亦然。

    对于数据的输入,我们采用了目前网球业余赛事中正式比赛的比分与数据,将其他非正式比赛排除在外,同时调整单打、双打的权重值,以便更真实地反应网球水平,目前推出的评分基本接近选手对于个人能力的自我评价

    对于数据的输出,我们将查询个人等级公布在每次赛事报名入口,并且严格按照等级来确认报名资格,评级系统要成为标杆还有很长的路要走。

    最后,这是我个人对「极客时间」的建议:

    1、文章评论区可以参考微信公众号的方式,作者回复与用户留言放在一起显示,建议不要将作者回复单独置顶显示,这样显得较为混乱,很难定位;

    2、关于精选留言与作者回复,最好能够通过 App 通知,这样会让用户有成就感,如果长时间没有反馈其实很有挫败感。我的留言中建议区分是否为精选留言。

    祝好。
    2017-11-30
    8
  • 郝产品
    “产品经理应当把大颗粒的整体性领域算法拆成小颗粒的算法单元,并在此基础上寻找产品化可能。”醍醐灌顶,分词、聚类、词对齐、句对齐都有产品化的空间。

    作者回复: 对,哪怕做个编辑器插件呢

    2017-12-05
    3
  • 一行
    看完后,畅快淋漓,启发挺大的。有几个小疑问。
    ①细化粒度时需要懂很多不同的算法吗?如何把大粒度的需求细化呢?
    ②文中讲述了数据收集到清洗到最终提交给工程师,数据清洗有没有其他的快捷的方法或者软件支撑?
    ③数据的最终目的是有效分析和产品化,如何多维度的进行数据的分析和串联起来达到产品化?
    问题有点多,都是实施环节的,希望二爷有时间解答一下,哈哈。
    2017-11-30
    3
  • 星语
    可以详细聊聊这块吗?想法很好,但是没有规划思路,求指教
    另外产品经理还应当想办法在业务中设计数据的闭环,通过产品的持续运转,不断生成更多数据提供给算法做训练。
    2018-04-10
    1
  • zhatrix
    得到的:产品经理1是分解问题,2是组合 ,3是利用。把已知的问题拆解成容易理解和实现的问题,包括拆解工程实现、算法过程等;组合是根据产品的场景和分解得到的已知条件组合在一起解决问题;善于利用所有的条件。
    2018-01-18
    1
  • 安乐天
    AI现在抄的火热,但是按照一般的科技产品的炒作周期,火热过去就是山谷,然后就是看技术的实际应用场景能不能达到投入产出比,比如去年得AR/VR.我想问二爷你是基于怎样的考虑认为AI的前景如此美好谢谢
    2017-12-01
    1
  • 和小胖
    类比一下现在的产品经理,其实现在的产品经理应该也需要懂一点技术,例如要知道原生native和h5的一些区别,否则如果都不知道各自有什么能力,提需求时候就很没谱。例如要知道接口是个什么东西,虽然不需要知道具体的技术实现细节,但是需要大概知道前台与后台是怎么交互的。

    产品经理懂一些技术,就可以提出更加合理的需求,也如二爷所说,可以提出颗粒度刚刚好的需求,而这些也能够增加产品经理在开发兄弟们中的可信度。

    AI 将来一定会成为基础设施,再加上 5G 的加成。
    2019-08-04
  • 龙猫
    Ai产品经理,必须懂Ai,然后深入算法细节中去,尽量在小粒度范围内,借助工程/产品的力量,实现价值。另外,需对数据有一定敏感度。对算法的不确定有宏观的理解和包容。
    2019-03-21
  • SmartAn
    听完觉得产品经理的高等数学需要好,还需要懂许多算法啊
    2019-02-21
  • Wendy
    感觉思路很清晰,对身为测试的我,也很有意义
    2018-11-28
  • javaadu
    二爷作为产品对AI的理解都有如此深度,我做技术的也得跟上潮流啊
    2018-08-16
  • Dylan
    融入技术
    2018-06-09
  • Dylan
    颗粒度是个好概念,除了算法本身,产品经理也要把对技术应用场景和范围的思考扩大到所有环节。本着为用户提供价值的初心,拆解技术喂各种粗细都颗粒度,或截取或组合,应用在产品服务上,然后交付出去。
    2018-06-09
  • lyjustforfun
    有点深奥了,需要多读读才能理解吧
    2017-11-30
收起评论
18
返回
顶部