拿我 2 月加入一家出海公司做例子，我从来没碰过出海业务，相当茫然，快速融入新工作，靠的是个人风格强烈的两个老方法。
创始人向我讲解产品重点与发展历程 我把产品拆解为几个关键系统 每个关键系统，安排几个熟悉系统的人（最好是一线核心员工）和我面对面聊半天到一天，我一边提问，一边查数据，最后一起分析竞品
也就是我先拆结构，再在结构内挨个填充数据与认知。
2 月在公司内部做了三天访谈，很多人访谈的习惯是，对方先讲，等对方大段大段讲完之后，自己再输出。但我不是这样。
一开始，我就按照跟创始人和核心员工的对话，把产品拆解为几个关键系统，并得到他们的认可。然后逐一安排访谈。
在访谈中，我会按照自己对关键系统的观察和理解，把访谈变成 “记者提问会” ，我来把控对话节奏。也就是我提问，对方回答，我再追问，用一问一答的方式从老员工那里获取经验。问题有大有小，大到 “新用户的关系链是怎样建立的” ，小到 “这个页面的内容分发机制是怎样的” 。
在提问回答的过程中，我会不断地插话，插入自己的理解和总结，甚至是插入自己的新想法和 idea，请对方给出评价。交流的节奏非常之快，气氛融洽，更像是同行之间的高频对话。按我的理解，这种有来有往的对话，对方的体验明显优于单向的大段输出。
我提问结束后，再请对方补充，对于这个系统还有什么重要的，交流中遗漏的部分，需要向我介绍。
最后，我总结两件事，一是对该系统的全面理解，二是今天提到的，需要重点关注的改进项和新想法。同样请对方给出评价。
这种结构性访谈，从一开始就梳理清楚了主次轻重，相当于把流水账的 DOC 转成了循序渐进的 PPT。否则，哪怕对方知无不言，也很容易把业务介绍成大而全的流水账。
三天下来，核心系统已经了解完了。新公司的两个中干，也是创始团队的核心员工，评价是 “你对我们的（海外）用户的理解已经非常准确了。” 当然，也得益于这部分用户场景，在我过去的工作中有所涉及，触类旁通。
结构性数据通常也依赖分拆产品结构，除了日活/留存/分享这些基础数据外，分拆出来的每一个产品模块，独立一页，都有自己的多项核心数据。
这些数据平时散落在各个报表里，被我点名集中在一起，一眼看完互有关联的结构性数据，从框架结构上去理解业务，不受细节干扰。
结构性数据分两部分，一是不断变化的数据，放在每周报表里。每个 PM 认领并记录自己的数据，在周会上解读数据变化。二是不太变化的数据，每季度或半年更新一次。
我通常会针对结构性数据写一篇两三千字的数据解读文档，内部对齐认知。
1、不断变化的结构性数据 > 2、不太变化的结构性数据 > 3、影响功能转化的数据 > 4、不影响转化的交互数据。我把数据分成这四类。
理解框架看前两样，分析项目看后两样。
这些产品点，一大半来自访谈过程中，对别人意见的收集整理。散落一地的碎片意见被我分门别类，划清楚主次轻重，受访的老员工相当惊叹，在大会上问我这是怎么做到的。
无他，唯手熟尔。
又及，
你可能会想，一个月现场工作三天能干嘛呢？
这三天里，通常每天开 3-4 场会，每场会 2 小时左右。
每个业务项目组，挨个跟我聊最近一个月的进展/数据/反馈 我现场做总结，现场划重点，把每个项目组的大量信息提炼为几条线，每条线都有清晰的定义/价值/课题 然后根据投入产出比，划分优先级，现场提出解决高优先级课题的处理思路，甚至解决方案
来一次北京，大约要谈 5-8 个项目组。高强度输入他们一个月的进展，再输出我的反馈。下个月往往按照我的反馈建议来执行。
如果公司不仅需要我的咨询，也需要我帮助落地，那么在一天开了 6-8 小时会之后，晚上我会继续干到凌晨，画原型/出方案/写运营文案。尤其是特别难的课题，我很乐意冲锋在前，亲手出框架解决方案，别人在我的框架上填充内容。
离开北京前，再把这三天的工作，总结成大约 4000-6000 字的，高度概括的文档，返回 5-8 个项目组作为参考。
2 月也就是第一个月，密集访谈之后出了 4000 多字的《二月总结》，先拆出来几条大业务线，然后对每一个产品大点&小点提意见。
3 月，觉得我这种总结方式，可能不太符合内部的阅读习惯。就从项目角度出发，对每个项目组挨个提意见，《三月总结》6000 多字。
4 月，我上个月提的一些意见已经落地了，已回收数据反馈。所以项目组挨个提意见这种方式，我觉得挺好的，但老板看 5000 多字的《四月总结》可能有点累，所以我在文档最后新加了一个章节：
A 项目：预期收益 x 分，预期成本 x 分，不确定性 x 分
B 项目：预期收益 x 分，预期成本 x 分，不确定性 x 分
……
满分 5 分
其中 “预期收益相对较高，不确定性相对较低” 的项目用颜色标识突出。
这样，提示老板先从最后看起，一眼就能了解哪些是我建议重点投入的项目。有了框架认知，再回头看我对每一个项目组的意见。
同时把公司业务结构用 Xmind 画了张脑图，大概 100 个分支：重要业务线 > 重要项目 > 重要功能及备注。然后用不同的 icon 标注哪些是高预期的增长线，哪些是高预期的拉活线，哪些是高预期的营收线，以及每个需求的优先级如何。
因为是一目了然，平铺开的脑图，当树状结构的逻辑清晰，标注醒目时，这就是一份优雅的业务大纲。一方面平铺重要需求，无一遗漏；另一方面因为结构与标注清晰，也能一下子抓住重点，比冗长的文档易读很多。
这种文档迭代节奏，一月一更新，有什么回报吗？没有。哪怕是第一版的《二月总结》已经相当专业了。随后面向对象迭代，仅仅是我的个人爱好而已。我就是单纯地觉得，如果下一次能比上一次做得更好，我更得意。
这种内驱力，也是我能突破 35 岁退化陷阱的关键。不需要任何外部奖励，我的迭代动机来自于 “我就喜欢”，而我喜欢的事情又有那么多。
内容来自“用思考交换思考”的 PM 思辨社区「犬校」。©2017-2023
