新产品孕育记：PM如何把一款产品从0带到1

这篇文章是我6月份写的，在负责的产品上线之后写的反思总结。我想这个过程，对于中小创公司的产品经理来说会有一定的借鉴意义。因为中小创公司并不像大公司那样把岗位分的非常细，产品经理经常会负责除了开发测试的其他工作。对于大公司的产品经理，我想就当做一个案例的了解吧。

从4月中旬开始做选股宝产品，开发一个月，测试两周，最终App在6月底上线。作为一个新人，能够有机会负责做一个全新的产品，是机遇也是挑战，路上遇到的坑坑洼洼也是一笔宝贵的财富。

话不多说，开始吧。先说说产品线的情况：

移动网页：用来App没上线前的预热、充当各种webview以及分享页面； ios版/Android版：移动App； 内容生产后台CMS：内容生产平台；

狼蚁网站SEO优化我将按照立项、产品设计、开发、测试、上线五个阶段来分别进行自我回测。

第一阶段：立项

大抵创业公司的立项都是CEO敲出一个idea，然后就干的吧？

这个阶段，我没怎么参与，不过也没有打酱油：一边通过处理公司内部需求熟悉公司业务，一边实战炒股同时学习各种k线图、技术指标、基本面等等知识，把自己变成股民来体会股民的心态以及行为。

然后，就是机会来临吧，总负责人皮总让我一起跟进这个项目，Let's do it

从结果论上来说，炒股这个行为也让自己做这款产品相对来说更加得心应手，因为对需求对用户理解的更深。

第二阶段：产品设计

这时候，大抵开始了作死模式，过程如下：

和总负责人皮总沟通、撕逼产品的方向、功能； 基于上面的前提，做出了App的动态原型1.0.0（基本功能、交互完善）； 1.0.0的产品方向被CEO枪毙； 和CEO&皮总沟通，做出App动态原型1.0.1； 再被局部枪毙； 产品总负责人变成了衣肿大人； 和衣肿&CEO沟通，做出了App动态原型1.0.2，以及后台CMS动态原型1.0.0；

这个阶段总结下来，有以下几点值得注意：

1、App动态原型1.0.0生产前，我默认了皮总和CEO是想法一致的，但事实上并不是，还相差略大，这给后面不断改稿埋下坑点；

可以做更好：尤其是一个新生的产品，它的方向会直接影响到是否有资源匹配、后续的功能如何以及呈现方式如何等，因此，在开始着手做原型之前，一定要确认大家在方向上想法是一致的。如果不一致，那就“撕”到大致一致；

2、在第1点的情况下，画了比较保真的原型。但是对产品方向的想法都不一致，再保真的动态原型也无用。虽然为了缩短时间，都是通宵赶稿出来的，然而这就跟“通宵念书很勤苦”一样，感动的是自己而已，如果多注意到一层，就不会这样了。

可以做更好：建议先画手稿和决策人进行沟通，得到大致一致之后，再去画比较保真的原型图，那么很多无用功夫就可以避免。

3、竞品分析做的远远不够，无论广度或是深度。当初觉得市面上没有内容，原来只不过是因为看的少。这个项目当初是比较赶着要做完上线，希望抓住牛市行情进行推广，因此在时间上非常的匆忙。

可以做更好：在时间匆忙的情况下，对于竞品分析这块我确实没有更好的方法来解决这个问题。不过想说一点：产品经理最好是自己产品的忠实用户。这样，对于产品的可改进点以及用户要什么，都会理解的更深。不仅对1.0的原型设计有帮助，同时对1.0之后的需求迭代也会有很大的助力。

4、虽然内心以及笔头都有规划过后面的功能，但是交付研发只给了1.0版本的东西，导致技术在架构上面容易没扩展性。以现在迭代几个版本的角度看，有些地方因为加了一些功能，确实导致了页面的重构。

可以做更好：建议把能够达到稳定版要求的原型都呈现出来，这样开发在代码设计的时候就更容易考虑到一些以后可能的情况吧应该。

第三阶段：开发

这阶段，可以称之为“无人领头并行工作死翘翘”模式。这部分很大原因是，没有领头人的同时追求“快”，匆忙开发。

1、整个团队的成员都非常年轻，也没有做0-1项目的经验，在产品设计、UI设计、开发过程中，都存在经验问题。但是我觉得很可贵的是，整个团队都非常合作和团结。虽然大家做的很累，但最终，都把这个产品扛下来了。关于这点，并没有什么可更好的地方，毕竟，资源有限的情况下，团队和个人都需要时间成长。

2、在1的情况下，产品设计阶段的原型图只是一个大概的图，细节和逻辑并不完善。 细节不完善存在的问题是，当初画原型图就是个短时间的事情，有些地方的交互觉得并不那么符合习惯，那么就会存在修改了某个按钮的位置，然后设计师就得跟着改，前端开发也得跟着改，然后恶性循环，大家都很累；逻辑不完善存在的问题是，我一边补充更细的边界条件，开发人员一边进行开发，那么会造成开发和沟通上的压力。

可以做更好：即使并行工作的前提无法改变，那么可以让开发童鞋们先做功能实现，再统一修改UI，与此同时，产品和设计师确认好UI，避免开发在做功能的情况下还要一次又一次的修改UI；

3、因为要快，所以很多技术上的实现，能简单就简单，能套用公司原有的的东西就套用，这个在1.0项目上没有办法。但是从迭代几个版本的眼光来看，确实在一些技术的实现上，因为之前做的太耦合，导致后面又重构。

4、在开发过程中，由于上文第2点，存在开发过程中，需求小变更的情况，但是这个变更没有落在纸上。不是说落在纸面可以免责，而是口头沟通的问题在于，不能保证各自双方记忆力的完整。同时，某个需求如果同时涉及前后端人员，而大家没有全部知晓，也是隐患的存在；

可以做更好：如果需求有变更，不管是因为产品设计原因，还是因为技术暂时实现原因进行的折衷，都需要进行对应的记录标示清楚，以便于之后查询以及后续人员的产品了解。

5、也是由于上文第2、3点，产品的某部分内容是由公司原来的管理后台生产，要满足这种工作场景，必须对其进行部分的改造，而这个改造会影响到整个公司原有的产品线的内容（网站、ios & android的App）。在第一次在改造的过程中只考虑网站，却忘记了App端，好在第一次开发量不大，但是也是浪费了人力。