标签归档:随笔

你需要两个日历

在进入字节之前,我一直在 iPhone 上使用 Calendar 5 来管理自己的日程,简单方便。进入字节后,我将日程的管理转移到了飞书之上,使用飞书来管理的我的日程,方便,毕竟约会议室什么的,确实很舒服。

不过,我也发现了一些问题,出于安全原因,飞书的日历不支持在外部读取,只能在飞书上查看(也正常,毕竟日程里还包含了与会人、时间、地点等信息,真要是泄漏了很麻烦的),那就需要考虑,我的生活日历放在哪里?当然可以放在飞书上,并设置隐私,但总觉得奇奇怪怪的。所以,我还是用回了 Calendar 5。

在具体的使用上,我是这样操作的:

  1. 工作日历保留在飞书上,工作日历的时间设定在上午的 10 点 ~ 下午 7点(合同里的工作时间),基本上满足了绝大多数场景下的需求。
  2. 个人日历放置在 Calendar 5 上,只用来记录下午 7 点 ~ 早上 10 点之间的日程(当然,有一部分是睡觉的时间)

这样有意识的区分可以让我将工作和生活的日程区分开。

在实际操作的时候,一定要注意,不可将生活日历放在飞书中读取,因为这样会让你下意识的想在飞书中加入日程,是比较不方便的。因此,有意识的隔离是必要的。

投资投的是认知

为什么说投资投的是认知?

因为每个人的风险偏好、资金情况、收益时间、收益预期不同。

别人讲投资策略还可以看看,聊投资标的看的意义不大。

我自己的“认知”的例子

我自己曾经是 $NVDA 的持有人,我在 100 美元买入,在 150 美元卖出,这是因为在我看来, $NVDA 只值 150 美元。但实际上,$NVDA 一路疯涨,涨到了 1000 美元,并完成了拆股的动作。

如果我认知到 $NVDA 值 1000 美元,那我不会在 150 美元卖出。

你知道一个股票值多少钱,便是你的认知。认知结合当前的市场价格,就很容易做出投资的决策。

成为对抗「制度化」的人

对于大企业的员工而言,我们会有逐渐「制度化」的倾向。因为制度确实帮助我们包办了一切。但作为一个独立的个体。我们既要享受制度化带来的便利,也要警惕制度化带来的问题。

在《肖申克的救赎》当中,制度化使得图书馆管理员老布身上体现带来的淋漓尽致。被关押了 50 年的他,没办法再良好的重新生活在社会当中,最终,以自杀告别。

而对于我们每个人的启示就是,我们要学会主动对抗制度化。主动对抗制度化不意味着你要抗拒企业提供的各种制度。也不意味着你为企业服务一段时间后就离开。

主动对抗制度化意味着你应该学会主动反思企业提供给你的各种价值,以及反思企业提供的价值是否有可以替代的解决方案。在 Netflix 的文化当中,鼓励员工去外部企业面试,也是一种提醒你反思体制化的手段。但所有的这些,都不如我们自己反思「我是否被所在的企业制度化了?」,「除了企业的制度化相关的东西,我们还有一些什么?」

用什么样的视角看待问题决定产品的形态

在计算机领域有一个非常经典的业务模型 —— IaaS、PaaS、SaaS,借助这个业务模型的区分,我们可以快速的给自己的产品找到定位。

但在看产品的时候,其实你不应该去关注这些技术维度 —— 或者说,你真正应该关注客户的问题,以及你如何看待这个问题。

当你关注问题的视角不同,你的产品形态也会完全不同。

举个例子:

  • 网站的部署需要服务器
    • IaaS 层的产品认为我们只要让服务器易于获得就好,那我们就做 IaaS 层的云主机进行售卖。
    • PaaS 层的产品认为服务器只是资源维度,用户并不关心资源,只关心应用的部署,那我们就做平台层面的产品,我们给用户提供基建,用户只关心基建之上的应用即可。
    • SaaS 层的产品认为,网站不过是服务于业务的产品,既然如此,我为什么不直接给用户提供能解决问题的手段,技术根本不重要。

当你去找你的产品的竞品的时候,除了去关注同一个层次的产品,也需要关注到哪些和你不是同一个层次,但解决的问题相似或类似的产品,这些东西会有助于你更好的理解自己的产品,并划分产品的界限。

大团队和小团队的工作体验

今天在上班路上听播客听到了关于创业公司和大公司的事情(也可能是我看即刻看到的,记不清了)。提到了大团队和小团队的工作体验。刚好也聊一下自己的体验。

小团队

我进公司以来,其实大部分时间是在小团队工作 — 轻服务团队,20多个人,包含产研。虽然大家都是研发工程师,但细分为架构组、业务组、前端、产品组四个方向,每个组内几个人,坐在两排位置上。

在轻服务的工作体验最大的就是 —— 开心,我们只需要关注我们想要做的事情,把我们要做的事情做到最好就可以。不需要太过思考这个业务对于领导和公司的价值(我乐观的相信这个业务是有价值的,未来是可以成的)。我的日常工作是创造出一个新的东西来,去解决新的问题,价值感满满。

不过现在回过头来想想,我们当时之所以能做的那么开心,可能很大程度上是王潇在替我们负重前行,帮我们扛住了更大的压力,让我们可以更加的开心做想要做的事情。

大团队

来到开放平台后,我的工作模式不可避免的从一个小团队的模式变成了大团队的模式。开放平台单产品就有 20 人左右(产品+运营),加上研发,估计要百来人?

我们每个人工作的事情也会更加的细致和细分,每个人都在做一些更细致的问题。以我为例,我最近专注在如何让飞书开放平台的 OpenAPI 可以更好用。虽然说起 OpenAPI ,大家都觉得这是个小事,但想要做好还是有许多细分的事情要做。我需要在更加细分的领域深耕细作。

在小的领域深耕细作的价值感显然不如创建新的东西。但我觉得不一定是坏事,过去我的似乎都太过于野路子、创业公司化,深耕细作磨练一下自己是一个不错的选择。

在开放平台的另外一个感受就是 —— 责任,不同的 leader 的管理风格不同。有的 Leader 的风格好处是让每一个人都可以更加专心做自己想做的事情。另一方面也会失去承担更大责任的可能(因为责任都是Leader在扛)。另外的 Leader 显然对于我是有明确的预期的,对于我来说,我也感受到了这样的预期。对我自己而言,是一种压力,也是一种激励,希望自己可以达成那样的预期。

总结

大团队也好,小团队也罢,都有所得,挺好。在小团队野路子不是坏事,在大团队深耕细作也不是坏事,只知道这一种选择才是坏事。记得,参差多态乃是幸福本源。

OKR 要长远,但迭代要敏捷

飞书执行季 OKR 已经很久了,相比于过去的双月 OKR,我认为这确实是一个好的事情。季度 OKR 可以让我们在一个更长期的事情上来完成我们要达成的目标而无需担心自己所做的事情要更加的长远和长期,也期待更多的团队和协作方可以享受到季 OKR 的带来的长期。

但从另外一个方向来看,即使我们使用了季度 OKR,也需要关注执行的迭代。

OKR周期是我们达成目标的周期,而做事的手段则应该尽可能的敏捷和快速。快速判断、快速执行、快速复盘、快速修正。

目标大和周期长是我们要着眼于更重要、更长期的事情。而迭代的敏捷,则可以帮助我们更好更快的抵达目标。

作为一个技术出身的产品的自我阉割

作为一个技术出身的产品同学,我比较自豪的是,我不会提出一些非常离谱的需求。因为我大体上可以感知到技术的边界在哪里,但另外一个层面,我同样也会有比较严重的自我阉割的问题。

比如,如果某一个数据的要求严重超出了一般意义上的限制,我可能就会先自我阉割,认可这个事情虽然能做,但可能 ROI 划不过来,前置给了判断。但实际上,真的做不到么?未必,也可能只是我们没有去做。当然可能 ROI 上划不过来,但在产品对标和洽淡合作时,这些可能是会被客户挑战的问题:“为什么你不如 XXX”

下次做决策,要先多调研一下, 再做判断,不能让自己的技术脑完全占领了高地。

先 Solution,再 Product

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

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

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

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

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

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

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

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

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

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

这个是个好问题:

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

我的答案如下:

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

总结一下:

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