PM要尽快摆脱对产品文档的依赖才能走向成熟

19 评论 15645 浏览 129 收藏 7 分钟

十年前,没有人告诉他产品原型和文档应该怎么写;十年后,他想与你分享产品文档的经验心得。enjoy~

最近面试产品经理时最苦恼的就是大多数PM拿画原型当自己的看家本领。绝大多数PM对于原型的使用都是错误的,直接导致无效的团队推动力。造成这个现象的最根本原因是自己本身缺少目标感——不去深思产品成功后应有的模样,而过于追求过程中的自我认可,寻求自嗨。

关于产品原型,你要记住两点真相:

  1. 产品原型只是产品成功路上的垫脚石,就是要吸引大家来踩,踩过去了团队才能往前走。
  2. 通过一份文档来解决问题的想法是幼稚的,文档最大的价值是信息沉淀以方便日后回顾。但更多时候是因为大多数人都不愿承担责任,才抬升了它的重要性。

所以,你在设计和使用这块“垫脚石”时,一定要首先注意:

  1. 当前团队处于什么阶段?目标是什么?接收对象是谁?
  2. 不要拿产品原型或文档去说事儿,要开放,要就事儿论事儿!
  3. 千万不要爱上自己的原型和文档,你爱的是用户,而且要让团队知道。

分享一下我作为产品新人时自己的一些技巧吧。

应该是十年前的样子,我第一次加入到一个人数不多的互联创业团队中,没有人告诉我产品原型和文档应该怎么写,在实际的推进中我产生了这几方面的困惑:

  1. 不知道要写多细。到现在都清晰记得我问身边的技术大牛要不要标清字号时他甩来到白眼。
  2. 无法用一份原型来统一回答技术与设计伙伴的问题。比如Axure很适合做页面逻辑的表达,但无法表达出数据以及接口结构。现在很多原型工具也有这个问题,虽然能让你低成本拿到demo,但无法对数据结构进行讨论,影响PM对于成本以及未来可能性的把控。
  3. 总会有人产生疑问。会上定会下改,今天定明天改。

那是一个黑暗的时期,不仅工作量大还非常没有效率——所有的改动都好像很急很重要,但并没有对产品最终的效果起到明显的推进作用。感觉自己就像一个整天到处救火队的消防员,成天被点火的人愚弄。那时真的很讨厌那些点火的人,可又不知道这些人是谁。是同事?老板?难道在可以刁难我?但我们私下还真的挺开心的。而且大家还给了我很多建议,最多的一句就是“再多想想”。

当时我有一个习惯,就是回复完所有当天邮箱里的产品反馈再下班。记得有天晚上,公司剩我一个人,很疲惫地看着反馈列表时,发现了一条夸我们产品好用的评价。我不知道那条评价被我反复看了多少遍,一个原因是确实激动,另一个原因是用户并没有写出到底是哪个功能做的好,他只说目前只有我们能够帮助他随时找到身边的商家。我突然明白了眼下最重要的事情是什么——回复邮件表示感谢之后,继续问他还有什么不方便之处。

那晚上,我的脑海里出现了一幅图:左边是一个用户,右边是他想要的苹果,中间是一个迷宫。我要最快地带他走出迷宫,拿到他渴望的那个苹果。

我突然发现之前我的做法都是错的。我把团队伙伴和老板当成了我的服务目标——他们本应是站在我身边一同为用户服务的人。我们如何才能一起行动呢?其实很简单,我们要一起面对用户的问题。换句话说,我们面对的问题必须是来自用户的。

后来我主动找公司进行如下改动——

  • 搭建redmine, 建立用户问题库(现在的工具很多,推荐confluence)
  • 仅针对问题进行讨论。如果建议来自同事或老板,我也当做用户一样对待
  • 针对每个问题进行原型提案,大家直接抛砖,甚至工程师也可以一起提原型
  • 最终由我来主持会议确定优先级,并按顺序打包成版本计划——路线图出来了

这个带来的直接效果是,团队与我站在同一战壕,都对如何更高效地解决问题产生兴趣。除此之外还有几个非常棒的效果:

  1. 我不用再写繁冗的产品文档,仅根据问题进行提案,组织讨论。
  2. 我开始使用手绘来表达原型,因为足够了,更多的细节设计师会跟进。或者他的主意更好。
  3. 团队非常清楚眼下的重点,知道要做什么,大家关系更加融洽了。

我终于品尝到了作为一名产品经理的成就和愉悦感

在多年之后,我才从《每个伟大的产品背后》这篇文章中再次确认产品经理无授权管理的深意:

  1. 不要追求成为团队最厉害的人,要做最会发现问题的人。
  2. 不要在意文档的质量,要关注团队使用文档的动机
  3. 产品经理是管理岗,要让团队中的专业成员得到参与感,并发挥长处。

确实,完美的文档并不存在!从此之后,我永远只是最快抛砖的人。抛得越快,团队跑得越快!

产品经理要尽快摆脱对产品文档的依赖才能走向成熟,越快越好:)

 

作者:王珏,WETOUCH互联咨询Founder,十一年互联老牛,前联想、腾讯资深PM

本文由 @王珏 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 其实我是来寻求一份固定的产品文档要领,当然我感觉你说的都是有一定基础功以后的蜕变,在没有任何概念的情况下我无法进行进一步蜕化,从而加入自己的想法和自己的观察,这一切的一切都是来源于基本功,其实我还是对你刚成为产品那段路感兴趣因为我现在急需的是这段经验。

    来自浙江 回复
  2. 产品需求不止来自于用户啊,还有来自于老板、竞品、运营或者战略需求等等,比如微信的红包功能,这个就明显不来自于用户问题。所以用户问题库也只是需求管理里的一部分,不能以偏概全

    来自广东 回复
    1. 你把“用户”这两个字搞窄了。

      来自北京 回复
    2. 任何人都能是“用户”吧,只是分了不同的群体。

      来自湖北 回复
  3. 我们现在就是使用worktile使用管理需求(点)和问题的,可能和作者说的效果接近,但是目前需求质量、历史追溯上觉得有点问题。作者大大在执行的过程中,最新的、完整的一份文档或者原型还是有的吗?

    来自江苏 回复
    1. 需求质量和追溯效果来自于两个方面:1. 对于问题本质的深挖;2.量化指标的对应设计。我们会花更多的时间把这两件事搞清楚。在这个过程中鼓励并允许设计师和工程师同事直接给出方案,并在Dev测试环境下进行体验和近一步讨论。偶尔会用原型进行辅助,但谈不上完整,很多都是手稿。

      来自北京 回复
  4. 好奇想问问,何谓冗杂的产品文档呢?目前在一家较大的公司实习,部门的产品线已经比较完善了,我经手的文档都是拆分成一个个需求来进行撰写然后开会讨论的。如楼主说的冗杂或说详细的产品文档格式只在一些前几年的网课上有听到过。所以是不是说目前行业内较完善的产品基本已经不会出现冗杂的产品文档了?

    来自广东 回复
    1. 这个不一定。PM应该去考虑如何让团队之间的协作更加高效,能够快些更快些。推荐一本书《Rework》

      来自北京 回复
  5. 最后一句很棒——没有问题就没有目标!

    来自北京 回复
  6. 不能为了写文档而写文档,虽说是信息沉淀的产物,但真的无法做到完美解决问题的目的;就算写完文档画完原型,每次沟通之后还是会改改改,效率真的很低。很受益,没有问题就没有目标~~

    来自陕西 回复
  7. 确实,产品经理应该要很好的理解自己的岗位,

    回复
    1. 是的,理解自己在团队中的贡献。

      来自北京 回复
  8. 真实刚需啊,最近跟开发沟通产品改版的需求方案,每次沟通下来都被反馈“再多想想”,之前已确认的方案会后也会被反馈说“再想想,或者会被建议怎样是不是更好”,真的是不知道怎么去做产品的需求方案比较好,感谢您的分享,会按照这个思路去尝试改变:)

    来自上海 回复
    1. 加油

      来自北京 回复
  9. 值得思考的话题

    来自广东 回复
  10. 我遇到的问题是,要么评审的时候没人提建议,要么抬杠,计较半天毫无用处的细节😅,这突如其来的心塞是怎么一回事?

    回复
    1. 从来不会有完美的方案,你需要把目标问题单独拿出来和团队分享和讨论。方案可以辅助你把问题谈得更清楚一些,并获得更多意见。

      来自北京 回复
  11. 原型是和技术、运营介绍你想法的demo,文档是作为记录为后来人了解产品迭代轨迹的

    回复
    1. 它们都是用来定位和追溯用户问题的。没有问题就没有目标,单纯的迭代轨迹没有任何意义。

      来自北京 回复