拼多多为什么能够成功，其中最关键的一点就是黄铮充分利用了人爱贪小便宜的这一特性。对于 C 端产品，离不开利用“马斯洛1943年提出的需求层次理论：人有一系列复杂的需求，按其优先次序可以排成从低到高的梯式层次，包括生理需求、安全需求、社交需求、尊重需求和自我实现需求。”这五类。可以看看做得好的 C 端产品，例如购物、出行、美食、短视频、陌生人社交、金融、游戏等等，都是在某些方面满足了人的诉求。这也是 C 端产品特别注重进行用户研究、做用户画像的原因之一。

到了 B 端，情形则完全不同，B 端的客户使用产品的核心诉求只有那几个，那就是扩营收、降成本、增效率、控风险。那些小恩小惠和企业的经营业绩相比根本不值得一提。而且，即便是让客户使用了你的产品，如果客户回头发现你的产品没有达到客户的商业目标，流失是必然的。这也是为什么国内诸多 SaaS 平台的流失率居高不下的原因之一。

使用产品的用户群体不同
C 端产品的群体一般按照产品定位、设计风格都能够圈定一个具有共同特征的目标用户群体，前期的产品设计及运营推广都会首先照顾这些目标用户，也可以称之为核心用户。到产品稳定后才会逐步扩大到潜在的用户群体，典型的一个例子就是知乎。早年的知乎的格调是非常高的，邀请制，精英群体高质量的回答吸引了不少用户。后来，随着商业化的需要，开始降低了门槛，内容也从问答扩展到了文章、视频领域。

但对于 B 端产品的用户群体来说，非常多样。这是因为 B 端产品需要串联的是从公司管理层到基层员工整个企业运作的链路。B 端产品通常不会说有什么特定的用户群体定位，而是目标客户定位。因为你的产品没法去替客户企业筛选使用者，而每个 B 端的客户企业的员工本身就十分多样，甚至相互的诉求甚至是矛盾的。比如管理者想加强内部管控，而基层员工则可能想着上班时候怎么“摸鱼”。实际上，如果没有好的客户资源，做核心的业务系统的 B 端产品会十分艰难，因为核心业务意味着客户整个经营主线都要随着你的产品进行变革 —— 这种变革非常痛苦，需要的是整个企业从管理层到基层员工都通力配合。而这种情况很少见，以至于很少有客户能够坚持到看到成效的那一天。

所以，我们可以看到，很多做得好的 B 端的 SaaS 产品都是面向某个业务部门的，而且是比较通用的产品，例如 OA、HR、项目管理工具、进销存、CRM 等等。这类产品一般只需要面对某一个部门，而且不会涉及到企业的核心业务，相对来说会比较好推动。不过，这类产品缺点也很明显。一个是竞争非常激烈，另一个是客户缺乏粘性，流失率比较高。

需求管理方式不同
C 端产品通常来说产品经理的话语权更大一些，产品的发展方向通常来说是产品经理来决定的。因此，C 端产品的成败很大程度上决定于产品经理。早期移动互联网刚刚起步的时候，很多产品在还没发布的时候，就能够凭借产品的创意和运营思路获得资本的亲睐。因此，C 端产品管理需求通常会有一个比较稳定的需求Roadmap，需求一般不会偏离主线，需求的来源也更为集中。

B 端产品的需求则不然，很大程度上受客户决定。早期的产品在相当长的一段时间内都是在满足客户提出的各种各样的需求，尤其是大客户的需求。因为，在早期从 0-1 阶段，获取一个客户太难了，很多客户就一句话——“没有这个功能我们不会用你们的产品”，然后就得吭哧吭哧干上个把月去开发对应的功能。

B 端产品在大客户面前的话语权是非常低的，甚至有些行业内朋友将自己比做弱势群体来自嘲，而如何管理客户的需求决定了一个 B 端产品经理的段位高低。好的 B 端产品经理在客户提出需求时，第一反应不应该是赶快实现客户的需求，而是先从业务背景上去理解客户的需求。如果所有客户需求都满足，那么你的产品就没法标准化，最后肯定会一败涂地。回到前面我们说过的，B 端产品需要洞察商业，也就是说我们要理解业务，从业务的专业性角度去评估一个需求是否合适，能不能纳入标准化产品。如果一个需求能够通过其他方式纳入标准化产品那是最优的选择，如果不能那么应该考虑引导客户使用标准化的手段去解决，如果还不行那么就需要评估投入产出是否值得。

B 端产品给大客户做定制化的需求开发是有的，但是占比不应该太高，通常不应该超过 15%。针对客户的定制需求，从客户的角度上看是合理的，但是实际考虑的却并没有那么简单，比如增加一些相关的思考：

如果支持这个定制功能，别的客户的业务会受影响吗？
会不会支持这个定制功能导致产生了风控漏洞？
业务实操SOP上面是否真的合理？
这是客户的某一个需求方提的需求，企业的员工会有不同意见吗？
你看，一个 B 端看似合理的需求，经过一思考可能会打上好几个问号。

我们重新思考梳理之后与公司销售、售前以及客户再次沟通后，客户非常认可我们的做法，而且觉得我们很专业，因为我们从他们业务角度考虑问题了，甚至比他们想得还要周全。实际上，拒绝 B 端客户的需求并不一定会导致客户真的弃用你的产品，前提是你能够给客户一个更好的解决方案。

工作方式不同
虽然作为产品经理都需要画原型、写文档，但这其实是基本功。对于 C 端产品经理而言，获取产品迭代的思路可以通过线上的用户反馈完成，也可以通过运营数据分析来完成，一般不会有很多机会直接面对用户。但是，B 端产品经理一定要多接触客户 ，只有不断地接触客户才能够了解客户的真实工作环境、工作场景和业务。

实际场景如果不深入一线很难获得，而如果仅仅是在办公室里设计一个类似的产品的结果可想而知。我们团队做 B 端产品的时候，有段时间刻意和销售部门的同事一起出去见客户，给他们讲解我们的产品，然后听他们的意见反馈，并且还会询问他们当前是如何进行工作的。通常来说，面对面和客户交流会有下面这些意想不到的收获：

拉近和客户的距离，后期进行需求交流会顺畅很多；
可以了解他们平时的工作状态；
了解友商，很多客户会愿意向你展示他们当前使用的产品的操作流程和界面。
因此，作为 B 端产品经理，请务必多多深入客户一线。

专业度要求不同
对于 C 端产品，通常对专业度要求不会太高，比如你做音乐 App 不一定要求你是音乐发烧友，你做购物应用也不需要你天天购物。C 端产品经理更多的是需要了解用户想要什么，而 B 端产品经理的专业度要求非常高。当你和客户交流时，如果你的专业度不够，你可能会答非所问，如果让客户觉得你非常不专业，那么产品大概率是没法在客户企业中推广的。我深信，做好 B 端产品的一个大前提就是，产品经理要成为领域专家。

如果你是做财务类软件，那么你最好是有一个会计证，或者是对国外的 SAP，国内的用友、金蝶财务系统非常熟悉。如果你是做供应链管理，那么你至少得啃好几本供应链领域专业的书籍。如果你是做智能工厂，那么你要对工厂的每一道工序烂熟于心。如果你是做 HR 系统，那么首先你自己得是一名合格的人力资源经理。事实上，B 端产品经理的专业度就是这个岗位的核心竞争力。

职业稳定性
在互联网领域，很少有岗位是稳定的。但 B 端产品经理的稳定性相对会高一些，而且不会有所谓的年龄线。因为，对于 B 端品经理而言，随着年岁的增长，业务知识也会更加专业，对行业的洞察也更深。客户尤其是管理层也更愿意和有丰富行业经验的产品经理打交道。这种深度是需要时间积累和沉淀的，年轻人没法在短时间追赶。即便是你的公司出现问题，你的行业积累也能够让你找到更好的下家，因为行业专家是十分稀缺的。

总结
本篇结合个人的实际经验介绍了 C 端产品经理和 B 端产品经理的不同。从个人角度来说，如果你在犹豫是选择 C 端还是 B 端那么建议选择 B 端。这个社会总是需要商业支撑才能够往前发展，而 B 端产品经理能够真正的助力商业发展。不过，请注意选择 B 端请务必抱着成为行业专家的目标努力，只有这样才能够真正提现自己的价值，给自己一个充足的职业发展空间。

我印象当中，大概在2014年国内就已出现了移动慢病管理服务，其中，以糖尿病这个细分领域发展尤为迅速。我们先来看一些数据：《中国居民营养与慢性病状况报告(2015年)》及相关数据显示，我国2012年全国18岁及以上成人高血压患病率为25.2%，糖尿病患病率为9.7%，但就这两类人群相比，总人数已经超过3亿人。根据《中国疾病预防控制工作进展（2015年）》公布的数据显示，中国慢病导致的死亡人数已占到全国总死亡的86.6%，导致的疾病负担占总疾病负担的近70%，民众对于移动医疗慢病管理的需求日趋增大。

目前互联网慢病管理行业中以糖尿病管理切入服务的企业数量最多，其次企业切入较多的病种是高血压、 心脏病、 心脑血管和肿瘤。 但从患病率人数总量分析来看，高血压患者人数庞大，是未来慢病管理发展极具潜力的细分垂直领域。2018年，中国整个移动医疗市场进入了一个高速增长期，民众对于移动医疗市场需求增大，用户渗透率也不断提升，产业链环节更加清晰，市场规模高速增长。移动慢病管理作为医疗健康产业互联网化发展过程中的新兴细分领域，被称为移动医疗的“下一座金矿”。随着移动医疗市场的高速发展，移动慢病市场也在随之发展成熟，移动慢病管理企业也由于慢病管理机制差异呈现多元化发展态势。

伴随着移动慢病管理服务市场的快速发展和大量资本的不断涌入，移动慢病管理市场出现了前所未有的混战态势，在诸多垂直细分战场中，糖尿病移动医疗产品的市场争夺最为激烈，该细分领域的发展也更为完善，市场规模也急剧扩大，据IDF及36氪研究院预测，2020年糖尿病APP服务市场规模约有162至271亿元。

在2015年的移动医疗风口期，移动医疗APP数目高达2000多款，其中糖尿病管理APP有700多款，约占整个移动医疗APP的30%，在糖尿病这个单病种领域上演了“百糖大战”。风口退潮之后，经过近三年的市场洗牌，糖尿病APP市场格局仍未形成，转而进入“战国时代”，行业内的核心产品主要有大糖医、微糖、掌上糖医、糖医生、糖护士等。目前，各家平台都在探索自己的商业模式，并尝试“广积粮高筑墙”，以待在百亿市场分一杯羹。

下面简单介绍下糖尿病移动慢病管理领域里的几个主要赛车手：

糖尿病管理App的主要功能还是来帮助患者控制糖尿病，本人尽管不是患者，还是尝试下载了几款APP试用了一下，也跟大家分享下我的感受。

目前国内的糖尿病App管理软件大约有百余种， 侧重点均为血糖记录和远程问诊两大版块。其中血糖记录和传输又分为通过手动输入、蓝牙、手机USB接口、盒子等几种不同的方式，但是因为存在不同的连接方式和时间段的认定， 以及修改个别数据的问题， 所以并不适用于所有年龄段患者。而且因为存在各种软硬件因素干扰，没有一款App能保证随时都能无障碍使用，经常会遇到没有联网无法使用、手机内存不足无法使用、版本更新系统不兼容无法使用、软件自带问题造成无法使用等等情况。这样看来，仅仅就记录功能而言，手工本子更牢靠一些。如果想让多日记录集中呈现，不如自己做个电子表格记录。

个别App还有血糖跟踪、提醒预警、远程监控和统计分析功能， 但是因为这4项关乎App厂商的资源配置，所以并不是所有的App均有此功能。因为是糖尿病病人使用的App，我个人感觉如果有数据记录，就难免会有血糖波动，所以提醒和监控还是有必要的，但是这种动态选择和机动性现在各App还是有很大的提升空间。

App是基于手机端的辅助自我管理软件，与人工自我管理相比， 其优势在于其强大的逻辑计算能力。现在的糖尿病管理App的发展是在从单纯记录向数据传输发展，而基于个人血糖数据的分析却仍是短板。并且以目前我所能接触到的App来看，各大厂家并未在软件设计方面投入足够多的资源，而发展重点都放在了积分、商城、问诊以及各种吸引客户的活动上。积分、商城、活动是不可少的，但是这部分所起到的作用也只是吸引了用户，与用户最核心的需求——管理好血糖相差甚远，所以效果也只是一段时间的，并不能让用户与App产生稳定的依存关系。至于对血糖监测结果进行分析，则是患者在血糖记录基础之上的深层次需求，也是管理好血糖的必需品。只有充分地基于原始数据的统计分析，才能找到问题的根源并寻求到解决的办法，避免再次出现同样的情况。

在App的问诊版块有免费、付费两种状态，但是其中大部分医生都因为工作关系无法及时回复，这对于用户来说基本属于鸡肋功能。就目前的体验来说，多数医生给出的意见也是模棱两可，实用性较差。并且由于对基层医生医技水平的不信任感，造成线上患者也是蜂拥奔向知名医生，从而造成和线下同样的问题：大医生时间有限，和患者交流时间很少或需要等待很长时间。糖尿病是慢性终身性疾病，一旦患上，就需要从患病初期和你的主治医生保持联系，经常沟通，探讨病情的发展和控制。但是究竟应该如何联系，如何沟通，目前各方还在探讨中。北京糖协有相关的“8760”2型糖尿病管理项目，也是在线下的各个医院和病友间开展活动，因为网上问诊终究还是难以完全解决很多“糖友”的实际问题， 但患者每周都去医院咨询也是不现实的，因此如果App厂商能够和医院进一步联合，定期参与在医院开展的活动，或者和医生联合走进社区，进行现场咨询，现场收费， 同时组织更多的患者活动，加深患者交流等，也许可将线上线下打通，有更好的表现。

国内血糖管理App还有糖尿病知识版块，也有专门以推送知识为主要功能的App，但是对于糖尿病知识版块，现在还没有一个产品是成型的和实用的，更谈不上个体化。大分类基本形成，但再深的分类和内容的审核过滤还是欠缺的。信息的有效性、可靠性、指导性、实用性都需要改善，知识内容的索引基本还没有建立，用户要找到自己所需的内容，基本要把所有的内容都翻一遍才行。而且一些题目起得过于洋气和高大上，并不利于用户的搜索。

另外我觉得，我试用过的所有App都存在一个问题，就是如何把你的产品功能变成用户的行为，让用户可以充分了解App能做什么、怎么用。现在的App则给人一个感觉：注册了你就用吧，好不好用，所有的功能能用多少，全看你自己的能力了， 与App厂商关系不大。举一个例子， 一款App产品，有在其官网导出记录数据的功能，但是这个比较独特的功能还是在一个患者群中得知的。这说明App在用户指导方面的缺失，也说明了同伴支持的重要性。国家在2002年医疗器械分类目录中就把软件划分为医疗器械一类（分类目录编号为6870），虽然个人用医用软件尚未列入其中，但是我仍然希望各个App厂商也能够像生产医疗器械软件一样做到用前、用中、用后的高标准服务到位。

我心目中理想的慢病管理App软件，是在配合有效硬件的基础上，实现AI慢病管理，集成市场上大多数的健康智能设备，具备语音识别、个性化医疗、数据分析、身体（图像）识别、增强现实等技术，加入科学分析与贴合需求的服务，全方位帮助慢病患者进行慢病管理。

产品经理的工作主要是管理与其产品相关的所有大小事务，一切以满足用户需求，并为产品做出长期的发展线路（Roadmap）。所以在产品经理的工作中必然并行着各种日常、短期及长期的工作内容或规划。

一般来说在理想状态下，产品经理的时间是这样分配的：日常工作内容是工作的基础，要花费大约50%左右的时间，短期的规划大约占30%左右，中长期的规划占20% 左右的时间。理想虽然美好，但现实必然是残酷的。理想只能做为产品经理的一个梦，从现实到理想还是有很长一段路要走的。

无论是负责某个具体产品的产品经理，还是负责一条产品线的产品经理，甚至于是负责一个产品团队的产品经理，即使是制定了再详尽的工作计划，却很少或从未正常执行过，为什么呢？根据本人及同事的经验来说，产品经理的计划是远远赶不上实际情况变化的，但并不是说产品经理不需要做计划，需要说明的是产品经理更应该花时间把计划做好，做细，可执行性做高。因为产品经理的时间真的很宝贵，而且一直在被无情的浪费着。

结合自己和朋友这些年的产品经理从业经验，与大家分享一下我的做法，有不足的地方，希望可以得到朋友们的指正：

产品经理的日常行为：
1、维护产品进度跟踪表
2、搜集与产品相关的信息和用户需求并深入思考提炼
3、产品调研分析与撰写产品需求文档
4、沟通协调与产品相关的工作（交互，设计，开发，测试）并控制项目的关键时间节点
产品经理的短期行为：
1、撰写产品的月度/季度计划
2、协调或申请资源为下一阶段产品工作做准备
3、监控和分析产品的主要竞争对手的发展举措并制定自身产品的优化竞争策略
产品经理的长期行为：
1、从数据分析，用户反馈和市场研究等方面，来规划产品的生命周期和长期战略计划
2、根据数据分析，提出产品的创新优化模式

怎样理解信息架构？
写给新手的信息架构设计指南

在豆瓣上闲逛的时候，发现好多人推荐一本关于web信息架构设计的书：Web信息架构设计大型网站（第三版），甚至还被有些朋友列为信息架构师必读书，我把一些写得不错的书评也收集起来一并在这里分享：

网站背后的信息架构
敢问北极熊，路在何方？

作者简介：
Lou Rosenfeld是独立的信息架构顾问，可算是这个领域的创始人之一，协助ccenture、Caterpillar、CDC、Ford、Microsoft，以及NCAA这些客户开发信息架构策略和提供内部人员专业训练。Lou于1990年与人合伙成立业内领先的公司Argus Associates，并在1993～2001年之间担任总裁。他在ASIS&T一系列成功的信息架构高峰会中扮演关键角色，而且与人合作成立该领域的专业协会：信息架构学会及Uxnet(User ExperienceNetwork)。
Lou最近的成就包括成立Rosenfeld Media；这是一家出版社，专门出版用户体验书籍。每年他也会在6个城市开设研讨班，教授企业信息架构。
Lou拥有密西根大学图书馆学硕士学位，目前也在该校教授研究生课程。Lou和他的妻子Mary Jean Babic、女儿Iris，以及猫Schwa住在密西根州安阿伯市。他的博客地址是WWW．10uisrosenfeld．com。
Peter Morville(morville@semanticstudios．corn)是Semantic Studios的总裁和创立者；Semantic Studuios是一家信息架构和策略顾问公司。从1994年起，他在信息架构设计实践中就扮演重要角色。身为Argus Associates(1994~2001年)公司的首席执行长，Peter建立了世界上最值得尊敬的信息架构公司，向AT＆T、Barron、Ernst&Young、HP、IBM、L．L．Bean、Microsoft、Procter&Gamble、Vanguard，以及Weather Channel提供服务。Peter是国际级演说家，提供基本方针和研讨班来探讨用户体验、知识管理和可寻性之类的主题。
他的作品出现在很多出版物上，包括《商业周刊》、《财富》、MSNBC，以及((华尔街日报》
上。
Peter获得了密西根大学图书馆学硕士学位，目前在该校教授热门的研究生课程。

之前一直以为产品经理是个比较纯粹的岗位，没有想到会牵涉到这么与多部门之间的沟通协调。从这则招聘广告中提到的工作职责第一点中可以看出产品经理最重要的是把一个产品策划设计出来，定位这二字看起来简单，其实要考虑到的元素也很多，细节功能的设计也是必不可少的，常常在两个类似的网站中因为其中一个的细节功能设计更卓越而让用户作出新的选择，所以在要求当中提到“在至少一个产品从构思到推出以及后期运作过程中扮演过核心的角色”、“优秀的定量分析能力和严密逻辑思维”也是理所当然了；职责第二点是一个长期的工作职责也是必不可少的，只有长时间持续不断的改进才可以更加完善产品；职责第三点包括协调和指导界面设计（UI）/用户体验（UE）、市场/品牌推广（PR）、程序开发、数据挖掘、商务拓展（BD）面的人员完成服务的设计、开发、运作、推广和商务拓展（BD）工作，要完成这样一个复杂而重要的工作职责，所需要的知识，能力，经验从工作要求的3，4，5点也能看出来了。