编辑导语：作为一名产品人，在职场摸爬滚打之际，总会遇到一些坑，收获成长。作者分享了他10年做产品的经验，并且进行了相关复盘，总结自己踩过的坑以及收获的经验，再到如何成为一名产品总监的感悟。我们一起来看看吧。

在8月8号生日的晚上，我在GZ酒店里敲下了超过5000字的长文 10年产品工作的一些感悟（一） 纪念并复盘这10年多的产品经历。文中介绍了我大学毕业前5年在一家上市公司的产品工作经历与感悟，这些内心深处最真实的感悟也得到了很多人的共鸣，非常感谢那些订阅本文的同行。

这个10年感悟系列文章总共分为三篇，本文是第二篇，我将纪念下创业环境中的一些经历和感悟。我的职业生涯过程中大概每两年就会出现一次发展瓶颈，随之而来的就是焦虑、浮躁、迷茫。机缘巧合，2014年7月我参与了一家创业公司的筹建，我开始进入互联网行业……

一、义无反顾地去创业

2013年余额宝横空出世，在互联网大厂的引领和监管的默许下2014年互联网金融如火如荼，真假互金公司犹如雨后春笋般，一夜之间漫山遍野，那是我见过最火的风口。

2014年6月份的某个中午，那会儿我刚睡醒。一个好久未见的同事神秘地把我拉到一边，公司要与两个大厂一起筹建一家互金公司，目前正在组建创始团队。

我在一无所知的情况下，不知道业务是什么、不知道岗位什么、不知道待遇是多少，我一刻也没有犹豫就答应加入筹备团队一起去创业。我还记得，在公司的顶楼天台上，半小时时间就谈好了，我想那时候我心里有一团火吧，我想去做C端产品，我想去创业，我想去奋斗。

1. 我的主要工作

我们从筹备到开业花费了一年时间。这一年公司主要在组建团队、探索业务方向、搭建交易平台和申请准金融牌照。我作为技术部门2号位，我主要负责：

技术团队组建：刚开始没有专职hr，团队由每个部门自己筹建。我化身为一名hr，不分早晚不分周末，先是遍历了老同事老同学校友，然后往返于各招聘网站捞取简历。

前后我面试过不下100人，找到了后端开发主管、前端开发主管、移动端开发主管、测试主管、运维主管、数据工程师、产品经理、交互设计师、设计师等。我完成了技术部门框架搭建核心团队组建。

技术部门协调：在开业前我们需要完成前端交易平台（网站、App）、后端交易平台、互联网运营系统、后端业务系统建设、完成与第三方支付系统对接、资金存管系统、完成系统运维环境搭建。

有个特别自豪的点是2014年我们根据当时的实际情况采用了全部系统上云的方案，我们没有机房办公室没有一台服务器，这在当时是非常激进的做法，当然现在看来是非常有远见的。我作为牵头人协调技术部门团队与第三方团队完成了这些工作。

产品团队管理：我与团队根据业务方案、运营需求完成整个需求梳理、产品方案设计、交互视觉设计。由于业务的特殊性，市面上没有成熟可复用系统。

我们没有任何C端经验、没有网站经验、没有App经验、没有互金交易平台经验、没有自营运维经验、虽然过程磕磕碰碰，但是我们一起完成了全公司平台0到1的搭建过程。

现在想想我们这40人的团队战斗力碉堡了，这里面至少有三分之一人能进一线大厂，我很怀念这个团队。

2. 踩过了哪些坑

危险的人人都是产品经理：

对于没有数字标准的、专业门槛不高的事情大家都喜欢发表自己的各种观点，并且都认为只有自己是对的，互不相让。

做产品的人应该都知道大家最喜欢对产品工作指指点点，喜欢对各种流程体验发表看法，喜欢五彩斑斓的黑，喜欢戳设计师的mac屏幕，你去看设计师的mac屏幕上是不是都是手指印。大家也喜欢对运营工作提出各种意见建议。

对于专业性比较强的工作就不这样了，你看看有几个非技术的人对技术方案指手画脚，有几个人会跟公司法律合规部门沟通政策法规，大家巴不得敬而远之。当然也有个特殊情况，就是有其他部门的人懂这些专业性的知识，并且没有边界感，总想着得听他的，觉得在坐的都是垃圾。

这些都是没有边界感权责不清造成的，没有搞清楚谁对目标负责。我们在这个上面吃了大亏，慢了进度，坏了氛围，伤了和气。

专业的人，干专业的事。一旦确定了负责人，就算不是特别专业也要去相信，给与支持。

致命的领地意识与部门墙：造成部门墙和领地意识的原因有多种，我就说两个。

长期没有边界感权责不清必然会导致受影响大的部门强势反弹，我的领地你不能踏入半步，你的建议我一个也不听，就算是合理的建议我也只听一半。

当我背后有了一个大团队时我就会考虑如何保障团队的正常运转，保护团队的利益。在公司的磨合期、管理初级阶段，需求方部门随意变更的需求、对需求上线时间的不合理要求很容易引起摩擦和冲突。冲突之后必然会进一步高筑墙，优先考虑团队利益部门利益。

这是我个人不成熟的表现，也是公司管理的问题，最后由公司买单。

不要被情绪奴役，管住吐槽的那张嘴：

有些岗位天然就是冲突的爆发点，当这个岗位上的人同时要承担高难度高强度工作的时候，搞不好很容易心态失衡，很容易情绪化。情绪化后人就需要发泄，需要吐槽，吐槽往往就会被当做负能量。

人都不喜欢负能量的人，领导是人，所以领导也不会喜欢负能量的人。我做了很多有价值的工作，但是情绪化也吞噬了这些价值，而当时却不自知。

人都有意无意给别人打标签，负面的标签一旦形成就需要很大的代价去去掉标签，这个代价就是收入和成长。

我曾经是这样的人，花了好几年才有改观，直到现在换了环境才去掉了标签。这也是成长吧!

没有业务就没有产品：

我们干过好多次业务还只有一个构想的时候就启动了产品的研发，业务还未就绪时系统就已经就绪了，最后业务和系统都没能上线。也出现过很多次需求反反复复。

这不仅浪费了公司资源，也伤害了团队积极性与部门间的信任。这里有人性的问题也是管理的问题。产品经理，特别是产品总监一定要注意这个问题，违反规则与逻辑的事情往往欲速则不达。

3. 获得了哪些经验

拥抱变化、一往无前：

可能是无知所以无畏吧，可能是梦想在燃烧吧。2年多时间我深度参与，甚至不谦虚地说组建了团队、领导团队完成了一家互金公司经营所需产品系统的0到1建设。我没有给自己划定一个框框，哪里需要我哪里就有我，虽然有很多未知的困难但是我从未害怕、从未停止脚步。

面对未知，不要害怕，办法总比困难多。比如招聘这个事情，我不懂移动端、不懂UI、不懂运维，我就多面试几个候选人，听每个候选人怎么讲，听听谁讲的更有逻辑更透彻，听听谁是一路人。

做品工作，特别是领导0到1阶段的工作，没有勇气肯定是做不了的。

大产品意识与落地意识：

作为产品经理，特别是承担了项目管理职责、团队领导职责的产品经理，我们心里要有大产品意识，产品衔接着上下游，是一个中枢环节，产品的上游是业务、运营、产品这些，下游是设计、开发、测试等，我们需要依靠上下游各个环节来完成工作，实现产品的最后交付上线。

大产品包含了产品工作的上中下游，产品经理只是大产品的一环。产品经理特别是产品总监要团结好产品上下游，相信团队依靠团队。

产品经理工作的价值是实现产品的最终业务价值，只有产品落地了才能实现价值，如果产品夭折了，前期的付出就都打水漂了。产品经理都希望产品功能强大体验好，但是大前提是要先落地。

先场景后产品：

“如果说功能和界面是产品的骨架，内容是产品的血和肉，那么场景就是产品的“灵魂”。没有场景的产品是没有灵魂的，是YY出来的，是自嗨。做产品之前先了解清楚用户需求是什么、业务流程是什么样的，梳理清楚5个W（who、what、when、why、how），然后才是考虑如何进行产品设计。

有场景需求的不一定是真需求，但是没有场景的需求一定是伪需求。

永远不要停止学习：

产品经理的一生都在不停的学习，因为需求是在不断变化的，技术在不断进步，产品的竞争力是在与竞品对比过程中动态变化的，每个产品领域都会从蓝海走向红海。

面对新领域最好的办法是去学习，特别是去系统性学习，不要觉得读了几篇公众号、看了几个短视频就是学习了，碎片化学习很难支撑起专业性要求。系统学习最好的办法是上课、读书。

为了理解互联网、做好互联网，这期间我大概看了不下20本行业书籍吧，虽然里面一半以上的书是为了挣出版费的，但是最终我也学到一些知识，就当是个转化漏斗吧。

二、成为产品总监

随着公司的业务不断发展，用户数量逐渐增多，公司决定将产品职责从技术部门和运营部门剥离出来整合到一起，成立专门的产品部门来负责公司产品管理工作。我被任命为产品部门负责人。

虽然没有成立产品部之前主要产品工作都是我在管理，但是前后还是有很大差异。

公司视野与行业视野：

我开始参加公司管理会议，更清晰地理解公司的战略目标和各项重要工作的决策考虑过程。我更清楚地理解产品的工作在公司拼图中的位置，也更理解上下游部门的工作目标和工作难处。这个变化让我对任务分配和部门合作有了更正确的理解和配合，一切都是为了公司目标服务。

我开始思考做好公司产品工作需要补齐哪些环节。我招聘了1个用研和1个数据产品。这个工作前期也走了一些弯路，摸索了一段时间。

与此同时，对竞品和市场环境的跟踪工作也成了日常工作的一环，有专人负责，定期汇报。这个跟踪更多是站在产品角度，竞品更新了什么内容，行业监管政策有哪些变化等。

被动创造价值到主动创造价值：

在技术部门时做产品主要考虑的是如何实现上游的需求，用专业能力如期实现上游需求就是最大的价值，需求方的权重远高于用户的权重。成立独立部门后开始考虑如何主动创造价值，考虑用户价值，这里有认知的改变也有KPI的压力。

我们思考用户需要什么，流程哪里可以更好，能为公司决策提供哪些支持。

举个大家好理解的例子：公司领导和交易运营同学随时关注交易量，每次在群里问的时候都需要运营同学去后台查，运营同学查起来不方便，响应也不及时，特别是非工作时间。

为了解决领导和运营同学交易量等常规数据获取不方便的问题，我们在钉钉里面加了个简单的驾驶舱查询，这样领导也方便了，运营同学也不用吃着饭赶回去查数据了，大家的满意度都提升了。

这个钉钉驾驶舱后面不断低成本迭代，很好地服务了公司领导和运营部门，特别是后来我自己管理运营工作时深度使用。

更系统化、专业化的产品思考方法：

经过几年的积累，产品越来越复杂，经常出现头痛医头脚痛医脚的问题。我们开始系统性思考，这些功能之间的逻辑关系和价值目标是什么，怎么做才更合理，这其实就是一个产品架构的问题。这个思考直接驱动了后续的App新版本研发，从根本上解决问题。

专业化比如减少日常方案设计与讨论过程中凭经验凭感觉凭权威的情况，在能数据量化和驱动的地方尽量数据决策，比如对ABTEST的引入，比如对用户体验问题的判断方法。

以用户体验为例，以前都是公说公有理婆说婆有理，没有衡量标准，但是实际上用户体验最终要体现在数据上，某个体验问题影响什么指标，不同的方案对指标有什么不同的影响，我们不再纠结于按钮颜色大小流程顺序等问题上。

思考产品问题时会使用到战略层、范围层、结构层、框架层、表现层思考框架。上一层决定下一层，上一层对了下一次才有意义，要抓住问题的根本点在哪一层，不要只看到表像。

人的认知是螺旋状迭代的，只有经历过才能有认知的迭代，只有认知的迭代才会有行动的改变。我们在这个阶段也走了很多弯路，比如从无数据到唯数据，某些情况会被KPI而非价值驱动。

本文由 @产品大辰 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议