一、产品不等于业务，搭建一个新的业务架构不等于创造一款新的产品-k8凯发天生赢家
本文作者依据自身工作中项目实践的所思所想，从5个方面出发并结合案例，分享了0到1搭建业务的相关经验，供大家一同参考和学习。
我们常常听到的“ios架构工程师“、”高级产品架构师“，但是不是很少听到有关于业务架构的搭建？
在很多中小型互联网公司，确定开拓一项新业务之后，都是在不断试错的过程中搭建业务架构，而这其中涵盖了对于业务模式的确立、商业模式的探索、组织架构的调整、工作流程的规范、团队规模的预留等等；
如果自己有幸参与这个过程，将会是一个很艰难但是又很宝贵的机会。本文就想以笔者产品经理及产品运营道路上一些0-1项目的经历提取，分享一些0-1业务搭建的经验。
在讲这一段之前，我们先重现一段场景，某知名教育互联网公司运营与产品总监的对话如下：
运营：“我们在进行用户调研的时候发现，很多用户在进行课程试听的过程中未出席，是不是因为我们的销售模式有一定的使用障碍？用户路径过长？我们可不可以考虑优2·化这个路径，实现系统约课？“
产品总监：“你的这个想法我们已经在实现阶段了，现在确实话费大量人力在这一块儿，我们要实现产品代替人工，提高人效！“
运营：“全部替代吗？目前系统可以支撑起来咱们的用户需求吗？需不需要过度？”
产品总监：“这个我们也会考虑，到时候同步你们。“
以上这段对话，看起来是不是十分和谐，似乎一个全新的方案即将诞生，一场完美的配合即将上演，然而，我们揭开表面看本质，在这个需求中，运营同学提到的：“系统约课”，是否可以依靠一款系统或者产品就完全解决呢？我们来针对这个例子进行一下场景拆解，解决这一痛点，我们需要考虑的问题是什么：
表现层：用户路径缩短，降低用户决策成本，提高销售人效；
产品层：产品提供前端到后台的系统支持；
业务层：业务模式从电销转为sop，客单价、销售方式、运营模式是否会受到影响？现有的就按课程产品是否适用于sop流程，是否应创新课程形态进行相应匹配？
人力层：去掉人力电话约课之后，效果是否可以完全替代电销？人力无法回滚。
这些还不是全部的问题，还涉及到新用户的获客渠道和老用户的维护等等一系列问题，我们就会发现，这不是一款新的产品或者一项新的功能就能解决的，而是涉及到从前到后一系列的改动，而这样的改动是否真的值得，是应该去试错，还是应该去创新？
以上的例子，我只想表达我的一个观点：产品不等于业务，但业务可以衍生出产品。
稳定的商业变现模式是很多互联网产品追求的共同目标，可很多业务在开创前，过度的考虑用户量级、市场份额的占据，对后期商业模式的发展只是有大范围的规划，而没有细致的思考，所以出现很多产品“生于获客，死于变现”，大量的融资做产品，但最后由于无法变现无法转化而走向灭亡的公司多不胜数。
就举例说会员制的音乐类、社交类、新闻类、健身类这些非刚需且竞品众多的app，到一定用户量级之后如何促使用户转化及稳定变现就是一个很困难的问题，毕竟保证盈利才是一家公司的长久生存之道。
for eg：健身领域独角兽keep，典型的非刚需类产品，但线上健身对于目前的市场来说其实是一个很好的机会，目标用户的消费力也偏高，keep在集中做会员制服务这一点上却没有做好服务，而选择了在融资后大量的发展硬件、商城及线下门店等难以快速盈利的项目，在mvp的商业模式没有彻底跑通的情况下投入大量的资金发展其它业务，是一件很危险的事情。总结大概是三点：
最开始没有想好这这一业务最后的目标是什么，是线上垄断，还是oto，还是整个行业的标新；
在融资后急于扩张规模及业务，跑得太快，忘记审视走的路是否是可以有一天可以变现的路，还是一条只砸钱不回钱的路；
没有将一件事情做到极致，就开始做第二件、第三件事，这是第二点的补充。
笔者还是很看好keep未来的发展，毕竟在这个有信仰的时代，“自律给你自由”这样的slogan确实可以深入人心，就看下一步怎么走了，是否能回到正轨，anyway，服务好用户是第一位，服务号会员准没错。
不是所有的大公司都是规范的，也不是所有的小公司都是混乱的。有的小公司虽然人员规模小，但是人员配置合理，流程规范，这是对于之后的每一个环节都尤为重要的。近些年出现了一个深入业务条线的职位hrbp，根据一个具体的部门或者是业务线进行更为准确的人员管理和招聘，这是很合理的。
我们总听得到一句话，现在业务规模还小，不规范很正常，以后慢慢就好了。而混乱的流程只会导致加快业务的毙命。
还是举例说明，笔者是产品经理出身，但在中小厂是没有项目经理的，甚至一些更小的公司，甚至没有产品经理，老板就是产品经理，这个没有问题，我们不需要严格要求谁做什么事，但是我们需要最开始规划一条路线，而这条路线中，你的位置在哪里，就应该做好这个位置的事情。
管理与执行的区分；
每个岗位之间配合情况；
确保每一条业务线都有自己的own product；
岗位可以空缺或合并，但职责不能模糊。（例如：可以没有项目经理，但是要明确谁进行项目管理，谁对整体项目进度负责）
先说数据，数据是可以赋能业务的，无论是一款产品的埋点，还是到产品上线后的数据统计及分析，这一切动都是为了推进业务发展，提高业务能力，提高业务效率。
不要把赋能放在最后一步，毕竟一件锦上添花的事情如果做的太晚，就连雪中送炭都来不及了。
我们要数据的目的是什么？简单粗暴的说：
知道仗打的怎么样了；
知道哪只战队更强；
知道哪只战队或者哪个兵拖了后腿；
知道是不是战队没问题而是粮草去晚了？
大概对应的也就是我们那些熟知的数据了，行为数据、用户数据、产品数据、市场数据等等。
做数据是废人力的，是费脑子的，做分析也是，但是也许你不信，还有太多的公司在业务模式都已经成型了，才开始补上数据这个问题，在这过程中消耗掉的沉默成本可想而知。
咱们再说b端的同步搭建，这里说的b端针对不同的行业有不同的定义，我们通常会认为给企业内部员工使用的产品或者说管理内部使用的产品等是b端，但其实还包括大客户等也包含在内，一项业务的起步如果不考虑它将来会最强做大，那你可以不用考虑到这一点，但是如果想要做精做细，无论是产品还是运营，都不能放掉这一块儿。
以一个产品经理的角度来说明，优秀的产品经理做一个功能是为了之后做无数功能埋伏笔，无论从用户层面还是后端技术层面，都可以做到前瞻性。
举例来说，你接手一个新的项目，你要考虑它的载体是app还是小程序还是社群，这个决定不是一蹴而就，你当下的决定只适用于当下，有的目前适用与社群的项目业务之后随着规模的扩张会承载不了大体量，需要做统一收口，那你怎么去规划之后的收口路线，怎么去规划用户的生命周期管理，怎么去规划你的用户在哪个环节哪个场景进入、什么场景活跃，最后统一留存在哪一个生态，是否是一个长线项目，还是一个短期实验项目，你的roi是否可以承载等等。
能有从0到1开始的机会是难得的，但也是艰难的，证明自己并为后人铺路，没有那么容易，这篇文章只是以互联网思维写的冰山一角。
本文说的“业务”可大可小，可以大到一个全新领域，也可以小到改动一个当前的支付模式从而诞生一个新的支付业务等，但无论是大业务还是小业务，每一个环节做到细致，留下迭代的空间，就不会太差。
本文由 @安溥 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自unsplash，基于cc0协议。
给作者打赏，鼓励ta抓紧创作！