|
【产品经理】从产品出发，构建企业根基 一、演讲内容做全面总结 阶段一：立项——该不该做 李老师根据用户依赖性，将产品分成三个层级，第一层级，对用户来说可有可无；第二层级，让用户产生一定依赖，如电动剃须刀；第三层级，让用户离不开，如微信。层级之间的差异关键是新的解决方案和原有解决方案的对比优势如何。 什么样的产品成功概率更大？喜欢+擅长+坚持=产品成功概率大，如果特别喜欢，那么很容易坚持，可以通过学习来达到擅长，产品容易成功；如果擅长某个方向，做的过程中会投入更多，进而慢慢喜欢，再加上坚持做，产品成功概率依然很大；如果既不喜欢，也不擅长，那还是算了，单纯的坚持没有意义。阿里前副总裁卫哲曾分享过马云的类似观点，要想产品成功概率大，参与产品创建的人首先要热爱这个产品，一定要主动参与，如果是被指派负责某个产品，则不会全情投入，几乎都会失败，阿里的成功案例，鼓励内部员工自发创业，投资200万人民币做出价值超过10亿美金的阿里妈妈。 判断力。决定产品yes or no！不要讨论不该讨论的问题，要尽可能抽象化的提出问题！不要试图定义每一个执行细节！首先要清楚，在立项阶段不适合讨论具体执行的细节，而是应该更多的思考当下的时点机会是什么，用什么样的产品可以解决用户什么痛点，不要提类似的的问题：“你感觉这个产品用户会喜欢吗？”我们可以看到大量的产品是刚开始定方向的时候定对了，立项时可能难度还极大，但是随着发展，一些细节困难被新技术和新材料所解决，如特斯拉最初原型机只能开五分钟。所以在决定该不该做的时候，更多的是看产品应用场景，需求频次，可能的市场规模，新产品对原产品的颠覆性，时间点对不对，还需要回答一个问题，用什么产品去承载你所立之项。 技术和产品的协作。李老师重点提到了团队中开发和产品的关系，建议要让开发一定程度跳出执行层面，从扩展属性出发，进行前瞻性提问，而非静态关注每个项目的成功率，也就是说产品或功能是否满足需求不应该是开发关心的问题。产品经理需要将用户反馈和判断，及时与团队沟通，让团队成员清楚产品的整体规划，这有助于开发从扩展性，架构和连续性上做更好的准备。 阶段二：产品定义——能不能做 首先，需要看产品解决了用户何种需求，这个痛点的解决占用用户多少时间，解决方案的成本如何（新解决方案成本上降低的比例决定了产品未来的受欢迎程度），产品的使用频次和规模会影响其未来定价能力和溢价能力。频次高，可以考虑客单价低，如天猫超市和京东超市；频次低，则需要客单价高，否则没有办法维持商业运营，如房多多，汽车之家，眼镜销售。 4步判断产品能不能做。竞品分析，市场分析，客群分析，能力储备。竞品不光是同类型产品，而且需要基于用户画像，发现潜在竞品。 产品经理需要与用户紧密联系，用户可以粗略分为老用户，新用户，深度用户，轻度用户。轻度体验用户一般会比较懒，产品需要尊重这些用户，为其提供便捷。更需要珍惜深度学习型用户，百度最初招聘产品经理就是那些体验产品后，编辑测评或提供系统性反馈意见的用户。 差别定义。新产品的推出要尽量满足“差异化”和被需要，差异化可以是人群的差异化，被需要是指市场容量还存在，且不会被快速替代，寡头竞争相对较好。竞争都是先多后少，然后再多的过程。比如手机行业，最初中国有上千个品牌，经过一轮厮杀剩下几个品牌，而今天手机品牌又有所增加，而类似于vivo和oppo这样的公司找到了拍照+快充+渠道的套路，冲到销量前两位。差异化的点，若体现在功能上，则要考虑该差异化是否是高频和普通的。不是高频，则做了也不容易被察觉，是为用户份额领先者打工。不是普通，大众使用感受到的差异化很难形成口碑，很难产生规模效益。 效率。李老师强调的效率是指团队需要非常清楚目标是什么，看到目标与现状的差异，实现新产品的成本及团队能力考量。这部分内容阿里巴巴前副总裁卫哲老师曾经做过系统分析，后续会整理分享。 阶段三：组织实施——搭建什么样的团队 选择单点突破还是平台战略？以小米为例，雷军将小米的的团队结构定义为铁人三项：硬件+团队+互联网，李老师感觉这个类比和小米的实际情况不符，小米实际上做的是百米飞人，因为铁人三星很难出明星，硬件为发烧而生的概念更像是百米赛跑，就是短时间对抗产生明星，提到百米大家都能想到博尔特，提到110米拦，大家都会想到刘翔，提到铁人三项，你会想到谁？我们今天看到的小米在只能硬件平台上很强，其团队和互联网是为硬件服务的，可以看一下应用下载排行榜中，小米的互联网产品下载量，如果是互联网强，应该是小米的应用下载量排名靠前。 找什么样的人组建团队？人是团队的关键，创业过程中人的选，用，驭，留是最关键的。选对人特别重要，这一点与《重新定义公司》中的观点高度一致，google招聘可能需要经历几十轮面试，就是要通过层层面试选择创意精英。阿里巴巴则是通过人效进行控制，如果你们部门需要招聘，那么你们部门每增加一个人，部门需要增加100万的KPI指标。当选对了人，用和驭就很容易。李老师回忆了在百度时候的招聘，那时候还没有BAT的概念，招聘进入百度的人可能能力不是最好的，但多是因为感觉百度正在做的事情是有意思的，有发展的，有极大进步空间的，面试者来百度为了让百度变得更好，为公司附能。而成为BAT后，招聘的人才能力上提高了很多，但是心态变了，他们感觉进入百度是一种成就，是公司为人附能。 对于校园招聘的新员工培训，可以宣传企业文化，用梦想和愿景驱动员工。而对于社招的新员工培训，需要将企业中做过的试错经验进行传达，否则新人进入后很可能依然去尝试那些已经验证过的，做那些行不通的试错。 如何形成稳固的团队？现在公司的创始人需要将1/3的精力给投资人，1/3的精力参加行业会议交流学习，1/3的精力留给自己的团队，留给公司团队这部分极其重要，因为只有中层理解创始人的战略和意图，执行上才不会出大问题，所以创始人一定要注重于团队的沟通交流。李老师将公司的团队管理类比为搏击，搏击中只需要注意两点：抗击打能力和体能。对应到企业上来，团队需要能够扛得住竞争对手的攻击，而且需要抗的够久，就像千团大战，共享出行大战，O2O大战，现在的直播平台大战，共享单车大战，最终考验的是团队的耐力，和你来我往中的抗击打能力。 阶段四、商业模式构建——如何盈利 只有清晰的商业模式、盈利模式才能形成使命价值观。当下的创业很难不考虑盈利，先圈用户，人口红利期已过。对于大公司，企业转型伴随着团队结构重组，进而带来商业模式转换。李老师以苹果举例，乔布斯时代的苹果，听完发布会用户会对拿到新品有强烈的期待，而今天的苹果公司，发布会依然火爆，用户也依然会选择苹果，但是已经没有那么强烈的对于新品的期待了。库克时代的苹果调整了公司的商业模式，其单品的利润依然很高，所以当初做空苹果的投资人亏了很多。但是苹果现在看很难再有突破，因为其单品的利润是固定的，再来看特斯拉，google和uber则还可能长得特别大，吃穿住行中的行，作为底层刚性需求，未来技术变革可能将出行这个领域完全颠覆，而这种对已有服务的彻底性颠覆，利润可谓上不封顶。 阶段五、建立企业机制和企业文化——制度和价值观 大型企业的三个机制。决策机制，评价机制和奖罚机制。决策机制需要公开、透平、客观、公平；评价机制需要采用双螺旋分析，不简单是员工需求的满足，需要分为激励因子和保健因子；奖罚机制则可以进行选择，做上限管理（奖）还是下限管理（罚），创新型公司需要做好上限管理，一定程度包容犯错；而交付型企业和制造企业则需要强调下限管理，也就是通过罚来界定边界。如果交付型公司强调上限管理，可能导致主营业务被忽略，所有部门都为了拿到奖而参与到创新竞赛中，进而导致主营业务出问题。 二、从产品经理视角进行解读和思考 通常情况下，一款产品该不该做，能不能做都是由产品总监和CEO决定的，而到了产品经理和高级产品经理需要决策的是某些功能该不该做，能不能做，什么时候做。有时，公司为了探索新的领域，可能会让一个高级产品带队做一些新方向的尝试，但一般资源不会投入太大。结合李老师的分享，我将自己的理解和思考进行总结。 1、程序猿与产品狗 一个互联网团队中，必然会有这样两群人，程序猿和产品狗，可谓是互联网公司第一难处理关系。一般情况下，产品经理会拿着精心制作的PRD（产品需求文档）和原型与开发沟通需求，沟通中可能发现系统现有架构不支持产品需求，与前期需求冲突等问题，开发会变得很不耐烦。解决了种种问题后，开发根据工作量排期，这时又会出现各种突发情况，如需求调整，追加需求，逻辑有问题，特殊情况未考虑等。开发和产品的矛盾激化，开发只想静静的写代码，却总是被打断。李老师在分享中举了一个例子，产品与开发过需求，开发问你这个需求是否有数据支撑，如果没有数据支撑为什么要做？如果是创新型尝试产品或需求，当然没有数据支撑，李老师认为开发的关注点需要引导，团队需要引导开发去关注产品规划，而非关注具体功能的成败得失。 程序猿和产品狗的关系是一对极难处理的关系。首先，从程序猿角度来看，产品经理就是做个原型，写两页word，功能实现都是我来做，还总是过来改需求，加需求，逻辑还有问题，上一版的需求这一版又来回改，害的老子加班，从这个角度看过去，开发必然会有怨言。再从产品角度出发，产品做原型的时候可能感觉调整非常小，调整也是因为用户反馈，加需求也是老大的意思，我也没办法，还要面对开发的不耐烦或拒绝，产品也很烦。那么如何能让这种冲突变得缓和一些呢？个人理解，以下三点一定可能有效：平时多沟通，专业性，目标统一。 平时多沟通。很多时候，沟通的矛盾源于彼此沟通不在一个频道，或者说开发没有把你当自己人，如果在开发的眼中，产品只是一个派活的，那么问题就会很严重，派活和干活很容易直觉上定义为对抗关系。如果平时多沟通，一起打打王者荣耀，请开发撸个串，共同加班，产品成功时在领导面前多为开发多说好话，为其争取福利，这种行为会传达出产品的友善，彼此的沟通需求时不会有预设立场，一旦这种预设立场没有了，沟通起来就会更加顺畅，要让开发指导，产品也不想添麻烦，但是问题出现了，我们只能一起上，去解决问题。 专业性。没有人可以接受自己的努力被别人无视，也没有人可以接受自己的时间被别人浪费，所以要尊重开发的工作。需求尽最大努力做到专业，逻辑上不能出错，内部没有评审过的需求不可以给开发，虽然产品经理不是神，设计的产品功能不可能一次性满足用户需求，但是产品需要具有强大的学习能力和复盘能力，某个功能的第一版需求可能是源于人性的洞察或老板指示，但是该需求的后续优化一定需要有数据验证，而这个思考和验证过程最好能进行分享，产品经理定期做产品复盘分享，用户反馈分享，竞品分析分享，市场分析分享，学习心得分享，这些分享面向开发，设计和同组产品，分享中可以让相关协作者看到产品经理的思考，知道产品的方向，开发可以提前考虑系统的拓展性和架构调整，设计可以更好地理解用户需求，设计出满意的交互和UI，分享同样有助于产品做出深刻反思和总结。产品的专业性还体现在技术知识的掌握，产品未必要会写代码，但是需要知道技术实现的逻辑，需要掌握一门语言，这都有助于编辑文档时逻辑更加清晰。 目标统一。产品经理需要将开发和设计的目标进行统一，统一的结果是我们设计的产品是为了更好的满足用户需求，解决用户问题，而不是谁为了业绩为难彼此，我们是为了将一个产品变得更好用而努力，也就是李老师说的，想办法让开发具有一定的产品视角和市场洞察，这样更容易进行目标统一。产品有时可能没办法了，会抬出来老板的意思，这招尽量少用，老板希望做的功能需要思考其背后的目的和意义，因为信息量不一致，导致看不懂老板的需求，不懂要问，CEO比产品经理更希望产品好，从产品的长期发展来看，产品经理和老板的目标是一致的。 2、从时间维度思考产品 罗胖在跨年演讲中提到，现在所有的服务实际上都是在争夺用户的时间，也可以理解为争夺用户对于产品的注意力，李老师也在分享中提到，能不能做一个新产品，要看其解决了用户的什么痛点，没有这个产品的时候，用户为了解决这个痛点用了多少时间，使用了这个产品后，用户可以节省多少时间。 以天气类服务墨迹天气为例，产品初期解决的就是用户希望知道当地天气的需求，最初是每天晚上看新闻联播后面的全国天气预报，后来可以用百度搜索查看各地天气预报，移动互联网时代也可以通过浏览器搜索地名查看天气，但是数据信息量太小，操作繁琐，于是墨迹天气切入天气预报这个工具类市场，通过提供更准确的天气预报信息，为用户提供穿衣指南，雾霾指数等用户关注的信息服务，用户点击直接可见实时天气，或者通过手机屏幕组件关联实时同步天气信息，无需点击也可查看，这能节省用户每次20几秒的操作时间，因为查看天气是高频需求，长期来看会极大节省用户时间。墨迹天气通过实景拍照分享功能具有了类似于installgram的属性，一定的社交属性，一步步从一个工具走向了图片瀑布流风景分享社交平台。 从用户痛点和需求场景发生频次出发，考虑新产品或新功能是否帮助用户节省了时间，是一个很好的思考维度，当然有些应用是帮助用户消磨碎片化或闲暇时间的，如直播平台，游戏，视频平台等，在分析产品功能该不该做，能不能做，可以将帮助用户节省时间维度作为一个重要指标。 3、规模改变也是一种变革 王煜全老师曾经在混沌研习社做过分享，《新技术与新趋势》中提到了三类变革，第一类是社会变革，改朝换代，这种变革会是颠覆式的，有大机会，也有大毁灭。第二类变革是人口结构变革，比如90后消费市场和95后消费市场，这些事人口变革带来了增量市场，全新的人口结构带来全新的需求。第三类变革是技术变革，如触屏技术的出现，直接将手机的发展推向了全新的高度，造成了诺基亚和摩托罗拉帝国的崩塌，苹果公司的快速崛起。 李老师今天提到一个以前没有想过的变革，规模改变也是一种变革，把握不好很可能会因为规模扩大而破灭，老师以豆瓣和知乎为例，两家公司都是最初做小而美的细分市场，最初的用户质量很高，沉淀下大量优质独家内容，而随着平台扩张，大批量用户涌入，原有的结构受到冲击，最初的那批优质忠实用户可能因为大批量的新人进入而离开平台，因为原有的打分和评价系统可能不适用于新的场景。美丽说CEO曾经做过产品分类分享，将产品粗略分为三类：1对1产品，一对多产品，多对多产品。当一个产品用户规模发生改变，平台涉及到多方利益时，可能从原有的一对多产品发展为多对多产品，而多对多产品核心已经不再是功能设计，而是规则制定和利益均衡，所以产品经理一定要警惕规模改变带来的用户构成改变，产品的规则可能需要随之不断调整。 4、案例背后的逻辑 李老师分享中举了一些例子，都是老司机的经验之谈，我们来看看其分析产品的视角。 汽车之家的故事。汽车之家的CEO李想为什么从汽车这个领域切入，首先汽车市场SKU有限，后台相对容易，2004年的时候，其他汽车在线服务前台做的很烂（用户更容易头部空间有几拳，后排腿部空间有几指，而不是类似于轴距这样的冰冷数据），所以有机会进行超越，于是就创立了汽车之家。因为买车是低频，长决策流程的活动，为用户提供高质量的内容和社区变得特别重要。为了让用户感觉到平台的活跃，分析用户行为后，发现用户一般会在每天早晨8点到11点登录，晚上7点到11点登录，所以这段时间之前更新大量内容，让用户感觉到平台内容的更新频率极高。 携程和艺龙的故事。两家公司都是主打商务用户的酒店预定服务，创立之初，用户的痛点是预定客房困难，有了两家提供的在线查看预定服务后解决了这个痛点，但是经常出现客人通过携程预定了房间后，到宾馆后发现没有房了，携程为了应对这个问题，根据数据分析和热点区域检索，每天固定预约一定数量的房间，为用户提供预订使用，用户用了一段时间会发现艺龙上经常预定后到店没房，而携程一般都会有房，就是这种差异性，让携程做大，走到今天。 滴滴出行和淘宝。淘宝是一个多对多产品，最基础的关系是卖家和买家的关系，阿里的产品经理经常分享阿里早期先抓卖家，提高SKU后抓买家，这是一个动态平衡的过程，如果只有卖家没有买家，则卖家会感觉无利可图，不会用这个平台，而如果买家太多发现SKU不足，则买家会放弃使用这个平台。滴滴出行遇到的是一样的问题，先抓出租车和私家车还是先抓用户，这也是一个动态的博弈过程，哪一方突然增加太多都会出问题。 脑白金的故事。史玉柱最初做脑白金的时候不知道应该叫什么，怎么卖，于是他带着销售团队去小县城扫楼，通过话术的调整，优化产品原型，发现用户送礼需求，将完善的话术和推广模式复制后到其他县城推广，不断优化完成后进行全国推广，如果看过《精益创业》的朋友一定会发现，这种方法正是精益创业法，通过小步快跑，高效试错，优化产品，验证成功后大批量生成。 日本景观设计和中国景观设计。园林设计都是为了营造美的意境，让人感觉赏心悦目，但是因为起点上的一点差异，导致日本与中国景观设计走向了两条截然不同的道路，日本的园林设计源于中国的佛学，不看现世看来世，所以园林景观是为了远观的，追求几百年景观的前后的一致性，而中国园林是为满足士大夫阶层的风雅需求，一定是一步一景，景观可交互，只看现世不看来世。以前做过一篇王东岳老师的总结，其中介绍了东西方文明的因为起点的一点点差异--农业文明和半农半商业文明，导致两个文明发展成完全不同的文明形态，感兴趣的朋友可以链接查看 东西方文化溯源-推演东西方文化底层差异。 三、个人所得 1、好的产品经理是终生学习者 产品经理需要发现用户痛点，争取资源，获取团队支持，将解决方案落地为产品，并根据用户反馈持续优化产品，这个过程中产品经理需要掌握心理学知识，社会学知识，技术知识，不但如此，因为用户在变，技术在变，所以产品经理需要持续的学习最新的知识，这需要产品经理持续学习，好的产品经理都是终生学习者，他们是时代发展的跟随者或者引领者。 2、前台重要还是后台重要？ 李老师在分享中不断的提到产品的前台和后台，两次在线测试也都是问某个时间点，创业时应该注重前台还是后台，在最终的问答环节，老师提到，前台和后台哪个重要，是他这么多年做产品总结出来的特别重要的一个问题，时点不同，侧重点则不同。前台指用户使用的页面和交互，后台指服务商使用的页面，淘宝有前台用户页面和后台商家页面，还有广告主，物流服务等页面。滴滴出行有用户操作页面和司机操作页面。例如阿里早期做淘宝的时候就是到论坛和评价中看用户和供应商对于易趣的差评，把差评中的问题解决了，然后去易趣挖卖家，而所以最初淘宝前台交互可能有各种问题，但是这都不重要，淘宝后台做的好，把卖家沉淀下来，当SKU足够大的时候，再去优化前台页面。 3、产品经理为用户代言 BAT三家都强调产品经理需要与用户保持紧密的联系。李老师分享中提到，百度新加入的产品经理需要做6个月的用户反馈梳理和分享，通过对用户反馈的关注，让产品经理更加理解用户。腾讯公司对于产品经理的要求是10/100/1000，即产品经理每个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验。阿里巴巴会把新人产品经理扔到客服去处理三个月投诉，这样产品经理就非常清楚应该做什么了。所以产品经理就是用户的代言人，需要为用户说话，一切从用户痛点出发。 好的产品改变世界，产品经理改变产品，产品经理们改变世界。
版权声明
1、本站所发布的一切学习教程、软件等仅限用于学习体验和研究目的；请自觉下载后24小时内删除，严禁用于其他用途，如果你喜欢教程，请支持正版教程软件，得到更好的正版服务，本站内容全部来自网络，版权争议与本站无关，如果您认为侵犯了您的合法权益，请联系我们删除。发送邮件到邮箱：liujun540@qq.com。
2、对于不当转载或引用本网站内容而引起的民事纷争、行政处理或其他损失，本网站不承担责任。
3、对不遵守本声明或其他违法、恶意使用本网站内容者，本网站保留追究其法律责任的权利。
| 
|Archiver|手机版|业务团网
|桂公网安备 45022102000011号
发表于 2018-4-24 09:16:58
发表于 2019-2-19 03:00:45
