产品运营不分家，参与业务深度越深，越能体会其中的关联性。从本质上都是通过提供“服务”给予消费者，完成自有的商业目标。
产品设计（包括其中的文案）都应该是为了帮用户解决问题，而不是创建困惑，不同的用户视角对应不同的产品状态，这次重点讲讲新用户视角。
现在很多产品都有安装后用户引导的设计，但这远远不够，用户引导的设计也意味是理解成本。
经常会忽视新用户视角，因为除非刻意，或者天赋使然的同理心，产品经理对产品接触的时间愈长，就越容易进入一种预判断的逻辑。例如看到一个登录按钮时，就预判用户会点击。
再例如，电商产品中经常强调新启用的电商转化，通过各种数据分析，各种理论研究，我们可能会做一些产品上的决策，例如增加一个下单送券的功能，但如果自己是一个新用户，是否会有这类需求？
重置你的用户身份
建立新用户操作监控流程
观察身边的人
服务是价值的传递。
价值：用户价值、产品价值
传递：工具、载体
运营的目的是解决效率问题。
产品的价值在于能完成资源的有效转化。
因为工作中使用 Google Doc 全家桶，在使用 Google Sheet 过程中，有时要使用到数据验证功能，例如
经常还会有这样的场景需求：有两个下拉选择框，根据第一个选择框的内容，第二个选择框自动更新可选的内容列表：
对于电商团队来说，数据是最为宝贵的「财富」，从业务指导的角度来看，电商运营往往会关注几个关键指标，结合 Tableau 的 LOD ，我们可以更加便捷地计算并可视化这些关键指标。
定义：特定时间段内，第一次下单的客户数。新客运营指标中还包括新客获取成本、新客客单价。获客成本体现拉新质量。
在 Tableau 中，使用 LOD 计算新客数特别方便：
很多 Tableau 初学者在日常使用过程中，如果对 Tableau 的一些基础概念不牢记心里的话，很容易出现的一种情况就是「凭感觉」去完成一些操作，或者参考范例完成后，在下一次作分析时却得不到要领。
相比于 Excel 这类表格软件，Tableau 提供了拖拽式的结构操作方式，从入门的角度来看，「维度」和「度量」就是 Tableau 初学者最应该摸透的基础概念，再怎么强调都不为过。 Continue reading Tableau Tips： 讲讲维度和度量
需求背景：在一份数据统计 Table 里，想要动态排除某个时间点的数据（例如想排除当天的数据）
实现方式：
在这篇小分享里重点讲第一种方法，关键知识点：计算字段、日期筛选器
Step 1：创建一个计算字段
1.1 将此计算字段命名为「排除当日日期」：
如上图，通过运算公式我们简单排除了当天的日期。（此外为计算字段的使用示例，实际中可以根据需求进入更复杂运算）
Step 2：编辑日期筛选器
在这一步中，我们直接使用顶部过滤条件，选择前 7 个数据，这时整个数据表就完成了条件筛选了。
在开篇前，在想要不要再起这个坑了，毕竟现在一来工作忙，特别是下半年，二来涉及到一些工具的使用，如果想入门学习，真不如直接看官方文档以及教程。
接着在整理下半年自己的个人成长计划时，还是把这块列到 ToDo 里来，抱有以下目的
所以整个系列主要是介绍一些基础概念，然后尝试更加体系化去介绍一些数据分析的方法论，通过一些虚拟项目来讲实战分析。 工具方面，主要在使用 Tableau，所以在接下来的系列文章中也会以 Tableau 的使用示例为主，现在只是列一个大体的框架，再逐一拓展。
看回 https://en.wikipedia.org/wiki/Kano_model上的介绍：
The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.
日本教授 Noriaki Kano 在 1984 年首次提出 Kano 模型，Kano 模型分成以下 5 个构成：
我想，谈及「产品经理」时，大家头脑里首先嘣出的一词有可能是「需求」，离开「需求」去谈产品都是在耍流氓。
那么，如何正确定义「需求」，以及在执行层面上如何去管理「需求」？
“如果我最初问消费者他们想要什么，他们应该是会告诉我，‘要一匹更快的马！’”——这是亨利·福特的一句经典名言，也是常用于讨论「需求」时的引子，也就是从表层的需求描述中深度挖掘客户隐性需求。
在产品开发流程中，从产品策划到产品需求阶段，产品经理应该要去作的时候就是去发掘产品策划后真正的产品需求，「我想要一个 xxx 的功能」、「我想在输入一个 xxx，然后输出 xxx」、「我想一个能自动 xxx 的功能」，想必大家常能收集到这样的需求提案，小到想调整一个页面按钮的文案，大至改动整个产品的运作模式。
这是 User story，并不是说这种表达方式不妥，只是需要产品经理去进一步沉淀出来用户想要的东西。 Continue reading 产品经理讲堂（3）- 需求管理
