创业初期产品研发应避免的几个坑

有些坑即使知道了也会跳进去，但有些坑可以通过学习而避免。

创业是一条不归路，当真正走上创业之路时，你会发现有无数的坑在等着你往里面跳。其中，有些坑即便知道是坑可能也会往里面跳，而有些坑可以通过学习而避免，还有一些必须亲身经历才知道那坑。

上周末参加了投缘帮的创始人技术课，原本在脑海中模糊不成型的概念在讲师的讲解下慢慢变得清晰了。在这里归纳总结一下分享给大家。

公司发展现状

创始人信心满满，拉动各方资源，创建团队，启动项目。然而，3个月过去了，项目开发进度遥遥无期，需求越做越大，团队需要的人越来越多。

外包不靠谱，换了几波人，项目快被拖死。

好不容易上线，用户量惨淡，开发产品已经将启动资金用光，无法进行宣传推广……

于是，创业公司卒于3个月。

手里有一把锤子，看什么都像钉子

通常情况下，当我们手里有一把锤子时，看什么都像钉子。创世人有一个好的创意，把它想象的无比宏大完美。这没错，因为正是有这样的格局才能驱动去启动一个项目。但在项目初期，资金、人员等方面不足，想法还未被验证的时候，大刀阔斧的去干往往会被耗死在路上。

同样的，产品人员醉心于如何设计出丰富完美的功能；开发人员想的是如何做出支持亿万级高并发的项目……如此一来，项目的工期将变得无限的长，人员需求变得无限的多，最终想法还没被验证，资源已经耗费殆尽。

创业初期，面对如此情况，真正需要做的只有一件事，那就是降维开发甚至不做开发，具体涉及到以下几个方面。

够用的产品

在初期阶段，不要求产品的功能有多么的完美，只需要够用即可。那么，够用的标准是什么？

构建独特的产品模型：想清楚你的产品与别人的产品不一样的地方是什么，解决了用户的什么痛点，市面上的针对此问题有什么好的解决方案，是否能够找到更简单粗暴的解决方案等。
实现核心业务逻辑：找到一条主线，用3到5步解决用户的问题。初期产品不怕low，就怕解决不了用户的问题。当能够解决用户问题时，丑陋一些用户也是可以接受的。
其他可以从简：一个产品常用的功能只有20%；一些看似简单的功能比如注册登录，会耗费大量的开发资源，可以考虑直接使用第三方的代替比如微信登录。与核心功能无关的，都可以做减法。
别开发，用成熟产品：如果业务模型成熟，可考虑使用开源服务或收费的SaaS服务。这样可以极大的缩短开发周期，减少开发成本。

产品初期容易犯的错误

产品初期拿到一些启动资金或创始人技术出身，往往容易犯一个错误那就是想建立一个完整的研发团队。这会导致，上线前技术忙死，上线后工作量不饱和。如果将研发成本使用到运营上，效果会更好。在此阶段能找靠谱的外包来搞定，就不要考虑自建团队。
招聘人员时，过于追求高大上，其实如果业务不是特别复杂，招聘2-3年工作经验的人开发人员，基本上能搞定大多数的需求。
产品的初期设计没有为运营留下入口，导致上线之后需要快速发布新的版本来进行接入。
新产品就做积分、签到等需要长时间才有效果的功能。
单纯的抄袭其他产品。

亲身犯过的错误

说说自己的亲身经历，在开发产品时犯的错误，其实这些错误在最开始的时候有些已经隐隐约约感受到了，但由于各种原因没有及时制止。

功能上没有做减法：开发初期，设计了完美的方案，把用户的基本都做了，比如注册、登录（多种方式）、基本信息设置等等，花费了大量的时间。现在想想，这些其实都可以不做，只用一个微信登录即可，两三天就完成的功能，如果像上面这样都做，可能得两三周。
设计上过于复杂化：期初的想法是做出一个完美的产品，通过完美的界面来吸引用户，结果把界面设计的过度复杂，开发周期就变得很长。如果只是把核心的功能通过3-5个页面完成，也就能够快速的试错，得到市场的反馈。
项目周期的迭代：没能够做到快速迭代，比如两周一个版本。没有很好的把控项目进度。
成熟产品的使用：初期阶段没有直接使用成熟的产品，而是想着自己去开发，耽搁了不少工期。

成长的过程

曾经和朋友接了一个私活，很小的项目，他主张使用分布式架构（dubbo+zk），理由是可以顺便学习一下，我没能够说服他。后来的结果就是本来只用一个项目就可以完成的事，拆分了N个项目。无论从开发调试的难度和部署占用服务器的资源方面对我们都造成了极大的苦恼，甚至后来都不愿碰那个项目。为这事我“嘲笑”了他好几年。

其实犯错误并不可怕，只有亲身经历了一些错误，并承担错误的结果，才能铭记于心。经历一些事，跳进一些坑，成长了便是最好的结果。

程序新视界
关注程序员的职场生涯，大量优质学习资源