Q4.08.1hiring a product for a job设计研究
关注用户雇佣产品完成什么
别名: 待办任务 · 雇佣产品 · JTBD
概念解释
问「你为什么买这个软件」，得到的是品牌、价格、同事推荐。问「那一次你请它来干什么」，得到的是一件当时要推进的事：在出差前把发票变成能报销的状态。待办任务（job to be done）把产品看成被雇佣（hired）来推进某种进展，而不是看成功能集合或品类成员。关注点从「产品是什么」转到「那一刻要完成什么」；功能只有在被雇用来做事时才进入分析。
机制
购买和使用发生在具体压力下：截止日期、手头已有的替代、丢脸的风险。这些压力选择的是能推进进展的手段，不是最像「报销系统」的东西。若分析从产品属性开始，会把雇佣情境里真正被比较的对象排除在外——邮箱搜索、共享表格、找助理。雇佣视角强迫写出进展的衡量：怎样算做成了、做成了会摆脱什么。写不出进展，所谓任务只是把功能换了个说法。
怎么研究
采集最近一次「开始用 / 换成 / 停用」的具体事件，还原当时要推进的进展、候选手段、触发压力，而不是问品类偏好。把事件写成「当……，我想……，以便……」，再用观察或产物核对是否真的发生过这次雇佣。比较「功能满意度」与「进展是否达成」对续用或弃用的预测。因变量包括能定位到单次事件的比例、以及进展陈述能否不提产品名仍可理解。
边界
探索性玩耍、身份表达、无明确进展的闲逛，不必硬套雇佣句式，硬套会编造任务。组织采购里，下单人、使用人、受益人可能雇佣的不是同一件事，一张「用户雇佣」会抹掉冲突。合规强制使用的系统没有被选择雇佣，分析应改成「被要求完成的官方任务」与「人们实际用来交差的私雇手段」对照。尚未发生的未来任务只能当假设。
怎么落地
- 访谈从最近一次具体使用或弃用开始，先问当时要做成什么，再问请了哪些手段，最后才问产品。
- 每条任务陈述拿掉产品名后仍应能被外行听懂；听不懂就还是功能伪装。
- 设计讨论里用「这是在应聘哪一件进展」筛选方案；应聘不上的功能，哪怕竞品有，也不自动进入范围。
- 用一次真实事件走陈述：压力、候选、做成标准对不上现场，就改陈述，不要改事件来迁就金句。