X

曜彤.手记

随记，关于互联网技术、产品与创业

  1. 淘宝产品经理分享：
  2. 团队合作：
  3. 项目启动前到产品上线：
  4. 项目启动后：

GeekBank C++ 线下班学习心得（三）


Created on  

淘宝产品经理分享：

  • 王程远（淘宝“闲鱼” APP 项目组项目经理）；
  • 淘宝规则部门 -> 淘宝基础产品部门 -> 手机淘宝 -> 闲鱼；
  • 996 朝九晚九每周六天；

团队合作：

  • 产品 = 商业模式 + 功能 + 设计 + 技术 + 内容；
  • 产品的成功是归功于整个团队的精诚合作，产品的失败只归咎于产品负责人 - Marty Cagan；
  • 基本团队组成：产品经理、交互设计师、视觉设计师、服务端开发、客户端前端开发、测试、投资人、产品运营、用户运营、内容运营、市场运营、BI、安全、客服、用研、法务；
  • PRD：产品需求文档（Product Requirement Document）；
  • KPI：关键绩效指标（Key Performance Indicator）；
  • UED：用户体验设计（User Experience Design）；
  • MRD：市场需求文档（Market Requirements Document）；
  • TC：测试用例（Test Case）；

产品经理需要具备对于技术和视觉设计和交互设计的基础了解，不关注具体的技术实现，而关注技术实现对产品方面的影响。不要过多的干涉设计，让设计师进行主导。

产品经理需要思考战略：有对产品的整体观，看终局（市场最终的结局是什么样子、未来的方向）、做布局（必须做哪几件重要的事情）、定位（告诉自己和用户：我是谁，我在哪来，我能为你解决什么）、策略（哪些路径可以走，选择哪些路径，用什么样的节奏和方法）。

注重看产品的更新版本，看连续两次版本更新的功能差别。

项目启动前到产品上线：

MRD的内容：（大体包括：怎么做，用什么方法做）

  1. 为谁解决这个问题（目标用户）；
  2. 产品要解决的问题（产品价值）；
  3. 市场有多大（市场规模）；
  4. 成功的必要条件（解决方案的关键点）；
  5. 有哪些同类产品（竞争格局）；
  6. 如何把产品推向市场（营销组合策略）；
  7. 怎样判断产品的成功（KPI）；

投资评估：

  • 投入：时间成本，产品开发成本，运营成本，市场成本；
  • 回报：可量化的回报指标；
  • 风险：风险概率，严重程度和可控性；
  • 评估周期：快速；（功能不能太多，否则评估过程会耗费很多时间）

投资和投机：

  • 投资：合作关系，共同的利益点，利益最大化；
  • 投机：以自己的利益最大化为主；

功能需求：（从一个输入框说起）

  1. 前置条件（进入页面）:

    1. 用户状态：用户状态正常，完成支付宝实名认证；
    1. 登录状态：已登录；

  4. 标题属性：

    1. 是否必填；
    1. 字数限制；
    1. 默认提示文案；

  8. 内容安全校验：

    1. 触发校验点；
    1. 先分清，再调用违禁词表；
    1. 命中关键字，弹出提示；
    1. 提交时判断违禁词类型；
    1. emoji 加入到违禁词表；

  14. 失焦后越策类型：

    1. 调用类目预测接口，返回类目 ID 和类目名称；
    1. 返回值为空时，缺省类目“ID=1278786”；
    1. 修改失焦后重新调用；

  18. 提交校验项：

    1. 字数校验；
    1. 违禁词校验；

非功能需求：

  1. 数据采集，用于评估产品效果；

    1. 设计评估指标；
    1. 设计客户端数据埋点，PC 埋点；

  4. 灰度要求：

    1. A/B Test;

  6. 项目要求：时间、资源；

  7. 初始化数据；

  8. 风险评估和方案：

    1. Anti-Spam 反垃圾；
    1. 安全风险；
    1. 开关；

  12. 关键性能需求：

    1. 响应时长：时间结降级方案；

  14. 2 流量消耗：图片降级方案；

  15. 帮助和反馈课题；

后台设置开关控制前端的控件显示（防止错误出现影响用户体验）；

PRD评审：（功能评审，版本评审）

  1. 功能没有价值 => 回到问题和目标，数据和经验先明确提出来，引导建设性问题；
  2. 过度设计，成本太高 => 尽量避免完美主义；
  3. 产品设计失误或缺失 => 定位问题，引导讨论优化方案；
  4. 技术细节过度讨论 => 指定相关人给出方案，迅速推进；

设计评审：

  • 项目初期：“How” and “Why”；
  • 项目中期：“Strength” and “Weather”；
  • 项目后期：“Variable” and “Wrap up details”；

如何优雅的参加设计评审：

  • 先听后说；
  • 在表达个人看法喜好时一定要提前声明；
  • 关键的问题先提问；
  • 找出当前设计方案中的精华部分；
  • 找出问题，指出设计师可能遗漏的方向，避免直接给出解决方案；

技术方案评审关注的几个重点：

  • 底层设计的拓展性；
  • Native or H5（Web 页面）；
  • 接口设计；
  • 数据结构；
  • 跨平台的一致性；
  • Kickoff：确定需求、设计、技术方案、沟通方式、项目时间点；

3P（产品经理、设计师、开发工程师）的爱恨情仇：不要以专业自居（比如设计和开发之间）；

发布上线：（两周开发一周测试）

  1. 灰度发布：检验 BUG 性能指标关键指标监控；
  2. APP 发布到渠道；
  3. Web、H5 和服务端发布；

项目启动后：

３种典型的运营：

  • 用户运营（KPI = 拉新 + 暂存 +流失召回）；
  • 内容/社区运营（KPI = 内容质量 +　数量 + 互动 + 建立模式）；
  • 市场/营销运营（KPI = 品牌影响力 +　营销指标）；

用户运营：

  • 获取新用户：用户分类和分层，获取用户渠道，数据：各种 ROI；
  • 留存和流失：找到用户暂留关键，流失用户召回，数据：用户留存；
  • 核心体现：建立 HOOK Model，数据：关键漏斗转化率；

常用指标：

  • 用户获取成本：CAC；
  • 用户活跃：DAU（APP 的核心价值）；
  • 周活跃用户数：WAU；
  • 月活跃用户数：MAU；
  • 日参与次数：DEC；
  • 日均使用市场：DAOT/AT；
  • 留存 + 流失：
  • 次日留存；
  • 三日留存；
  • 七日留存；

内容 / 社区运营：

  • 设计用户发现内容的路径；
  • 直接产生内容；
  • 驱动用户产生内容；
  • 设计浮现机制；
  • 驱动内容消费；

用户发现内容的路径：

  • 类目、广告、属性、搜索、人、算法推荐；

Last built on


评论 | Comments


Loading ...