一场对于工作和生活的快速思考，形而上的哲学 vs 接地气的执行。
约 2000 字，阅读大概需要 6 分钟。

其实这个标题是想说 when to be high-level, when to be specific.
high-level 这个词实在太难用中文翻译了，我能想到的一个词语是 “高屋建瓴”，当然，你要理解为大人们常说的 “格局” 也未尝不可 lol。
我们先来定义一下，我这里说的抽象是什么：抽象就是一些在行业内看起来“格局”很高的话题，例如，目标，战略，用户，方法论，市场，决策， PMF (Product-market-fit)， GTM (Go-to-market)， framework， critical thinking， systematical thinking 等等。有内味儿了对不对。
具象是什么，就是一些务实，需落地的东西，例如执行，工程，技术，UI，管理，质量保证，risk management，stakeholder management，budget management，数据驱动，成本管理，效率管理等等。看起来特别像打工人操心的日常。
最近的工作同时包括了非常抽象和模糊的 product and feature planning，也有不少 heads-down 画图画到吐的执行工作。两个视角来回切换，让我对不同环节需要什么样的能力，有了些模糊的感悟。
今天恰巧看到前 Amptitude 产品网红 - John Culter 的下面这篇文章，感觉又把之前碎片化的点连在了一起，大呼，我悟了。
先看这篇文章写了啥。
https://cutlefish.substack.com/p/tbm-218-level-depth-time-and-frame?utm_source=profile&utm_medium=reader2
TBM 218: Level, Depth, Time, and Frame
作为一个产品，当 John Culter 去定义战略，目标，roadmap 的时候他会按照四个维度
  • Level
  • Depth (or Specificity)
  • Time
  • Frame
Level 层级‍
"Level "与组织的架构有关。即使在相对扁平的组织中，信息和战略部署往往也是双向流动的。例如，企业战略会影响产品和市场战略，而产品和市场战略又会同时为企业战略提供信息。
作者没有展开说该如何运用 Level 的，因为作为 Director or leadership 视角的他自然可以从很高的维度看到这么多层的内容，以及可以比较从容地诊断和定义问题。
但是对于我的启发是，如果是一个在巨大组织下独立生存的个体，纠缠于那些琐碎日常的同时，想要更好的解决问题，也要有意识地去定义和思考这个问题是存在在哪个维度的。
我如果接到一个任务，我是不是需要思考，它是 feature level 的体验问题，还是某个产品功能缺失的问题，还是市场定位就不想做的问题，还是组织架构的合作问题，还是组织外部的客户反馈闭塞的问题，等等。
无论我是实习生，还是大老板，想要可持续的成长和进步，即使信息不完全，我得学会问问题，我得心里有数。
我现在越来越觉得“组织架构”对于“做好一个产品”有着极大的影响，甚至有的时候是决定性影响。一个笑话好像是说，一个产品的最终呈现，肯定反应了他企业的组织架构。
挂面的题外话
之前在大公司倍感心酸过，也痛悟过，自己曾经是，也目睹过某些具体职能的“专家”同学，想用一个 lower level 层面的方式去解决一个 higher level 的问题，盲目无视组织架构和企业级层面存在的障碍，其中的遇到的困难，令人无助和唏嘘。
问题的“空间位置“很重要：它在哪个地方，我想不想解决，它在哪个维度解决最合适。
Depth (or Specificity) 
深度和具体化程度
终于提到了标题，什么时候该抽象，什么时候该具象。我们先来看看平时经常犯的错误：
  • 以为组织内的“层级”和所需的“具象化程度”相关联
    好比只有老板才能想“高格局”的东西，而“IC” 只能做非常清晰的执行。其实这个和 Level 无关，有关的是你要解决的问题的属性，它需要你高屋建瓴，还是需要你具体执行。
  • 对什么时候需要抽象，什么时候需要具象没有判断，喜欢一概而论
    抽象 (high-level) 意味着它的标准是跳过细节，对项目进行抓重点的概述，侧重于目标、计划和结果。如果你包含了太多细节，就会让人觉得不耐烦，思路混乱。
    具象 (specific) 意味着它的标准是具备清晰可以快速执行的方案，并且有明确的衡量标准。如果你包含了太多倒返回去目标，计划等等，就会给人你在摸鱼，四处抄抄，并且执行力差的观感。
一些“用错了地方”的典型现象：
  • 强执行的环节扯哲学，故弄玄虚，过度拔高
  • high-level 还没定义清楚的时候直接跳到细节
  • 没有 vision 的创业：走哪里，算哪里
  • 在无法更改的严峻现实问题下(例如政策问题），盲目 dream big，大谈愿景
  • 在需要 high-level 层面高度对齐的话题时，带有偏见回避此类话题的讨论
  • 在需要 be specific 的时候反复纠结，过度验证评估，造成产品和公司内耗严重
所以，那到底什么时候需要偏具象化的表达和思考，什么时候偏抽象化表达和思考呢？
我非常个人地抛砖引玉一下一些思考：
  1. 对问题的所处阶段有判断，对模糊性的程度有判断
  2. 模糊性越大的东西，越需要从 high-level 开始，可以慢一些，形而上一些，注重原则一些
  3. 进入执行阶段需要 specific，敢于做得深入和具体，在迭代和试错成本较低的情况下，能不纠结就不纠结
  4. 考虑合作人的视角，对方是更具有宏观视角还是微观视角，补齐信息的缺失点，提高沟通效率
Time 时间
一个团队可能有一个季度战略，也可能有一个十年的战略。即使是 feature 和 task 也需要一定程度的 "战略"：例如很多 feature level 的规划也有诊断、指导原则和持续的执行行动等等。
时间同时也是决定优先级的一个关键因素。John 也给根据 high-level 还是 low-level 的一些内容定义了推荐的更新频率。
Frame 框架‍‍
框架我理解就是我们不断拆解问题后呈现的结果和模块，也是最适合头脑风暴和团队作业产出的方式了。这里就不展开了。
在 Level, Specificity, Time and Frame 之间游走，保持平衡，是一个重要的职业能力。任何工种都是如此。
不仅仅是工作，对生活的启发
一些挂面的 personal notes：对比年初非常形而上，并且沉迷于研究存在主义危机问题的哲学思考状态，五一之后的我感觉状态变好了很多。其中的感悟就是要把一些具体的和抽象的问题区别对待。这个也是朋友们之间，大家有相似困惑彼此交流之后的感悟。
好比感受，情绪，感情都是倾向于具体的，就不应该过度 intellectualize（理性化）这部分的自我。很多年前我就被朋友“批评”过，总是喜欢用理性去分析感受和感性层面的东西，结果就是产生了一些不必要的内耗和虚无，这也可能是多年设计教育和常年研究用户造成的职业病吧哈哈。
保持正念，把抽象和结构化的思维用在工作和创造价值上，生活上要关注当下，做具体的事，爱具体的人。
希望看到的读者们也可以在生活和工作中一起修炼这两者的平衡：）
相关历史文章
做工具设计的一些观点
关于 Product-Led Onboarding 的认知和实践
关于PLG的一些前置条件
一些伴随多年的职业鸡汤
正文结束
我是一名在硅谷/北京的产品设计师 - 挂面(年少的我一面试就挂!)，是字节、Dropbox Growth、Yahoo、CMU Alumni。目前在创业，热爱表达，日常喜欢思考抽象和哲学。努力维持理性与感性的平衡中 :) 

继续阅读
阅读原文
关键词
就是
就是
结果
还是