科技巨头的个人健康记录实验 (Google Health):一家有能力做产品的科技公司,为什么做不好个人的健康记录?
健康数据的入口不在用户手里,而在医院、保险与实验室的系统里
科技巨头的个人健康记录实验 (Google Health):巅峰期由大型科技公司推出的个人健康记录平台,用户可以集中管理用药、检验与就诊记录,被视为科技进入医疗数据领域的重要尝试;终局是用户规模始终有限、商业伙伴参与不足,公司在数年后宣布关闭服务,并要求用户在规定期限内导出数据。
由大型科技公司推出的个人健康记录平台,用户可以集中管理用药、检验与就诊记录,被视为科技进入医疗数据领域的重要尝试
用户规模始终有限、商业伙伴参与不足,公司在数年后宣布关闭服务,并要求用户在规定期限内导出数据
3,702 票参与
1 方案 · 1 见解
投稿会先进入待审,通过后才进入公开目录和站点地图。
核心败因全民归因公投
投票选择您认为导致该企业/项目最终死亡的最核心死穴,认同即可实时投票计入权重
关键数据不在自身体系内
数据持有方缺少对接动力,产品价值依赖外部配合
健康数据的互通标准不成熟
缺少统一标准使集成成本高、覆盖面窄
用互联网的采用率逻辑套医疗
医疗场景的决策链涉及医生与机构,不遵循通用产品的增长逻辑
投入与回报不成比例
在价值未被验证前持续投入,难以为继
时间线:从高峰到终局
服务上线
公司推出个人健康记录平台,用户可以集中管理用药与检验记录,媒体关注度高
伙伴对接有限
医疗机构与检测方的数据对接进展缓慢,用户需大量手动录入,使用体验受限
采用率不足
活跃用户规模未能形成网络效应,产品的持续投入受到内部质疑
宣布关闭
公司宣布关闭该服务,用户被要求在期限内导出数据,医疗数据业务方向调整
四大维度全景复盘剖析
发展背景与全盛期基石
公司擅长的是面向海量用户的通用产品与平台能力,希望通过个人健康记录切入医疗数据领域;项目获得公司内部资源与外部医院、药房的部分合作,但医疗数据的互通标准与合规要求远比通用互联网产品复杂巅峰期的成绩单是:由大型科技公司推出的个人健康记录平台,用户可以集中管理用药、检验与就诊记录,被视为科技进入医疗数据领域的重要尝试。此时的它拥有渠道、品牌与资本的合力,看起来没有任何理由会输。
致命转折点的战略误判
数据的实际持有方是医院、实验室与保险公司,用户在平台上能获得的信息有限,往往需要手动录入;医疗机构缺少主动对接的动力,健康数据的互通标准也未成熟,导致产品价值难以体现,活跃用户不足,公司最终宣布关闭服务管理层把规模当成安全垫,用并购和跨界把营收做大,却没意识到这些业务的毛利率、周转率与决策节奏完全不同,总部根本无法用同一套考核管住。
内部组织文化与盲目傲慢
组织里最会讲故事的人拿到了最多的预算,最懂业务的人被调去做整合。战略会上没有人真正算过「这块新业务要多少年、烧多少钱才能自己站稳」。
轰然倒塌的崩盘推演
用户规模始终有限、商业伙伴参与不足,公司在数年后宣布关闭服务,并要求用户在规定期限内导出数据。科技巨头的个人健康记录实验 (Google Health)的结局不是某一次意外,而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
商业落地避坑实操法则
以血淋淋的商业代价淬炼出的创业与经营行动准则(DOs & DONTs)
进入医疗数据领域,先解决「数据从哪来」和「谁有动力给」
把数据供给方的收益设计清楚,再谈产品体验。
- •先确认数据供给方的动力与接口
- •选择数据已经在自己手里的场景切入
- •不要把通用互联网产品的增长逻辑套到医疗场景
- •不要在数据来源未解决时上线面向用户的产品
绝地求生模拟器:如果你是当时的CEO,在关键转折点该如何挽狂澜于既倒?
历史不可更改,但思维可以淬炼。针对核心转折点,提出手术刀式改革方案与资源调配破局法,交由全网创业者与投资人可行度公投。
先把数据供给方的动力设计清楚,再谈面向用户的产品
关键干预时点:2009 年前后机构数据对接进度缓慢、用户大量依赖手工录入时
- •停止在数据来源未解决时扩大用户推广
- •停止用通用消费产品的指标衡量医疗产品
- •停止假设机构的对接会自然发生
- •为数据供给方设计明确的收益与接口标准
- •从数据已在体系内的场景切入
- •把临床与保险方的使用价值作为产品验证标准
医疗数据的合规与标准问题超出单一公司能力范围,需要行业协同。
产品获得稳定的数据来源,用户价值成立并可被持续验证。
行家深度复盘见解
来自创业者、投资人、前员工和行业专家的真实第一手复盘反思
从产品设计看,这个平台想解决的问题是真实的:一个人的病历分散在不同的医院、体检机构与药房,自己根本整理不清。公司的优势是能做大规模、易用的产品。但医疗数据和社交、搜索不一样——它的持有方是机构,而机构把数据给出去既没有直接收益,也要承担合规责任。于是用户在平台上看到的多数信息需要自己手工录入,价值一下就弱了。当活跃用户长期上不去,公司很自然地做出了关闭决定,这对互联网公司是常规操作,对等待数据迁移的用户却是一次麻烦。
医疗数据的入口问题不解决,再好的产品也只是个空壳。
商业复盘与避坑备忘录 · 科技巨头的个人健康记录实验 (Google Health)
一家有能力做产品的科技公司,为什么做不好个人的健康记录?
# 商业复盘备忘录:科技巨头的个人健康记录实验 (Google Health) > 一家有能力做产品的科技公司,为什么做不好个人的健康记录? > 周期: 2008 - 2011 | 行业: 医疗与健康 > 巅峰: 由大型科技公司推出的个人健康记录平台,用户可以集中管理用药、检验与就诊记录,被视为科技进入医疗数据领域的重要尝试 > 终局: 用户规模始终有限、商业伙伴参与不足,公司在数年后宣布关闭服务,并要求用户在规定期限内导出数据 ## 核心概览 健康数据的入口不在用户手里,而在医院、保险与实验室的系统里。巅峰期由大型科技公司推出的个人健康记录平台,用户可以集中管理用药、检验与就诊记录,被视为科技进入医疗数据领域的重要尝试;终局是用户规模始终有限、商业伙伴参与不足,公司在数年后宣布关闭服务,并要求用户在规定期限内导出数据。 ## 社区公投头号死因 1. [战略决策] 关键数据不在自身体系内 (1,218 票) 2. [产品技术] 健康数据的互通标准不成熟 (1,023 票) 3. [组织管理] 用互联网的采用率逻辑套医疗 (828 票) ## 可执行教训 ### 进入医疗数据领域,先解决「数据从哪来」和「谁有动力给」 > 把数据供给方的收益设计清楚,再谈产品体验。 - ✅ 推荐做 (DOs): - 先确认数据供给方的动力与接口 - 选择数据已经在自己手里的场景切入 - ❌ 绝不能做 (DON'Ts): - 不要把通用互联网产品的增长逻辑套到医疗场景 - 不要在数据来源未解决时上线面向用户的产品 ## 救亡方案 ### 先把数据供给方的动力设计清楚,再谈面向用户的产品 — 良略编辑部 干预时点: 2009 年前后机构数据对接进度缓慢、用户大量依赖手工录入时 - 必须断腕: - 停止在数据来源未解决时扩大用户推广 - 停止用通用消费产品的指标衡量医疗产品 - 停止假设机构的对接会自然发生 - 破局动作: - 为数据供给方设计明确的收益与接口标准 - 从数据已在体系内的场景切入 - 把临床与保险方的使用价值作为产品验证标准 - 预期结果: 产品获得稳定的数据来源,用户价值成立并可被持续验证。 ## 社区见解 ### 它把界面和体验做得都不错,问题是用户打开之后,里面是空的——因为数据不在用户手上。 — 良略编辑部 (产品经理) 从产品设计看,这个平台想解决的问题是真实的:一个人的病历分散在不同的医院、体检机构与药房,自己根本整理不清。公司的优势是能做大规模、易用的产品。但医疗数据和社交、搜索不一样——它的持有方是机构,而机构把数据给出去既没有直接收益,也要承担合规责任。于是用户在平台上看到的多数信息需要自己手工录入,价值一下就弱了。当活跃用户长期上不去,公司很自然地做出了关闭决定,这对互联网公司是常规操作,对等待数据迁移的用户却是一次麻烦。 - 如果重来一次的纠偏招式 医疗数据的入口问题不解决,再好的产品也只是个空壳。 --- 来源: 良略 · https://www.lianglue.com/c/google-health