产品经理成为原型人的七大迹象

编辑导语:产品经理的工作内容之一,就是实现需qiú方的需qiú,将假设的功能变为现实。然而,对于不少产品经理来说,随着工作曰复一曰的推进,逐渐变成了完成需qiú,开发新功能的“原型人”,产品经理成为原型人的七大迹象都有哪些呢?你是这样的产品经理吗?

发现很多初创XX都是Feature Factory(功能工厂),很多产品经理都是Axure People(原型人),需qiú方任意提“需qiú”,产品经理负责“需qiú”的实现,hú乱堆砌功能。

最典型的特点是“上线即完成”的心态(PS:一个版本上线了,交由需qiú方确定后,就什么都不管了,紧接着开始新的版本开发)。就像只是坐在工厂里,做出新功能,在liú水线上传递下去。

John列出了7种“功能工厂”团队的迹象(或者说产品经理作为原型人的迹象),读友可以看看,你中qiāng了么?

一、没有X规划X

有些产品经理从来没有参与XOKR规划和chāi分X,这其实是非常有隐患的。

因为产品需qiú的来源大部分来源于X需qiú,而X需qiú绝不是X同事拍脑袋产生的,而是基于整体的X规划。产品经理需要非常清晰接下来XOKR,基于X的方向制定有效的产品迭代计划。

能达成OKR,整个团队一片祥和,一旦偏差较大,团队凝聚力指数下降。所以制定版本迭代计划绝不是产品经理拍脑袋的,每一步都必须做好追溯。

再絮叨下OKR制定的步骤(建议定季度OKR,做月度chāi分):

  1. 季度最后一个月的月初(比如X初),需要和X负责人沟通下一个季度的XOKR,在月中进行XOKR述职;
  2. X中敲定下一季度OKR,并在会后做好邮件确定;
  3. 产品组依托于XOKR做产品版本计划形成产品路线图并内部宣讲确定;
  4. 并在月底之前同参与确认存档。

二、以“上线交付”来衡量版本完成

产品版本上线是一个非常重要的节点,标志着该版本在内部是可用状态,是否被用户接收?能否达到预期效果?尤其对于主版本号①调整是非常重要的问题。

需要注意两个方面:

  • 一方面是在普测时,邀请核心用户来测试体验(尤其是B端产品,一定要让客户试用),如果有条件的话,做下可用性测试②,遇到问题点可以作为接下来优化的版本;
  • 另一方面在上线后前三天做好数据整理和分析,看看是否有异常状况,持续在种子X/客户X做好吐槽点收集。持续1周反馈看效果,看后续优化动作。

C端产品做好用户“可用”后,后续X优化做到“易用”和使其产生“传播点”。B端产品做好客户“可用”后,后续X优化达到真正为B端“降低cāo作难度”和“提高工作效率”。

这才是产品经理需要持续去做的,也是产品经理X项目能快速成长的(PS:如果是外包呢?如果外包交付后,建议可以后续跟进下效果,并X下你认为比较好的运营策略和迭代方案)。

①版本号划分,John给了一张图说明:

产品经理成为原型人的七大迹象(多文档下载)

三、团队未做过项目复盘

项目复盘的目的是产品上线一段时间后或者某个活动结束后,项目部都需要有zhēn对性的对项目复盘。看看项目执行过程中的得分点和失分点,来实现向过去学xí,达到能力的提升。

复盘分为两个方向,zhēn对产品迭代过程中团队协作的复盘、zhēn对产品上线后产生的效果复盘。

再来把这两个点赘述下:

  • 团队协作:在协作过程中遇到了哪些问题?哪些可以形成沟通liú程并固定下来……(长时间用下来就形成了产品开发liú程方案);
  • 线上效果:X数据看线上的效果怎么样?用户对产品的使用怎么样?其中反馈在模版的活跃度、使用人数和对核心liú程的影响。

四、只注意细节,未深挖底层

不知道大家有没有遇到这种情况——“哼哧哼哧的把功能清单、liú程和原型梳理出来,反馈给X方,发现Xliú程并非如此?”

这个问题80%在于产品经理,主要是这几个原因:

1. X确认环节:深挖X方提出的需qiú

  • X方实际的目标是什么?(X目标看看方案是否切实可行,证明不是拍脑袋出来的)
  • X方实际的liú程是怎样的?(按照实际cāo作场景一一说明,能够形成实际liú程的闭环,看看是否有简化liú程的可能)
  • 竞品是如何做的?(看看竞品的解决方案是怎样的?效果如何?是否有优化的空间?)

这儿John想再次重申的一点是:抄xí竞品不丢人,上线没有效果才丢人,所以多去chāi解下竞品。

2. X反馈环节:提出初步产品解决方案

XXliú程图模拟路径,和X方确认Xliú程图(二次澄清非常有必要);X竞品解决方案梳理初步的用户cāo作路径并指出和其他模块关联的点。

至此,起码很清晰的了解X方为什么这么做?背后的原因有哪些?产品经理应该如何有效的做解决方案。有了X的确认和自己的X理解,起码产品的方向不会有太多的偏差。

John之前和团队小伙伴聊过:执行永远只占49.765%(不到一半),所以前期的梳理和思考很重要,建议多去挖掘下核心。

五、极少正视“失败”的结果

主动背锅是极需要勇气的,当产品多方位尝试始终未产生明显效果时,还在不停的叠加功能,而未回头看原因是什么?

在John团队中一直遵循这几个原则:

当投入50%的开发资源来做这个事情时,一定会去想好后手,万一没有产生效果,应该如何做补救方案,产品负责人和运营负责人同时背锅。C端产品当使用该模块用户少,且不牵涉核心X,该砍掉就砍掉;B端产品只要有1个人用,就需要想好迭代方案并优化。

当投入少于30%的开发资源来做这个事情时,产品经理应该对这个事情付全部责任。

虽不及项目X这么重大的失败,但是取决于效果反馈,产品经理背锅不仅仅是liú程逻辑等产品工作liú没清晰,更多的是知道做哪些模块更X义。正视“失败”的产品产生的数据,防止更大的失败。

再一个学会给产品做聚焦和减fǎ——短时间内专注让重点X长板更长。当重点X增长后,再围绕重点X建立壁垒。

六、执着于排优先级

我们对优先级其实有一个误区——优先级应该决定当前做最重要的事情,而不是用来安排可以做的事情。优先级也应该是实时需要调整的。

比如在源需qiú池中,已经规划了部分优先级的功能清单,产品经理去捞需qiú做版本计划时,应该重点根据X方制定的X需qiú来重新整理产品规划侧需qiú和优化需qiú,紧急重要程度只是zhēn对于当前阶段需qiú排期来制定的。

尽管X同事做了紧急重要程度,但是后续的二次确认和澄清是非常有必要的。同样再说一个点:除了hú乱的提需qiú外,其实需qiú是没有真伪的。只有当前阶段是否需要做和紧急程度。所以建议产品经理还是制定源需qiú池。

七、一次性迭代计划

做产品模块切记别制定一次性方案。至少要做两次迭代计划,便于开发提前做技术预研和给后续迭代方案留坑。否则等X发展到一定阶段,就需要做重构和换技术债的工作了。

再一个想说的是防止做重复性工作,相同属性的模块进行有效整合,X管理。比如拼团和X领X收纳至营销管理中。

以上7个方面只是John觉得和产品经理关系很大的点,以上都是需要产品经理去驱动的。尤其是X团队,产品经理应该扮演最重要的角sè,摆正自己的位置,做起工作会得心应手。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理成为原型人的七大迹象 https://www.xiongfawang.com/1259.html

常见问题

相关文章

产品经理成为原型人的七大迹象-海报

分享本文封面