产品运营的定义

定义

  1. 吸引产品背后目标用户群来使用/体验产品(根据用户分群思路制定策略吸引用户使用我们产品)
  2. 引导用户持续产出符合产品定位和发展目标的行为和内容(用户自传播与用户软文分享,也可以代指社区产品内用户UGC内容)
  3. 最大化发挥并挖掘我们产品核心价值(短期、中期、长期)

    举例

    支付宝是一款支付产品,最初只是单纯的为了解决用户支付的问题,随着用户的群体增大,支付宝逐步从支付产品演变为数字金融产品乃至于演化为数字生活产品,支付宝从支付工具演变为数字生活产品后,不仅拥有着一站式生活服务,更是一款国民级APP,不限用户年龄段,只需一定时间的引导与体验产品,就能解决不同年龄层用户的使用需求。

产品运营的工作内容

八大工作基础型原则

  1. 内容建设(通过软文以及引导用户在内容平台上进行“发声”)
  2. 市场推广(学会在地域性进行推广产品的使用以及市场的占有率)
  3. 活动策划(策划多个用户感兴趣、愿意参与的活动并形成长期独占活动)
  4. 用户维系(维系种子用户以及愿意长期与你互动反馈问题的用户)
  5. 数据分析(通过分析UV、PV、DAU、GMV、跳转率等数据指标,来挖掘与发现业务问题)
  6. 规则维护(制定SOP以及社群运营相关的流程与规则,确保活动执行效果最大化)
  7. 竞品调研(及时关注市场的变化、如同类的产品、跨业相似点较高的产品、新型线上平台产品)
  8. 需求提炼(倾听用户的抱怨,提炼出有效的产品需求,是一项任何岗位都必的必修课)

工作重点产品的不同阶段,运营的重点不同

新产品上线推广阶段(推广引导期,最大化的曝光与ROI是首要考虑的衡量点)
内容建设和市场推广是重点(“青涩”成长期,雷同于青春期)
产品进入稳定发展阶段(“成熟”期,稳定的GMV、用户真留存)
用户维系和规则维护的比重将逐渐增大(尽可能延缓产品的衰败,因为任何一款产品都会迎接产品的死亡,维系用户等于维系客户)

内容建设

标准建立

产品的价值观,由其承载的内容体现
产品运营自身其实就是运营+策略型产品,运营在产品诞生之初就应该在产品团队中,谋划中长期的收益占比以及运营侧角度的风险规避以及产品侧的链路与交互,确保在用户视角来看,我们的产品是属于较高程度的交付方案或能够敏捷开发管理迭代上线的一款产品
故此,产品最初给用户造成的印象是怎样的,就决定着用户第一印象是否会长期使用

内容推荐与奖励机制

作为平台方以及持续发展的快节奏业务中,我们鼓励贡献为我们提供优质内容产出的用户进行一定的奖励,可以普及用户我们产品的优势与独特的价值观,引导用户产出更多符合我们期待的UGC内容,鼓励产生优质内容的用户,挖掘具备成长潜力的用户并给予一定的奖励

需求提炼/分类

image.png

提需求和提bug的流程

流程图.jpg

关于产品需求

针对还不存在的功能提的需求,主要目的是解决的是“不好用”的问题,但是这里的需求实现周期通常较长,且与开发资源严重挂钩,目前我司没有“大中台化”与“平台型PD”,所以考虑这类的需求,推荐先把自己拷问一顿

关于产品bug

针对已经存在的功能提的,解决的是“不能用”的问题,解决时间视bug严重程度,通常要求尽可能快地处理,可直接找到对应的RD去解决,尽可能推进短期会造成重大损失的问题

产品需求描述

1.需求名称

产品名称+功能+提出时间,如“生花对我司运营后台改进产品需求-2021.03.31”,便于PD进行归档以及留档说明这个需求方来源是谁

2.目的

尽可能详细写出目的,因为有助于PD、RD能够充分理解你的需求的必要性和重要程度,如“为了提高KYC审核效率”或“快速处理到账的渠道清分自动路由”

3.优先级和时间要求

“P0,需要今天紧急上线”
“P1,需要两周内进行上线”
“P2,中长期规划性需求”
“P3,战略性规划需求”

4.需求描述

说明用户身份(外部用户和内部用户的处理方式有区别),页面需要包含哪些元素,期待的布局和风格,排列顺序,是否必选项,有何特殊要求,是否需要查询及查询条件设定,是否需要权限管理等信息,尽可能详细,最好给出参考案例或类似竞品截图。

什么情况下需要提产品需求?

考虑仔细用户的需求、内部的需求
能够用已有的产品达到的任务目标或者基础能力,就尽可能不要去做新的大变动的规划与新的产品,学习的浸没成本以及需求开发评审成功后的RD开发成本是非常好的,若考虑一个后台的开发,则需要在上线之前考虑好利弊关系、路径收益、需求来源以及中长期规划的弹性需求扩容解决方案
需要牢记,能用运营的手法解决的,不必耗时费力地动用产品和研发,能通过成熟的渠道与平台进行流量换量去实现用户的需求,就不要自己从0到1去做一个看似有效但却无效的平台供给能力输出

案例

数据分析后台

分析用户渠道来源的自动化召回数据,一般情况下通过我们APP后台-收券列表可以拉取,但一旦设计发券来源较多、数量较大,则现有的收券列表就无法支撑,所以需要从MetaBase中拉取数据库中存储的数据,通过Excel生成分析数据透视表填入到自动化模板中,便于周报撰写时的附图反馈

小结

接到/提炼出需求后,问自己以下几个问题

  1. 目标足够明确吗?(用户群体?客服/运营提出的吗?)
  2. 已有的产品确实无法满足工作要求吗?(数据可视化完成度不高?、缺少该功能严重影响流程?)
  3. 已有产品的缺陷已经极其影响工作效率吗?(工作效率是否因为该缺陷导致大幅度下跌?解决后的效率提升会有多少?)
  4. 成本是否合适(RD开发成本、需求撰写以及透传的沉没成本)

如果以上的“质检”环节中,出现了自己是否定的情况,需重新审视需求合理性,并且和需求方积极沟通确定最终解决方案,并实施落地

如何促使需求尽快实现?

需求表述明确,最好有结构化的沟通与表达,形成模块化思维并提交流程规范与合规,拿到自己做的相关需求,一定要通知到位以及做到位,不埋坑/少埋坑是最大化的赋能/帮助团队在日常效率的运转
按流程提交需求后最好再当面跟产品经理沟通,尽快落实需求并启动,关键时刻还得看PD推进需求,且必要时机或场景中,学会舍得砍需求,确保敏捷开发上线
充分利用各项资源来达到目标:平时和(爸爸、爷爷、大祖宗)产品设计研发同学搞好关系,必要时通过上级协调解决并推动都是方法,但尽可能的不要越级,越级会打乱一定的流程,若是在探讨环节公开提问中,可以咨询陈总的建议

被毒打出来的总结

  • 产品策划的改进,通常要落后于业务发展时候的需求
  • 互联网产品改进伴随整个产品的生命周期,不是一次性的改造
  • 产品改进必定是由运营驱动的,好的运营能够让产品永不失业
  • 再好的产品,运营跟不上也是白费,所以运营SOP与运营策略/操盘非常的重要

    如何与研发(大祖宗)建立良好的合作

    谨慎处理需求,不要让研发白做工

  • 经过充分的论证调研,先把自己给说服了,再尝试与RD沟通这个逻辑性问题

  • 现遇到的问题,确实无法满足业务发展所需了
  • 研发成本不会超出现有资源范围

    充分说明需求,调动研发的积极性

    让他们充分了解这个需求的来龙去脉,这个需求的背景

  • 现在的这个产品需求是我运营经过调研分析确定的,我的解释是否能让你足够清楚明白可以进行开发了?

  • 从研发的角度,请你看看是不是有其他的隐藏问题?
  • 你有没有更好的解决方案?我们一起再探讨。

    掌握沟通技巧,研发最怕频繁打扰

    利用工具(例如JIRA、云效、多维表格等)来管理需求,汇总一批需求定期(例如每周一次)和研发沟通,确定优先级和排期
    紧急的需求,或者重大的bug出现可以随时找研发处理,但尽量不要用即时沟通的方式

    最好懂点技术,方便跟研发沟通

    了解技术的一些基本概念,名词,表现形式和行业趋势
    提需求时能从研发角度进行一定的考虑,研发提出的方案和排期,心里基本也能有数,效率提高很多

    发掘共同利益

    让参与的人有共同的利益,这事成了,大家都获利,而不只是单纯的部门之间工作配合或者帮忙而已
    组织结构
    为一个产品线配备齐全人员的产品事业部制,就比按职能划分按任务派活的大部门制更能激发员工对产品的责任感和积极性
    舍得分享,赏罚分明,提错了敢于坦诚清晰的承认自己考虑的不足,对了鼓励对方思考的比较全面