知易行难 | 新项目MVP版本上线后,我总结的一些踩坑点

6 评论 5199 浏览 24 收藏 13 分钟

编辑导语:在项目中,我们或许会犯一下小错误,很多人觉得不要紧,没有犯大错就行了。其实,这样一个个小错误才是大问题,它会影响项目的上线情况。作者通过其项目经验,总结了一些自己踩过的坑,与你分享,希望你在成长路上能够吸取教训。

大概在11月中旬的时候,我负责的新项目MVP版本就算是正式上线了。虽然团队内部已经搞过了一个简单的总结和反思会议,但是我觉得在产品经理个人成长的角度来看,有些东西还可以继续挖掘一下,所以我写下了这一篇文章。

MVP版本上线虽然强调小步快跑,快速试错,也能容忍很多不足,但是其中很多细节或暴露的问题,都是很值得总结和沉淀的,毕竟从0到1的机会不会太多。

知易行难 | 新项目MVP版本上线后,我总结的一些踩坑点

11月中旬做总结时候记录的初稿

我从事产品经理行业其实并没有很长,也就是大概4年多的时间,大大小小做过的项目大概十来个,真正从0到1的项目也做过挺多。再加上这次的项目和之前的项目业务内容几乎是一致的,所以我自信这次哪怕是从0开始组建团队,再去从0到1做项目也应该不会踩很多坑。

但是从实际上线的结果来看,似乎我还是被打脸了。虽然大问题不是很多,但是小问题其实还是足够给我上一课了。我将这些问题整理出来,一方面是对自己的过往的回顾和沉淀,另外一方面也希望未来自己在类似事件上可以做得更好,最后也希望能对阅读这篇文章的朋友一些帮助。

一、关键性原则的总结

1. 只有理解了需求,才能理解什么是真正的MVP

需求和MVP这两个词几乎是产品经理天天挂在嘴边的,但是这两者的关系要正在的领悟和使用,还是得要实际项目真正验证了之后才会有切身的感觉。

在前期的时候,由于人力资源不足,客户资源不足,压根没时间调研和访谈,很多需求都是根据之前的个人经验推出来的,或者是转了多手之后来到产品经理的手里。

于是在做产品规划,产品特性梳理,优先级和其他信息决策的时候,往往很难把控住符合MVP的需求到底是哪些。最后该做的可能只做了一点点,不该做的或者不是这个阶段做的却做了很多。

说白了就是,本应该是好钢用在刀刃上,可结果却用在了刀把了,没有击中要害。

所以,要想确定MVP自己想要什么,本质上还是得要理清楚需求,而需求从哪里来呢?

肯定是从实际的客户上来,如果没有客户或者相对明确的用户画像,那么起码应该少量多次的试探,而不是一把梭哈到一个不确定的因素上去。

2. 简单,简单,一定要简单。删除,删除,直到不能再删除为止

对于SaaS类的B端产品来说,由于需要满足各种客户的不同的业务场景,肯定是希望自己的系统做得灵活和强大。

灵活意味着用户自由配置的空间就很大,可以动态地调整系统逻辑和功能,而开发者也不用频繁的发版或者定制。

但是对于MVP版本的产品来说,产品经理在这个时刻去思考这种灵活配置化的功能是极度危险的。因为每次在设计功能的时候总是会想着以后这个地方要灵活,要可配置,要支持自定义,然后就会情不自禁的留口子,留缓冲的余地。最后导致出来的功能相对复杂,且其他辅助类功能没有形成闭环,最后导致用户体验不佳。

本来可以给用户一个写死的,确定性强的解决方案和流程,但是却做成了给用户多个选择,但是用户选择了之后可能会遇到死胡同(有些功能没有闭环)的尴尬场景。

「简单」意味着确定性强,而给多了选择,留多了口子,肯定会变得「复杂」。

3. 看竞品有可能犯错,但是不会走歪路

对于新产品来说,学习和参考竞品的方案是常有的事,这几乎可以算是业内不成文的规定了。

但是作为产品经理来讲,别人虽然做得很好,自己在学习的时候肯定不会一股脑全部抄过来,肯定会加一些自己的理解,或者是刻意地和竞品做的不太一样。

这算是产品经理的态度,也可以理解为一种渴望超越而不服气的精神,总感觉自己可以做得更好一些。

于是乎,这次MVP很多的大框架和主流程等,我都有意识的和竞品做的不太一样,同时也沿用了大量自己的过往的项目经验。

最后产品肯定可以快速完成,但是在实际交付客户试用体验的时候,就发现花了很多时间做的功能用户并不太认同,反而是一些和竞品做得比较类似的基础功能,客户却很喜欢。

最根本的原因就是两套方案面向的客户群体,用户画像是不一样的,而我的方案瞄准的恰恰不是MVP阶段的目标客户群体,所以试用的时候才会被用户吐槽用的太麻烦,不太好用,建议我们做的简单一些。

看竞品的时候,除了基础的功能和业务逻辑之外, 还有一个很关键的因素就是看双方的用户画像群体是不是一致。如果大方向就不一致了,那么细节的功能点参考起来就很容易走歪了。

4. 相似的项目经验是好处,也是坏处

之前我写过一篇文章,讲有经验的产品经理反而容易吃亏,其实就是从这个项目引发的感慨。

相似的项目经验看似很美好,直接上手可用,直接Copy一套,但是隐藏在各处的坑坑洼洼的细节,积累多了还是很容易让老司机翻车。

关于这一块我不再赘述了,感兴趣的可以去看我之前写的文章《纳尼?有经验的产品经理反而容易吃亏?》

想要提醒大家的就是:别困在过往经历中,随时打破更新自己的固有观念,才能更加有效地避开这些小坑小洼。

二、细节方面的总结

知易行难 | 新项目MVP版本上线后,我总结的一些踩坑点

一些细节方面做得不好的地方

1. 功能尽量一次性闭环,别做一半留一半,总是留点边边角角会给自己挖坑。闭环是指核心流程的功能要做完,而不是所有内容做完才是闭环。

2. MVP期间如果要赶工期,那么就要考虑减少接口的开发,例如查询,提交,删除,频率低的异常功能等,很少用上的,不确定能不能用上的,一律就先不做了。

3. 减少非必要字段和功能的拓展,当前用不上就别加,加了再去掉就很麻烦。很多时候会考虑未来这个地方要拓展,所有就留着一个字段放在那里,结果前后端理解有差异,测试理解也有差异,该做的漏了做,不该做的却做上去了,徒增麻烦。

4. 在MVP期间,太远的事别想,太复杂的方案别想,太难落地的方案别想。先确定一个基础的目标,先完成再完美。初期以人工+系统的方式解决也未尝不可,不一定任何事情都需要用系统来解决,别陷入“手里有锤子,看啥都是钉子”的怪圈中。

5. 设计核心业务方案的时候,别想着优化用户体验或者交互问题,琐碎的事情专门去做,效率更高。例如项目初期的时候,没有UI,没有标准组件库,然后在出原型的时候一方面要考虑业务的问题,另外一方面要考虑前端交付的问题,最后导致产品出原型慢,前端看到的交付物也丢三落四的,反而效率不高。还不如先专心搞业务的事情,然后统一时间或者让专人来负责原型标准化组件,与前端交付的问题。

6. 产品经理要敢于认错,方案有问题,决策有问题,错了就是错了,坦坦荡荡地承认、道歉,然后及时改正。别羞于承认错误而固执坚持,最终项目失败,辜负团队众多同事的心血,这样的后果更加严重。

7. 当面说,小会议说,然后文档说,需要循序渐进地来推进。很多时候产品经理自己写了很多规范和标准放在原型的某个角落,然后群里@各位开发、测试去看一下,这种情况下大多数人都不会去看,只有到用的时候,出问题的时候才回去查文档。团队协作的规范推动是一个急不得的事情,只要还有问题没解决,就需要不断地强调和推动,过程会很累,但是这必不可少。

8. 要给团队清晰明确的规划和指令,未来要做什么,要做到什么程度,这些规划可能由于某些东西还不够清晰,所以只存在产品经理自己的文档里。不清晰的规划别乱公布,如果需要公布则最好做好相应的注释说明或者通过会议+文档的形式传达。对产品经理来说,职业天性就是和模糊不定的东西打交道,而对开发和测试来说,清晰和准确无误的信息是他们特别在意关注的。所以产品需要将不确定性转为确定性,将模糊的东西清晰化后,再准确无误地传达给他们。

#专栏作家#

我叫维他命(Vitamin),微信公众号:PM维他命。前PHPer,做过在线教育类产品,也做过4年多的跨境仓储物流方向的产品,目前是一位外贸SaaS领域的供应链产品经理。主要专注于WMS/OMS/TMS/BMS/ERP等领域,分享供应链相关的产品知识。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 「简单」意味着确定性强,可以应用到生活中任何事情上

    来自广东 回复
  2. 对接b端和c端,一定要简单在简短,用最少的信息进行营销,才能准确

    来自江西 回复
  3. MVP总的来说还是需求端的概念,还是要从4c理论去研究,不能太复杂也不能太简单

    来自江西 回复
    1. 是的,有道理

      来自广东 回复
  4. 只有我看到MVP还只想着是游戏里面最头铁的那个吗,果然还是专业知识看的太少了

    来自江西 回复
    1. 本来我没想到那里去,结果你一说,我也发现这两个词竟然是一样的,我要开始错乱了 😱

      来自广东 回复