分类目录归档:随笔

close up photo black Android smartphone

先 Solution,再 Product

我们部门名字之前是叫「Integration and AI Solutions」,但坦白来讲,过去我一直没太理解这个部门的含义,加上自己的序列一直是产品,所以始终带着 Product 的帽子,而没太在意 Solution。但最近发生的一件事,让我更理解我们的部门名,以及,想清楚了更应该做什么。

作为 RD 出身的 PM,我不自觉的会将手头在做的事情进行抽象 —— 抽象出面向对象的类,避免面条式代码。这样做很好,我们尽可能的提升我们在做的事情的可复用性(从一个具体的事项中,抽象出可以服务更多的人的需求,这也太产品了)。但,这样也很坏,因为一但没有把握好度,就会陷入到无限抽象的怪圈里。虽然产品抽象出来了,但用户的问题并没有得到解决。很显然,我曾成为后者,忙于抽象和设计产品,而不是真正的解决问题。

而走过这个阶段,我所得到的教训便是:「做事应该先 Solution,后 Product」,你需要先为用户解决问题,产生价值,再思考如何通过抽象去服务于更多的人。如果过早的开启抽象,大概率会陷入到虽然设计的很好,但不落地,不解决问题的困境当中。

用户关心的不是你的 Product ,他只关心他的问题是否得到解决, Product 只是 Solution 的一环。如果连问题都没有解决,那你的 Product 又有何用呢?

我希望我的反思能够启发大家,在产品开发和解决方案提供之间找到合适的平衡点,共同进步。

two roads between trees

为什么是产品决策优先级(二)

在上次写完「为什么是产品决策优先级」之后,我也和身边的几个产品同学聊了聊我的推演逻辑,他们给了我不同的输入,让我觉得,这些内容应该分享出来,既帮我厘清了思路,也帮助我看到了不一样的产品。

首先是产品 A 同学, 他的观点很简单:产品经理之所以决策优先级,是因为产品经理为这个产品的最终结果负责。这个逻辑其实是从证明的视角来看的,虽然所有人都为产品结果负责,但运营同学可以通过篇一些其他指标来证明自己的价值 —— 比如运营指标好;研发同学可以通过技术指标来证明自己的价值。唯独产品经理别无选择 —— 他成功与否的评价唯一标准便是 —— 产品自身的成功与否。产品最终承担一个产品背后的所有结果,从权责利对等的视角来看,则应该由产品 —— 这个最终承担后果的人来作出决策。

其次是产品 B 同学,他的观点比较有意思,也给我带来了不同的视角:产品经理之所以需要决策优先级,是因为价值不明确,需要“有判断力”的人来做出价值判断。他给我觉得例子是早期头条研发,早期的头条研发在整个产研链路上是比较有话语权的, 原因是产品的收益相对明确 —— 调整某个策略,能够非常明确的计算和评估出 ROI,导致最终优先级和价值回收变得非常简单粗暴 : 按照策略的预测上能力即可。相比于简单粗暴的广告 / C 端业务,B 端的业务显得收益不那么明确 —— 产品设计出一个功能,商业化团队未必能卖出去;商业化需要的功能,从产品视角来看,未必是适合产品定位的。从产品到商业化的长周期链路,使得对于产品的决策能力要求会更强 —— 需要产品能够从海量的信息中找到什么是最重要的?找到那个必须要做的事情。

two roads between trees

为什么是产品决策优先级?(一)

这个是个好问题:

  1. 为什么是产品来决策优先级?而不是研发而不是运营而不是项目经理?这个背后的核心到底是什么?
  2. 产品决策优先级的底层逻辑到底是什么?如果底层逻辑可以迁移,是不是别人也可以决策优先级?

我的答案如下:

  1. 产品决策的优先级核心逻辑是信息补全,产品让渡了一部分时间去参与各种会议,来换取足够的上下文,并基于这些上下文做出决策和调整。
  2. Leader 的预期是产品会被拉到各种不同的群 / 上下文里,梳理不同的信息,明确优先级,并帮助业务达成目标。
  3. 严格来说,一个好的产品需要的能力挺多的,你需要有用户感知、项目经验、沟通能力等各种不同的能力,才能更好的当产品。正是这样的原因,也让产品可以成为团队中的 Connector ,对齐不同人的信息和上下文。
  4. 产品决定大范围的优先级,但一些细节的优先级可以由具体执行的人来决策,毕竟要让听到炮火的人来做决策,才不会出现问题(也依赖听到炮火的人的能力)。

总结一下:

  1. 产品的决策底层逻辑是信息,这个人可以是运营/产品/研发,只需要让渡时间来做这些事情,你就可以成为这个做决策的人。
person holding black ceramic mug with coffee beans

零食经济学

d2b5ca33bd970f64a6301fa75ae2eb22 14
公司的零食箱

压力山大的时候,我就会选择去零食箱拿点零食,来消磨自己内心的压力(这也是为啥体重一直居高不下)。取零食多了,我开始有一些有意思的发现:

  • 我们楼层经常会剩下一些烤面筋、虾片、鸭脖;
  • 每次补仓的时候,并不会把之前的零食拿走,而是直接往里加新的零食;
  • 周末的时候,即使大家不怎么喜欢的零食,也会被吃完;

让我想到一个问题 — 如果我是餐饮同学,我会怎么做?

如果我希望零食被消耗的更快,那我会每次拍照或简单统计一下剩余的零食,然后大概可以知道不同楼层的零食偏好,并在下一次补仓周期里,重点补上那些大家消耗比较快的零食。这样可以让零食大量的被消耗。

如果我希望零食被消耗的更慢,那我会每次拍照并简单统计一下剩余的零食,这样可以大概知道大家不喜欢什么,在补仓周期里就可以进一步的补充大家不喜欢的零食,从而让零食可以被消耗的更慢。

d2b5ca33bd970f64a6301fa75ae2eb22 7

使用 Renamer 批量重命名,节约重命名时间

我最近在用 Youtube 看《喜人奇妙夜》(毕竟 Youtube 上有纯享版,体验太好了)。同时,为了方便我可以在地铁/高铁上看,我还会使用 Youtube-DLP 下载到本地。但,Youtube DLP 下载到本地的视频文件往往名字都特别特别的长,比如:

【纯享】《看不见的TA》i人闫佩伦和“鬼怪”张佑维变室友? | 《喜人奇妙夜》Amazing Night EP3 SKETCH #喜人奇妙夜 #闫佩伦 #张祐维 [XUsi1R1Ny80].f614.mp4

这个内容长度中存在了大量的无用信息,虽然对于 Youtube 这样的视频平台来说,有助于流量和搜索,但对于我这样的本地存储用户来说,大大的影响了我的本地观感,因此,我一般都会手动移出其中的无用信息。只保留作品名和基础的介绍信息,比如上面的文件名我会修改成 《看不见的TA》i人闫佩伦和“鬼怪”张佑维变室友?.mp4

当然,我可以写一个脚本来完成,但重命名这件事实在是太过于常见了,所以我也懒得写脚本(且脚本还需要指定路径,麻烦。),刚好,SetApp 套装中有一个 Renamer 的 App,可以解决这个问题,于是便有了这篇文章,介绍我自己是如何处理的。

分析目标和模块

Renamer 提供了多种重命名的能力,其中包括文本替换、正则表达式替换、数字、移出文本等多种能力,这些能力将会成为我稍后使用的工具。

d2b5ca33bd970f64a6301fa75ae2eb22
Renamer 提供的模块

如果看我们的文件名前后,可以很清晰的分辨出,我操作了两个部分:

  1. 去除了最前面的【纯享】
  2. 去除了后面一直到拓展名的中间介绍文字。

因此,我需要用到两个模块,来实现替换 —— 正则表达式(Regular Expression) 和文本替换(Find & Replace)。

配置替换

替换纯享

纯享因为是固定文本,所以替换比较简单,新增一个替换的动作,选择 Find & Replace,并配置只对文件名生效,设置 Find 为【纯享】,Replace 为空,就会在执行替换的时候,将【纯享】替换为空文本,来达到移除特定内容的效果。

d2b5ca33bd970f64a6301fa75ae2eb22 1

当然, 同样的功能你还可以用移除文本来操作 —— 选择 Remove Text, 并把要移出的 【纯享】放在里面即可。

d2b5ca33bd970f64a6301fa75ae2eb22 2

替换其他内容

【纯享】因为是固定文本,相对简单,但后续的内容则就复杂了许多,其中的内容会变化,且包含了大量的 ID、标签等信息,单纯的 Find & Replace 是无法解决的,因此我们这里用到正则表达式替换来完成。

你可以借助于 Regexr 这个网站来调试你的正则表达式,在上方编写你的表达式,并在下方填写你的测试文本,通过高亮,即可判断是否正确匹配。

d2b5ca33bd970f64a6301fa75ae2eb22 5

测试匹配正确后,复制上方的正则规则,在 Rename 中新增一个 Regular Expression 替换动作,配置成文件名 Only,并填入你的正则表达式。

d2b5ca33bd970f64a6301fa75ae2eb22 4

效果

最后,拖入你要修改名称的文件,就可以查看到批量修改文件名的效果了。这时你只需要拖入多个文件,就能一次性给 N 个文件完成更名的动作了。

d2b5ca33bd970f64a6301fa75ae2eb22 6

turned-on MacBook Pro

公司的期权该卖么?

在 X 上看到小橘子的这个信息,我觉得可以给一些我自己的输入。

从我自己的视角来看:如果你还愿意在这家公司工作,那么就应该继续持有。

接下来继续解释原因:

我这几年也在做一些投资,来满足自己在规律性的投资之外的动手的欲望。我卖飞过 NVDA、卖飞过 PDD、卖飞过 Microsoft。不过整体的收益还是正的,倒也还算是有一些心得。

期权可以理解为你所在公司的一部分权益,是兑换未来股票的机会。他代表着你对于一家公司的金钱的投入(虽然你并没有真实投入钱,但它也会占用同样钱的机会成本)。而你为一家公司工作,则是对这家公司的时间投入。

从这个视角来看,如果你觉得一家公司还不错 、还在增长,或还有增长的空间,你应该继续持有这家公司的期权或股票(至少这些不是卖出期权的理由)。那么,什么是我们卖出的理由?是我们发现更好的投资标的(比如你当前公司的增长是年化 10%,但你找到了年化 50% 的渠道);或者是我们发现当前公司已经不是优质的资产(比如你的公司已经在走下坡路了,它已经无力增长)。

如果你的卖出期权的理由符合上述两者任一,那么不要犹豫,卖吧。此外,如果你发现卖出的理由是当前的公司已经不是优质的资产,我建议你额外加一层评估:我当前是否有必要继续在这家公司工作?避免金钱投入分散了风险,但大量的时间放在了垃圾的资产之上。以及,记得在离职的时候把你的所有期权出清(既然它对于你来说已经是劣质资产了,为什么不卖掉呢?)。

当然,上述的这些条件依然需要你自己判断。不过,如果你持有的是自己所在公司的期权,其实相对来说还是好判断的,因为你真的懂这家公司,你真的能够感受到它的好与坏。相比于不熟悉的投资经理来说,我们还是可能拿到更细节的信息辅助判断的。这些信息,足够让你判断是否要继续持有当前公司的期权了。

people doing office works

什么是 Hackathon 以及在 Hackathon 当中取得更好的名次的小技巧

这个分享是我在 2024 年 5 月份的飞书 AI 训练营的分享,我觉得这个 PPT 的内容可以完美的诠释我对于 Hackathon 的态度,所以除了视频,我将文字稿也完整的撰写出来,希望让这篇文章对 Hackathon 感兴趣的你,能够有些帮助。

视频版可以在 BilibiliYoutube 找到。


什么是 Hackathon?

5e70b9cc82dbaf59c5fbfb19c1c488ce

Hackathon 是一个起源于美国硅谷地区的创新技术活动,来自不同背景、技术各异的天才开发者们会现场组队,在 24 小时内进行代码开发、创造新的产品,以解决某一个具体的行业难题或痛点。

当然,得益于技术基建的发展,Hackathon 不再是工程师、开发者们的专属,借助于各种 Low Code、Zero Code 工具,非技术人员也可以打造出一个产品,来解决一个具体的问题。

Hackathon 的三大特点

7463ba38c49de8883d69ee00a93adb06

Hackathon 有三个非常显著的特点,也是我个人非常喜欢 Hackathon 的原因:

  1. 短时高强度:Hackathon 往往是有时间限制的,一般是 24 ~ 72 小时之间。这个是我认为 Hackathon 最重要的特性。
  2. 开放:Hackathon 会更加的开放,无论你是什么背景,都可以在这里找到合适的队伍参与到其中。即使你的 Day Job 是一个设计师,但在 Hackathon 里,你一样可以是一个产品经理。
  3. 从零到一:Hackathon 一个很大的好处是给了大家一个从 0 到 1 的机会,你可以从 0 到 1 的打造一款产品,这对于在公司里往往只能做 1~100 中的某一小部分增量价值的打工人来说,颇为难得,可以帮助你获得在企业中无法获得的经验和视角。

我进一步解释一下我为什么认为短时高强度是 Hackathon 的精髓。

如果你做过力量训练,就知道有效的力量训练是让你在短时间内做最大力量的练习,以让你的肌肉发力,直至断裂的效果,并通过休息来让肌肉组织重新生长和链接。而Hackathon就有类似的效果,让你在一个很短的时间内去做一个看似不可能的事情,通过在这个极短时间内做事,来实现锻炼的效果。当你完成 Hackathon 之后,就可以复盘自己在 Hackathon 中的所作所为,并一次优化自己的下一步动作。

而且,因为Hackathon 本身的开放性,你可以在不同的 Hackathon 当中去锻炼不同的能力,第一场可以锻炼开发能力、第二场锻炼产品能力、第三场锻炼运营能力,以此类推,逐步把自己的各项能力的短板完成补上。

短时高强度另外的一个好处,便是沉默成本可控。我每次参加 Hackathon 的时候,都抱着:大不了这两天就浪费了的心态参加 Hackathon,因为就算我这次 Hackathon 一无所获,我也不过是浪费了 24 小时,周末在家躺平刷抖音也是浪费 24 小时,又会亏到哪里呢?而实际上,当我抱着这样的心态去参加 Hackathon,再配合自己多次参加 Hackathon 的经验进行一些基础的设计,我大部分时候都是有所收获的,甚至是大有所收获。

为什么“你”应该参加 Hackathon

上面说了 Hackathon 的特点,接下来说说“你”为什么应该参加 Hackathon

为了学习新的技能

  • Hackathon 是一个很好的学习新技能的机会:因为没有人会预期你会做的特别牛逼,反而能够让你放下自己内心的戒备,以空杯心态,认真学习新的技能。同时, Hackathon 因为是从 0 到 1,你可以试一试一些新的产品、技术方案。
  • Hackathon 是一个很好锻炼自己的创新思维的机会:Hackathon 不是日常工作,会让我们跳出当下的工作,抬头看路,看看还有什么新的可能性。而且,当你做一件事的事情被限制在一个特定的时间内,为了达成目标,你可能会爆发出你自己难以想象的潜力。
  • Hackathon 是一个很好的探索自己边界的机会:Hackathon 当中的组队只有分工,没有职位,你完全可以在 Hackathon 当中,试着去换不同的岗位来做事。比如你的日常工作是工程师,那不妨在 Hackathon 当中试着去做一个产品经理,换个视角来做事。
  • Hackathon 是有奖项的,如果可能的话,赢得一个奖项,也是不错的收获。随着 Hackathon 在国内的大行其道,不少的投资团队也会参与到 Hackathon 当中,你的项目甚至有可能会被投资人看中,给你一笔钱,让你全职做这个项目。
  • Hackathon 可以帮助你建立新的友谊关系:在平日里,我们扩展朋友的机会可能不多,Hackathon 是一个很好的机会,你可以认识新的人,了解不同人的思维风格和习惯,并通过 Hackathon 共同协作,达成战斗友谊。比如我自己之前和一个伙伴合作,参加了一次 Hackathon(当然,也拿了奖),在Hackathon 结束之后,我们又合作了一次,搞出了一个新的项目,数据还非常不错。如果没有 Hackathon,我们可能从一开始就不会认识,更别提合作项目了。

如何选择 Hackathon 主题

当你确定要参加一场 Hackathon 之后,马上就会面临组队和选题的问题了。组队不多说,每个人都有自己的风格,你可以选择强强联合,也可以选择百花齐放,自己喜欢就行,也往往不会成为大家困扰的内容。

而选主题往往会成为大家最困扰的问题,毕竟日常的工作当中,我们往往是在做命题作文,很少让你去自主命题。但 Hackathon 往往是不预设主题的,你需要自己去研究、发现,找到合适的主题。

从我自己的经验而言:

  • 如果你没有主题和想法,那么首先可以选择在日常工作中困扰你的主题,这类主题很适合在 Hackathon 当中解决掉。如果你搞定了但没拿奖,至少可以提升自己的工作效率;如果你搞定了且拿到奖,那就是双喜临门!
  • 其次,是选择那些你自己特有的、细分的、具有行业 Know How 的问题,这比你去解决一些更通用的问题产生的价值会更大,且你能够做的更好。如果一个医学背景和一个计算机背景的人同样去做一个医学领域的问答工具,那么医学背景的人肯定会比计算机同学做出来的东西更有价值,因为他更懂行业中到底有什么问题。
4ede7b9387234f30a091401d39586a5d

当然,找到这些问题可能不代表你马上会选择,很多时候,我们会担心自己选择的问题很小,不值得我们去解决。这里我的观点是:问题大小并不是关键,关键在于这个问题是否有价值,以及你是否能够在 Hackathon 的时间范围内解决它。毕竟没有人预期你会在一个 Hackathon 当中解决光刻机的问题。

当你真的打算去解决这个问题的时候,如果无法判断自己的问题是否有价值,一个最简单的方法是,先想清楚自己要解决谁的问题,然后找到符合这个画像的人,去问问他,给他提供这样的解决方案,是否可以满足他的问题。

77d11b8c3e5a43447b006c763082e175

Hackathon 中的项目管理

对于没有项目管理经验的人来说,Hackathon 是一个完美锻炼自己项目管理能力的试炼场。因为这是一个资源有限(3~5个人,24~72小时,满打满算 15 人天),同时 DDL 明确、目标明确的项目。

你需要在项目的开始时,找到项目最重要的P0、P1、P2,并安排好人、事物,让大家知道自己在什么时候应该做什么事情。此外,你还需要为项目规划合理的 Milestone,以便于检查项目的执行情况,降低风险,并尽早的发现风险点位,解决风险。

当你能够做好一个 Hackathon 项目的项目管理,那么对于一些小团队内部协作的项目管理,你便有了基础的经验,下次自己去做项目的时候,也就不会那么的焦虑。

5cf6bc1ed7aeb1dab4e4d37d6d0e3c4b

Hackathon 中的项目路演

在 Hackathon 的最后,一般是项目的路演。对于路演,我只有一句忠告:“项目路演很重要,要当成一件事来规划”。

我们在 Hackathon 的前半程都是在设计和实现产品,是一个”做产品“的过程,而路演,则是”卖产品“的过程,你要让评委 Buy in,让你的目标受众 Buy in。在 Hackathon 当中,你即要能做产品,也要能卖产品。毕竟,现在是一个酒香也怕巷子深的时代

把路演当成一件事,提前规划和留出时间做你的演示文稿,可以有效降低你在路演过程中的风险,同时如果可以的话,至少演练 1~2次你的演示文稿,以确保每个视频\动图\文字都是正确且易于理解的。

在你的路演过程中,如果有一些演示,可以用录制好的动图、视频,这样可以从整个过程中“偷时间”,将真实的产品演示放在最后,这样如果你的路演还不错,评委会给你时间让你演示完,以查看实际的效果,你就有了更多的时间去表达自己的主张。

以及,提前想想,假设你是评委,你会怎么挑战自己的项目?这样提前做好准备,就能更好的去应对评委的提问。

总结

以上的这些,是我自己参加 Hackathon的一些经验分享。希望能帮到你,同时,也希望你能享受 Hackathon,感受 Hackathon 的魅力,把 Hackathon 当成一种生活方式来体验。

a close up of a computer screen with a purple background

给孩子用的 AI 工具

今天参加一个线下活动,和朋友聊起来对于 AI 的恐惧和焦虑,问我该不该引导孩子去接触这一轮的 AGI 工具、接触这些 AI 工具。

我给了一些建议:首先,我认为我们应该给孩子接触 AI 工具。AI 的大趋势是不可逆的,基于这个前提,我们不应该抗拒孩子去接触 AI,甚至应该尽早的让孩子去建立 AI 的认知,知道什么是 AI 能做的,什么是 AI 不能做的,已经应该明确 AI 和 人类的价值边界。

用法

在聊天过程中,我们聊到了如何用 AI,我自己的观点是:

我们需要让孩子知道如何提问,以及区分出它是工具还是目的。工具掌握用法,并要明确我们的目的是什么。

剩下的,让他自己去玩就好啦。

工具

基于上述的认知,我认为现在可以推荐的工具如下:

ChatGPT

如果可以,当然是给孩子用最好的。但这个有门槛,以及作为家长,你可能要考虑 ChatGPT 本身是有风险的,可能会输出一些你不希望的内容(比如色情、暴力之类的)。

推荐程度: 5 🌟。

Perplexity

AI 搜索,体验很不错。如果孩子有搜索和探索的欲望,那么这个可能会比 Google 会是一个更好的体验。

推荐程度:5🌟

MetaSO

秘塔搜索的研究模式,比较适合孩子做一些方向的研究。可以让孩子在日常学习和生活过程中,有问题,提问。

推荐程度:5🌟。

Other things

在和这个家长聊的时候,发现现在缺乏一个 For 家庭教育场景下的GPT产品。这个产品的客户是家长,用户则是孩子。

和标准的大模型 、 产品之类的区别,是提供一些家长控制能力,这样会让家长们减少焦虑。

但我内心的另外一个声音告诉我:真的做出来,可能孩子也不会用,更好的办法是在现有的产品上加入家长控制模式。

pile of assorted-title books

介绍一下 Read it!

每年我都会给自己开一些新的坑,用于探索新的技术方向、新的领域。2024 年,我的新项目是 —— Read it!

Read it! 是一个用于分享我自己觉得不错的文章、网站的地方, 你可以在这里看到我日常浏览网页过程中发现的不错的网站、文章。

我会在分享链接的过程中,加上一些我自己的看法、总结。

如何使用 Read it!

  • 网页浏览: Read it! 是一个网站,所以你只需要打开浏览器,访问 readit.ixiqin.com,就可以看到我分享的网站。
  • RSS 订阅:作为一个古早 RSS 爱好者, 你可以直接在你的 RSS 里订阅 Read it! ,将 https://readit.ixiqin.com/rss/bookmarks/ 贴在你的 RSS 阅读器里,就可以查看到它。

为什么会有 Read it!

我是湾区日报的读者,也很喜欢湾区日报的形式。包括过去也尝试过用 WordPress 之类的系统来搭建类似的形态。但,繁琐的操作会消磨我分享的耐心。

最近又在整理书签,加上也开始进行一些大模型应用的开发,所以决定借助大模型来帮助我自己完成一些工作,就重新搞起了 Read it! 这个项目。

Read it! 目前的工作模式挺简单的,我找到觉得不错的文章,直接在 IM 里发给他,他会自动解析我的意图,并将解析出来的结果录入到系统当中,给大家看。想来这样的交互可以让这个项目活得更久一些~

d2b5ca33bd970f64a6301fa75ae2eb22 15
流程说明

Read it! 会分享什么?

Read it! 可以理解为是我自己再看的各种文章,所以并不会局限领域、方向,只要是我自己看的觉得有收获的,我都会分享。后续会考虑提供分标签的订阅方式,这样你可以选择只订阅自己喜欢的文章。

blue red and green letters illustration

Thinking in Component Tree

在开发前端应用的时候,我比较推荐在真正开始写代码之前试着画一画组件树 / 状态树。

在很多时候,可能你的设计师已经帮你做好了组件树,但在某些场景下,你的设计时并不会帮你拆解组件树,或者是你是直接和产品经理对接,他不会帮你拆解组件树。

这个时候,相比于写代码,我更推荐你先拆解组件树,在完成组件树之后,再开始你的 Coding。

d2b5ca33bd970f64a6301fa75ae2eb22 5

Figma / Sketch 之类的软件提供的分组能力、图层的能力,可以帮助你将组件合理的拆解、分组、归类。当你完成树的建设之后,可以试试看将不同的模块拆解,每个模块是否可以独立正常的运转。如果不可以,则说明你的状态拆解的可能是有问题的。

当你完成拆解之后,只需要按照你拆解出来的树组织你的 Component 即可。