从零开始一个产品的过程，无疑都是一个漫长的路程，这个过程有的时候甚至是煎熬，不是三千米，也不是一万米。
回顾曾经所有经历的项目，成功的，或者失败的，都各自有它的缘由，但很多项目是从一开始就出现了差错，所以在整个复盘的过程，我把“定义”放在了最前面，它包括如何定义一个产品经理的角色，如何定义用户的角色，但他们最终又会回到了“人的问题”上。
这些问题，包括直接用户的问题和业务目标，更包括付费的决策者的问题和业务目标，当然也包括所在组织的业务目标。
1
人，始终是第一位的。
产品经理越做到后面，团队建设的能力越发重要。
从零开始做大型的项目 / 产品，除了沥青用户的角色，解决业务的问题之外，首要的其实是团队的问题需要“未雨绸缪”，越是大的产品 / 项目，团队的稳定性和匹配度越发产生重大的影响。
团队问题，我猜想很多时候我们并没有真正考虑过（我此前几乎没有考虑过），尽管多数情况下也都无需考虑。
但在完整的搭建一个平台型产品的时候，这一点很值得多花一些心思，因为组建一个好的团队，一定能够事半功倍。特别是对PM而言，其成功都来自于整个团队的努力。
团队的问题，可以换另外一句话来提出：我们（成员）为什么跟随你一起完成这个产品，也可以说是做完这个产品，对参与项目的全体成员来说意味着什么，是否有认知上的增益，还是有技术上的进步，等等。
这对于从零开始搭建一个产品置为关键。
通常来说，我们每每开发一个产品，通常都会至少包括研发、设计和测试岗位，大型的产品涉及的岗位会更多，队伍也会更为庞大。
管理是一门科学，界定清晰的边界范围是为了确保整个过程的可管理程度。产品经理的这种团队建设与管理的能力通常都会包括横向管理和纵向管理两个维度。
纵向管理
关于这一点，简单的概述就是了解业务目标，理解战略规划，管理期望，努力达成使命。
如果你是接受一个中途的项目，最好先能了解清楚这个问题是什么，为什么会发生，牵涉到什么层面，可能的话，进一步了解原来为什么没有做好。
所以，别忙着一上来就颠覆，全面的观察一遍，了解这些问题，摸清你工作的边界和禁区，是非常重要的事情。再想要搞革命也不迟到。
所谓没有调查就没有发言权，一定要有调查的成果，再针对每个问题提出具体的解决办法。
向上管理这件事，转载一位朋友的文章内容就是这样描述的：
请用一颗光明的心，去真正的认知自己的定位，真诚的认同老板的思路，真心的认识什么该做什么不该做。当你获得了老板的信任和全力支持之后，你也会惊讶的发现自己在对业务的认知上换了一个视角，上了一个台阶，发现自己可以从更高的角度来审视自己的工作和前景。
横向管理
好的组织结构能够有效激励团队，糟糕的组织结构则只会对各方形成掣肘，导致低效和内耗。
当你有条件、有机会去亲自挑选、组件团队的时候，应当考虑到团队与产品的匹配度，也要考虑团队的成长性和产品的生命周期相适应的问题。
更为关键的是，整个团队会呈现怎样的梯度，怎样的氛围，以及怎样的成长路线，否则在这个过程很可能团队溃散最终产品 / 项目失败。
所以，作为真正意义上的产品负责人，引导团队成员的多元化发展是必要的思考方向。不但保证了团队能够应对各种不同的实战需求，又充分保障了个人的存在价值和差异化成长。只有这样，团队能够健康成长，产品才能持续良好的运转。
这个话题，更为引申一点的就是，如何建立与强化团队的文化氛围和价值观。这当然是很遥远的话题了，但就眼前的项目而言，如果让团队持续相信这个的愿景是更为迫切的切入点。
在整个项目过程，要想办法尽量缩减“看热闹型”和“完成任务型”群体的比重和影响。
2
无规矩，不成方圆
想要成功的推动一个产品的落地，需要耗费很大的心力，结合过去的项目，高明的做法是能在项目开始之前明确一些基本性的原则，避免在项目过程中随意发生不必要的争执。
如果有机会统筹一个平台型的产品时，这一点随着项目的深入尤其重要。
产品原则，是产品发展的一个潜在标尺，指导着产品发展的方向，它代表着产品的定位与运营的逻辑，它涉及到UI、用户体验、也涉及到产品的需求优先级等一系列问题。
比如微信，到底要不要做“已读”标记，这个看起来是一个功能，其背后的逻辑就是到底是发信者视角还是读信者视角的问题。
产品原则，就像设定了一个评判尺度。有效的归置了在面临取舍时的判断标准。
1、MVP产品原则
指的是通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。
这个原则，根本目的就是要对需求进行快速的试错验证，而不是纠结某个点的UI和视觉问题（在产品的某些阶段，这些问题完全不值一提），其出发点就是避免团队耗费不必要的成本开发错误的产品功能。
2、数据导向原则
我们需要全员的数据意识，来降低错误的概率。
数据体现的过去，很多时候都会因为我们的过分解读和理解不够，而与事实发生偏移，我们需要数据，但不要去迷恋数据，有的时候不是数据越多越好，尽管通常情况下，数据的可靠性大于用户的反馈，更大于我们的经验和构想，但这不应该成为我们迷恋数据的借口。
这一点很难达成共识，除非你有足够的权威。
3、统一需求原则
这个原则简单来说，就是统一需求出入口，不要让需求满天飞，它包括需求的优先级处理和风险分析，也会带来产品质量和团队效率低下的问题。
这一点，同时也包括需求必须评审的基本要求，不要出现随意修改，随性发挥的情况，整个团队要有全员的质量意识，既要有自主性，也要有责任心。
4、变更原则
基本的思路就是在一定时间几点上冻结需求，而不是没完没了的变更加塞需求，不要为了追求某些“成果”而强行改变计划，打乱整个团队的节奏，特别是从零开始的产品，这种变更往往得不偿失，市场和用户不见得会因为我们想象中的“功能”而忽然变成喜爱你的产品。
这个原则和MVP原则是一脉相承，目的是为了快速试错，找准方向，而不是似是而非闷头折腾。
5、风险原则
这个原则，指的是及时预测发现风险，包括业务、技术、质量和团队的风险。甚至有些产品，还会涉及到一些人文的，社会的风险，都需要及时找到应对和解决的方案。
不同的产品，不同的团队和管理风格，应对风险的方式都会各自有很大的差异，作为产品经理，首先要理解所在的组织风格，尽早识别风险，并提出预警，协助和推动风险应对方案的落实到位。
6、其他原则
包括基本的会议规则，邮件的规范，等等。
举个邮件管理的例子。
当你的项目周期超过3个月，具有统一识别的邮件标题规范都能提高效率。
3
开工没有回头箭
真正从零开始做一款产品，可能远比我们想象中的要负责，而且越大型的产品，其复杂程度就会更高，涉及到的各方的关系和利益平衡，当然也更需要考虑用户价值和商业价值的平衡。
这个话题可能难有确切的答案，不同的组织都会有不同的风格。对产品经理而言，更为考验的是如何利用好现有的资源，快速拉起队伍，快速的试错，并且快乐的推动整个进程。
开弓没有回头箭，发吧。
Quclouds_数字营销商业自媒体。全球格局，移动·数据·技术的浪潮下，营销需要新势力，数字营销行业价值传递平台。
